Diferenças entre a construção de uma máquina com o VS2010 instalado e em uma máquina com o 7.1 SDK instalado

Question

Estamos tentando atualizar nossa base de código para usar o Visual Studio 2010, mas estamos tendo problemas para resolver tudo em nossos servidores de construção. Não queremos instalar o Visual Studio 2010 em nossos servidores de construção e, portanto, instalamos apenas o .NET 4 Framework e o SDK (v7.1).

Ainda estamos querendo atingir a plataforma .NET 3.5 (atualizaremos para o .NET 4 em algum momento no futuro, mas ainda não queremos).

Conseguimos obter o código para compilar, mas agora estamos enfrentando erros de tempo de execução, como o seguinte.

Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

O problema é que o tempo de execução está tentando desserializar o recurso incorporado e, se eu olhar para os recursos no refletor, vejo que eles são todos objetos .NET 4.0. Por exemplo, o ícone do nosso aplicativo Windows é do tipo System.Drawing.Icon, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.

Parece que o MSBuild está compilando os recursos incorretamente (usando um tempo de execução diferente para o destino)? Confirmei isso olhando as diferenças da DLL construída na minha máquina de desenvolvimento e que é construída no servidor de construção - fica claro ver que os recursos de uma DLL usam a versão 2.0.0.0 e a outra (do servidor de construção) usa 4.0 .0.0. As referências do projeto são para as DLLs v2.0.0.0 em ambos os casos (como seria de esperar).

Alguém tem alguma idéia de por que o MSBuild está compilando os recursos como 4.0 objetos?

Desde já, obrigado.

Chris

Answer 1

Quando você atualizou sua solução para o VS2010, mudou a estrutura direcionada? Você pode procurá -lo visualizando os arquivos CSPROJ em um editor de texto. Você tem a estrutura 7.0A em seu servidor de construção?

Editar:

Eu encontrei o mesmo problema há um tempo atrás e isso tem algo a ver com a chave do registro não definida. Dê uma olhada aqui:http://connect.microsoft.com/visualstudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-Emibed- Recursos

Eu acho que você precisa adicionar manualmente a chave do registro HKLM\Software\Microsoft\MsBuild\ToolsVersions\SDK35ToolsPath

Answer 2

Não tenho certeza se isso ajuda, mas veja este link sobre requerframework35sp1ASSEMBLY TARK

http://msdn.microsoft.com/en-us/library/ff598689.aspx