How does one have developers on VS2008 target .net 2.0 (but not the service pack) to avoid runtime crashes?

Question

So, I want to upgrade my development team to VS2008. As an enterprise, we haven't rolled out the 3.5 runtime yet.

From some reading, it seems like installing VS2008 will automatically give you .net 2.0 SP1, which has some new APIs, and when you target 2.0 runtime it will assume 2.0 SP1.

But if SP1 is not rolled out to our users, this will lead to runtime breaks.

1. Is there anyway to have VS target dotnet 2.0 (NOT SP1)?
2. Is there any other solutions to this problem so developers don't use APIs that compile and run fine locally but blow up in production?

I see that fxcop has a check for this but there must be a more fool-proof solution to this problem.

Answer 1

This can be difficult or easy. We went both routes:

1. The easy way: Establish a build server that has only .Net 2.0 installed. Automate the build to run on check-in (we use CruiseControl.Net). You will have to use MSBuild from the command-prompt to build the projects.

2. For machines with 3.5 installed many of the MSBuild tools are replaced even when you run the MSBuild from the .Net 2.0 framework directory. To avoid this you must create an application that forces the continued use of the .Net 2.0 runtime only. This is not easy. We directly load the projects and invoke the the build using the Microsoft.Build.* framework. This alone is still not enough. You have to pin the assemblies you want to use in your .config file:

   <configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="2.0.0.0"/> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="2.0.0.0"/> </dependentAssembly> ... ect ... </assemblyBinding> </runtime> </configuration>

BTW, you may also have issue with projects newly created in VS2008 expecting a property called "MSBuildToolsPath" which must be defined. You can define this on the command-line if using MSBuild, or specify it programatically if using the second option:

engine.GlobalProperties.SetProperty( "MSBuildToolsPath", msbuildPath );

Answer 2

Perhaps the supportedRuntime configuration element is worth to have a look at. But I'm not sure if this can help.