Como se possui desenvolvedores no VS2008 Target .NET 2.0 (mas não o pacote de serviço) para evitar falhas de tempo de execução?

Question

Então, eu quero atualizar minha equipe de desenvolvimento para o VS2008. Como empresa, ainda não lançamos o tempo de execução de 3,5.

A partir de alguma leitura, parece que a instalação do VS2008 fornecerá automaticamente o .NET 2.0 SP1, que possui algumas novas APIs, e quando você segmentar o tempo de execução 2.0, ele assumirá o 2.0 SP1.

Mas se o SP1 não for lançado para nossos usuários, isso levará a intervalos de tempo de execução.

1. Existe alguma maneira de ter vs vs Target DotNet 2.0 (não SP1)?
2. Existem outras soluções para esse problema, para que os desenvolvedores não usem APIs que compilam e funcionam bem localmente, mas explodem na produção?

Vejo que o FXCOP tem uma verificação para isso, mas deve haver uma solução mais à prova de idiotas para esse problema.

Answer 1

Isso pode ser difícil ou fácil. Fomos as duas rotas:

1. A maneira mais fácil: estabeleça um servidor de construção que possui apenas o .NET 2.0 instalado. Automatize a compilação para executar no check-in (usamos o CruiseControl.net). Você terá que usar o MSBuild do promotor de comando para construir os projetos.

2. Para máquinas com 3.5 instaladas, muitas das ferramentas MSBuild são substituídas mesmo quando você executa o MSBUILL no diretório da estrutura .NET 2.0. Para evitar isso, você deve criar um aplicativo que força o uso contínuo do .NET 2.0 RUNDEMPLE. Isso não é fácil. Carregamos diretamente os projetos e chamamos a compilação usando o Microsoft.Build.* Framework. Isso por si só ainda não é suficiente. Você precisa fixar as montagens que deseja usar no seu arquivo .config:

   u003Cconfiguration>u003Cruntime>u003CassemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">u003CdependentAssembly>u003CassemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>u003CbindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="2.0.0.0"/>u003C/dependentAssembly>u003CdependentAssembly>u003CassemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>u003CbindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="2.0.0.0"/>u003C/dependentAssembly> ... etc ...u003C/assemblyBinding>u003C/runtime>u003C/configuration>

BTW, você também pode ter problemas com os projetos recentemente criados no VS2008, esperando uma propriedade chamada "msbuildToolspath", que deve ser definida. Você pode definir isso na linha de comando se estiver usando o msbuild ou especificá-lo programaticamente se estiver usando a segunda opção:

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

Answer 2

Talvez o Elemento de configuração suportadoRuntime vale a pena dar uma olhada. Mas não tenho certeza se isso pode ajudar.