The recent release of Visual Studio 2008 and .NET Fx 3.5 is causing some confusion. Microsoft released these two technologies together for good reason. The wonderful new LinQ technologies introduced in .Net 3.5 rely on explicit compiler-level support, and therefore require LinQ aware compilers in Visual Studio. The new version of visual Studio provides these compilers, allowing developers to take advantage of the new monadic syntax. In addition, Visual Studio has several new features designed to make it easier to exploit NET 3.5 features such as Ajax and the foundation libraries (WCF, WF and WPF).
The problem is that by tying the release of .NET 3.5 to Visual Studio 2008, the impression is given that, unless you are ready to upgrade to the new version of the IDE, there is no point thinking about upgrading to the new version of the framework. This is simply not the case. The .NET framework does not have any built-in dependency on Visual Studio, let alone a specific version of Visual Studio. More to the point, Microsoft has long since split the versioning of the framework from the versioning of the run-time environment. .NET 3.5 continues to exploit version 2.0 of the CLR. Visual Studio 2005 is perfectly happy to compile your code against .NET 3.5 assemblies. They are just assemblies. Even more compelling is the realisation that most of the assemblies in .NET 3.5 are identical to those in .NET 3.0 (same version number). There are some new assemblies with new features. .NET 3.5 is just .NET 3.0 with extra stuff.
Why is this important? Well, not everyone is ready to upgrade to Visual Studio 2008. Apart from the expense this involves, consider the dilemma of BizTalk Server developers. Currently, there are no Visual Studio 2008 bindings for BizTalk Server (i.e., you can’t create BizTalk Server project types in the new IDE). This, we are assured, will be addressed at some point, but that could be months away. For the time being, BizTalk developers are stuck with Visual Studio 2005 🙁 Hence, some people are currently discounting the possibility of using .Net 3.5 because they believe, quite incorrectly, that it requires an upgrade to Visual Studio 2008.
There are issues, of course. As well as the absence of compiler support for LinQ, Visual Studio 2005 does not have access to various new project and file templates and tools that support the new version of the framework. Developers may need to do more coding in Visual Studio 2005 than would be necessary in Visual Studio 2008. This is often a small price to pay, however, in order to access the improvements in 3.5. As an example, consider the new integration between WF and WCF, provided in the new System.WorkflowServices assembly. The integration is provided via the new WorkflowServiceHost class and a couple of new activities. Visual Studio 2008 has new template support for building workflow services, and comes with a very useful new WCF test harness. However, exploiting this new functionality in Visual Studio 2005 is trivial. Create a WF workflow library, add a reference to System.WorkflowServices and add the new activities to your tool box. Finally, use the WCF Service template to add a service class to your project and you are just about in the same position as you would be in Visual Studio 2008 if you used the new Workflow Service project template. You’ll need to write a couple of lines of code to use WorkflowServiceHost to host your service, of course. Off you go, and enjoy .NET 3.5.
posted on Saturday, December 01, 2007 11:23 AM
