One of the first things you'll discover with VC++ 2005 is the fact that there are now two different lenguage dialects for managed (.NET code). The original Managed Extensions for C++ syntax (or MC++ for short) introduced with VC++.NET 2002, and the new CLI Bindings for C++ (or C++/CLI for short).

The new C+/CLI is going to be the default and only syntax going forward, so you'll want to migrate your existing MC++ code to use it (it not only is more powerful, but the overall syntax is much nicer, too). This means that the /clr switch now assumes it is compiling C++/CLI code, and not MC++ code.

You can still compile MC++ code by using /clr:oldSyntax instead, though, so no need to panic. There are even a few (small) fixes, so it should be better anyway.

Back to compiling C++/CLI, it is important to understand that there are three favors of the /clr switch for it:

• /clr: This is the default behavior, which means the compiler can compile C++/CLI code that generates mixed assemblies (containing both MSIL and x86 code). It is by far the most flexible option, since it allows almost seamless mixing of unmanaged and managed code (it is far better at this than MC++ ever was, btw) using the C++ interop options (otherwise known as IJW).
• /clr:pure: This restricts the language to a subset so that it can generate assemblies containing only MSIL code, with no x86 at all, so IJW is not supported. You can still use P/Invoke to call unmanaged code from pure assemblies, though. With /clr:pure, you should get good performance (as far as .NET is concerned), since you basically have no managed/unmanaged transitions unless you explicitly add them through P/Invoke. You also get most of the security benefits that pure MSIL assemblies (such as those generated by C# and VB.NET) have enjoyed such as full reflection support and support for environments that have trouble using mixed mode assemblies. If you're only writing managed code, you'll want to ensure you use /clr:pure at the very least.
• /clr:safe: This restricts the language to a subset of features where the compiler can ensure it generates MSIL code that is also verifiable (so it goes further than /clr:pure). The main downsides are that you can't call unmanaged code at all (not even using P/Invoke), that you don't get to use the CRT, and don't get to use native data types at all. However, as a benefit you get increased security and access to places with tight security (such as running inside SQL Server 2005).