Can VS.NET XmlSerializers 2010 / MSBUILD producir para .NET 3.5 SP1?

Question

Acabo de actualizar una solución VS 2008 que contiene Windows Forms, bibliotecas de uso general, y una aplicación web para VS 2010, pero todos los proyectos aún orientar .NET 3.5 SP 1. Yo uso esta técnica para generar XmlSerializers para mis bibliotecas de uso general. Los WinForms aplicación se ejecuta bien. Cuando mis intentos de aplicaciones Web para ejecutar el uso de estas bibliotecas que hacen referencia a los mismos XmlSerializers, que arroja el siguiente:

  

Error de servidor en '/ WebSubscribers'   Solicitud. No se pudo cargar el archivo o   montaje   'Ceoimage.Basecamp.XmlSerializers' o   una de sus dependencias. este conjunto   está construido por un tiempo de ejecución más reciente que la   actualmente cargado en tiempo de ejecución y no puede ser   cargado. Descripción: Una no controlada   excepción ocurrió durante el   la ejecución de la solicitud Web actual.   Revise el seguimiento de la pila para obtener más   información acerca del error y dónde   se originó en el código.

     

Detalles de la excepción: System.BadImageFormatException: No se pudo cargar el archivo o ensamblado '' Ceoimage.Basecamp.XmlSerializers o una de sus dependencias. Este conjunto está construido por un tiempo de ejecución más reciente que el tiempo de ejecución actualmente cargado y no se puede cargar.

He mirado en las referencias de la XmlSerializer usando .NET Reflector y ver que hace referencia tanto a las versiones 2.0 y 4.0 de mscorlib así como las 3.5 y 4.0 versiones de System.Data.Linq. Curiosamente, sólo utiliza la versión 4.0 de System.Xml. Eso es probablemente mi problema allí mismo.

¿Cómo puedo obtener la aplicación Web para ejecutar el uso de estos XmlSerializers? Cuando sólo tiene que borrar esos XmlSerializers, la aplicación web funciona muy bien. Esta es una opción, pero ¿cómo puedo forzar MSBUILD para crear serializadores para una versión específica de la CLR?

Esta es la tarea de MSBuild agrego a los archivos de proyecto que las fuerzas de la creación de la XmlSerializers:

<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
 <Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
 <SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
  <Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
 </SGen>
</Target>

Answer 1

He encontrado que puedo especificar explícitamente ruta de herramientas de la tarea SGEN utilizar la versión 3.5, así:

<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="@(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin">

Answer 2

MSBuild 4 voluntad (...) deberían usar herramientas para construir 3,5 3,5 proyectos. Sin embargo, parece que no se puede calcular dónde las herramientas son de 3,5 y está utilizando las herramientas 4.0. El resultado es que se está construyendo correctamente su proyecto 3.5 (con CLR 2.0.50727 conjuntos), pero la herramienta 4.0 sgen.exe está generando Ceoimage.Basecamp.XmlSerializers.dll como CLR 4.0.30319 montaje.

MSBuild utiliza el registro para obtener la ruta a las herramientas v3.5. Las tareas de MSBuild que requieren herramientas de SDK v3.5 caerá de vuelta al camino v4.0 si la ruta de las herramientas 3.5 no puede ser identificado - vistazo a la lógica utilizada para establecer la propiedad TargetFrameworkSDKToolsDirectory en C: \ Windows \ Microsoft. NET \ Framework \ v4.0.30319 \ Microsoft.NETFramework.props si usted está realmente interesado.

Puede diagnosticar y solucionar posibles problemas de registro de la siguiente manera:

Instalar Monitor de procesos y establecer un filtro para el acceso al registro de monitor por msbuild (clase de eventos: Registro, Nombre del proceso: msbuild.exe, todos los tipos de resultado)

Ejecutar su creación

Busca en el monitor de procesos para un acceso coincidente RegQueryValue "MSBuild \ ToolsVersions \ 4.0 \ SDK35ToolsPath". Tenga en cuenta que esto podría ser o bien estar bajo "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft" o "HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft"

Si usted tiene un vistazo a esta clave en el registro, se verá que es alias de otro valor de registro, por ejemplo, "$ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1 \ winsdk-NetFx35Tools-86 @ InstallationFolder)" Poco después de esto, es probable que vea un "nombre no encontrado" como resultado intentos msbuild para cargar el valor de la clave especificada.

Debe quedar claro qué teclas es necesario añadir / modificar desde aquí.

Hay algunas razones posibles por las que los valores del registro están mal. En mi caso, un problema con la instalación v7.1 SDK de Microsoft significaba que las claves de registro fueron nombrados de forma incorrecta, que ha sido identificado como un error aquí:

http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net -3-5-genera-equivocadas-recursos-incrustados

Answer 3

¿Es usted dependiente de nada específico 4.0?

Si se invoca MSBuild 4.0, obtendrá 4.0 herramientas. Si se invoca MSBuild 3.5, obtendrá 3,5 herramientas (que es lo que desea como usted es el anfitrión claramente en una CLR 2.0).

La otra opción es poner el CLR 4.0 en su servidor web. Si eso no es abierto, no debería tener ningún 4.0 targetted cosas en su corriente.