Yeah, I found something to that effect here: http://channel9.msdn.com/forums/TechOff/260742-ActiveX-Test-Container/ However, even after building the old sample code and applying the linker workaround I still encountered run-time issues. I tried upgrading to VS2008 SP1 and grabbed the SP1 samples, but the sample tstcon won't even compile. So it gets worse going forward. I am pretty disgusted with Microsoft right now. Pretty pointless to publish a tutorial that relies on a tool that is no longer supported, and to ship sample code that won't even build let alone run. Thanks for the reply.

The menu item is present on the Tools menu, but is disabled. I did a full install of VS2008, so it should be available, but ... Has it been pulled? Are there some extra steps required to activate? NOTE: I don't think it matters, but I am running Windows 7 Thx NIK

Well Mike, if you are trying to steer peope away from this site, you are doing as good job.

Anyone have any practical experience using this component in a corporate environment? My exchange server name doesn't seem to work. Presumably I need some specific designation for SMTP.

Yep, just tracked that down. It's in System.Net.Mail, looks like there is a small sample in the MSDN code library. Thanks for the response.

Are there any components in .NET that support basic SMTP processing? Just need something that will enable me to send a notification email from a desktop application (not ASP). Presumably, I could use MAPI, but then I have to mess around with Sessions and Logons, etc.

No worries, at least I can make an informed decision. I am kind of inclined to just do this old-school and roll my own pseudo database and write the app in straight C/++. It will be screaming fast and have no platform dependencies. The time I would have spent ramping up on SQL, .NET, DAO, IIS, etc, can be spent on implementation. Thanks again for the input. NIK

One Yes and One No - I am well confused.

Really!!! So I can just use something like string path = "C:\\MyFiles\SomeFile.Txt"; File.OpenText(path); ... in code behind?

Hey folks, I need to build an application that does some local file manipulation (editing, copying, etc.) on the behalf of the user. How restrictive is ASP in terms of client side machine access? I could just write a client-server app instead, but seems like that would take bit more effort. Thx NIK

:suss:I'm thinking I can ignore the posts from 2000

:) No-one codes for free, at the very least we spend our time.

Apologies if this is not the place for this. If anyone is looking for a software engineer with 10 years of Windows development experience plus C#, WPF and .NET experience, let me know. Thx

No runtime modification or localization needs. Decided to go with a simple XAML declaration of strings in Application.Resources and use typename.value as key (ID) name. No hard coded string IDs, and easy for non-programmers to maintain (notepad) in a centralized location.

should have extended subject to say "that can be easily modified by non-programmers outside of the .cs file" I think I can probably build a ResourceDictionary in XAML that would provide a basic lookup capability at application scope. Thus my UI guy can tweak the XAML and I can simply do a FindResource using the enum value identifier as the key.

I need to provide a secondary string description of the enum value. Rather than "Blue", I would want to map that value to a human friendly string such as "The Color Blue". Make sense?

We have various enumerated types in our system and we obviously want to present human readable values that can be easily configured by our UI folks rather than the cryptic identiofiers that we use in the code. Just wondering what facilities are available in .NET 3.0 to accomodate this kind of thing. In the old days, I would use a string resource and a mapping table for the lookup. Anybody got any cool/slick/modern ideas on this? Thanks NIK

Check out the competing product. Find out what they do well and copy it. Find out what they don't do well and do it better. Define your feature set and use cases before you even begin to worry about technical design. Most importantly, find another human being to collaborate with even if its just your significant other listening to you spew every night. The mental process of articulating the problem is invaluable.

I have MS looking into it via my MSDN subscription, I'll post the results. BTW - I learned that Mixed-Mode debugging for x64 will not be supported until AFTER Orcas, which itself isn't even due until next summer.

My whole team is impacted (severely slowed) by this one. Currently we are debugging via trace output, which is obviously sub-optimal. We are developing some Native x64 DLLs that are plugged into an x64 Managed application. We really need to be able to debug the Native DLL in Visual Studio 2005. However, when specifying the managed Exe as the Debug Command for the project, I encounter the following error message. Unhandled exception at 0x78d4dd30 in Managed.exe: 0xC06D007E: Module not found. It appears the managed application is no being launched properly. Any ideas on what the problem is and how to fix it. Thanks NIK