Las diferencias entre la construcción en una máquina con VS2010 instalados y en una máquina con instalan el SDK 7.1

Question

Estamos tratando de mejorar nuestra base de código para utilizar Visual Studio 2010, pero estamos teniendo problemas para conseguir todo lo clasifican en nuestros servidores de construcción. No queremos instalar Visual Studio 2010 en nuestros servidores de construcción y así hemos instalado .Net sólo el 4 y el marco SDK (v7.1).

Todavía estamos queriendo apuntar al 3,5 plataforma .Net (vamos a actualizar a .Net 4 en algún momento en el futuro, pero no queremos que por el momento).

Hemos logrado obtener el código para compilar pero ahora que se están ejecutando en los errores de ejecución como el siguiente.

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.

El problema es que el tiempo de ejecución está tratando de deserializar el recurso incrustado y si miro a los recursos en el reflector, veo que todos son .Net 4.0 objetos. Por ejemplo, el icono de nuestra aplicación de una ventana es de tipo System.Drawing.Icon, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.

Así que parece que MSBuild está recopilando los recursos de forma incorrecta (con un tiempo de ejecución diferente a la meta)? He confirmado esto mirando los diferenciales de la DLL construido en mi máquina dev y que incorporado en el servidor de compilación - es claro ver que los recursos de una DLL utilizan la versión 2.0.0.0 y el otro (desde el servidor de compilación) utiliza 4.0 .0.0. Las referencias del proyecto son los archivos DLL v2.0.0.0 en ambos casos (como cabría esperar).

¿Alguien tiene alguna idea de por qué MSBuild está recopilando los recursos como objetos 4.0?

Gracias de antemano.

Chris

Answer 1

Al actualizar su solución de VS2010, se cambia el marco dirigido? Puede buscarlo mediante la visualización de los archivos csproj en un editor de texto. ¿Tiene el marco 7.0a en su servidor de compilación?

EDIT:

Me encontré con el mismo problema hace un tiempo y tiene algo que ver con la clave de registro no se establece. Echar un vistazo aquí: http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting -net-3-5-genera-mal-recursos-incrustados

Creo que es necesario añadir manualmente la clave de registro HKLM\Software\Microsoft\MsBuild\ToolsVersions\SDK35ToolsPath

Answer 2

No estoy seguro de si esto ayuda, pero ver este enlace en relación con RequiresFramework35SP1Assembly de tareas

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