Geek Answers Handbook

How do developers on VS2008 target .net 2.0 (but not on the service pack) to avoid run-time crashes?

So, I want to upgrade my development team to VS2008. As an enterprise, we have not yet completed 3.5 runtime.

From some reading, it seems that installing VS2008 will automatically provide you with .net 2.0 SP1, which has some new APIs, and when you set your sights on version 2.0, it will read 2.0 SP1.

But if SP1 is not released to our users, this will lead to runtime disruptions.

  • Anyway, is there VS target dotnet 2.0 (NOT SP1)?
  • Are there any other solutions to this problem, so the developers do not use APIs that compile and execute normally locally, but exploded during production?

I see fxcop has a check for this, but there should be a more flawless solution for this problem.

+4
source share
2 answers

It can be difficult or easy. We went through both routes:

  • A simple way: install the build server on which only .Net 2.0 is installed. Automate the build to run during registration (we use CruiseControl.Net). You will need to use MSBuild from the command line to create projects.

  • For machines with installed 3.5, many MSBuild tools are replaced even when starting MSBuild from the framework.Net 2.0 directory. To avoid this, you should create an application that forces you to continue to use .Net 2.0 runtime only. It is not simple. We directly load projects and invoke the assembly using the Microsoft.Build environment. *. This alone is not enough. You must include the assemblies you want to use in the .config file:

    <configurations> <environment> <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> </ environment> </ configuration >

By the way, you might also have a problem with projects recently created in VS2008, waiting for properties called "MSBuildToolsPath" to be defined. You can define this on the command line when using MSBuild or specify it programmatically if you use the second option:

engine.GlobalProperties.SetProperty( "MSBuildToolsPath", msbuildPath );
+1
source

It might be worth considering a supported Runtime configuration item . But I'm not sure if this can help.

0
source

More articles:


All Articles