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.
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.