Some of you may be wondering why the latest and greatest Visual Studio 8.0 does not support projects that target .NET Framework 1.0 or 1.1. This is a great question that deserves some in-depth coverage.

When VS 7.0 was about wrapped up we started thinking about v.next. There were now two .NET Framework versions to consider: 1.0 and 1.1. It was clear that having a single new toolset that could target both versions would be a great benefit for our developers. Early on in the VS 7.1 planning we investigated what it would take to do so.

This investigation showed that VS was deeply integrated with the CLR and the .NET Framework. This integration provides a rich development experience, but at the cost of some agility up and down the stack. Visual Studio uses parts of .NET Framework and the CLR as integral parts of the tools stack. The versions of the CLR and the .NET Framework that get loaded into Visual Studio determine some of the tools that VS uses and thus output target of those tools. Here’s how all of this all comes about.

1. The Visual Studio process can only load one version of the CLR. This is a limitation imposed by the CLR itself – one per process, thank you very much.
2. The CLR “shim” determines the version of certain unmanaged utilities used by compilers, linkers, and parts of the build system. These include the metadata reader-writer utilities, the assembly linker utility, and strong-naming utilities.
3. The CLR’s Unification Policy determines the single version of the .NET Framework that can be loaded into the process.
4. Unification Policy influences the version of designers and code generators that Visual Studio can load and thus the Framework version that these tools target. For example, when you reference a COM type library from the project system, the type library converter emits an interop assembly built for the current CLR version.
5. Unification Policy also limits the set of classes that designers themselves can load and design against. For example, a Visual Studio 8.0 process can only load a 2.0 Form. The designer cannot load and design for a 1.1 Form.

These difficult versioning issues hit almost every area of the toolset: editors, IntelliSense, compilers, linkers, the Object Browser, debugging, designers, resource generators, code generators, etc. It will take some serious restructuring of the CLR, the .NET Framework and the Visual Studio toolset to provide a great end-to-end development experience that targets a specific platform version.

In juggling priorities, costs, and benefits for Whidbey, the Visual Studio team determined it would be better to continue with a side-by-side toolset strategy than to delve the depths of cross-targeting from a single tool. We have therefore put effort into ensuring that Visual Studio 7.0, 7.1, and 8.0 can be installed side-by-side on the same development machine and can target side-by-side versions of the .NET Framework.

During Whidbey, the Visual Studio and .NET Framework teams have taken steps in the direction of supporting cross-targeting. Managed compilers can now take advantage of the Reflection Only Assembly Loading so that they can reflect on exact bits without being influenced by assembly versioning policy. The new MSBuild system has taken versioning into account so that build tools and tasks can be designed to target a specific CLR version. (See Jomo Fisher’s blog entry.)

I strongly support the initiative for a toolset that can target multiple versions of the Microsoft Windows and CLR platforms. This need comes into sharper focus when you consider distributed applications having heterogeneous combinations of mobile devices, desktops, web and database servers. These platforms version at different paces and we cannot assume that all will pop up to the latest CLR at the same time. This is why Visual Studio is currently investing in new tools architectures and CLR versioning strategies that will make a cross-targeting toolset tenable in the future.