visual studio 2010 - Cómo establecer la ruta de acceso de SGEN en Msbuild al framework de destino 3.5

visual-studio-2010

Question

Acabo de actualizar un proyecto de VS2008 a VS2010, pero todavía estoy apuntando al framework 3.5.

En mi archivo de proyecto tengo una tarea personalizada para ejecutar SGEN para generar mi XmlSerializers.dll. Sin embargo, la versión de sgen que se ejecuta se dirige al marco 4.0. Como resultado, cuando ejecuto mi aplicación recibo el mensaje de error:

"No se pudo cargar el archivo o el ensamblaje ''XXXX.XXXX.XmlSerializers'' o una de sus dependencias. Este ensamblado está creado por un motor de ejecución más nuevo que el tiempo de ejecución actualmente cargado y no se puede cargar".

La tarea de Sgen se ve así:

 <Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can''t figure out how to force the SGen task. -->
<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>

Está el ToolPath = "$ (SGenToolPath)" . ¿Cómo hago para ejecutar la versión que apunta a 3.5?

Hay una pregunta similar aquí pero no me ayuda mucho.

Answer 1

@Craig: ¿instaló manualmente el framework 7.0A en su máquina de compilación? Si es así, su problema puede ser su configuración de registro y no msbuild. Eche un vistazo a LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath y asegúrese de que la clave reg a la que se hace referencia allí sea válida. (Sugerencia: asegúrese de que -x86 esté allí solo si existe la clave -x86).

Answer 2

MSBuild usa el registro para obtener la ruta a las herramientas v3.5. Las tareas de MSBuild que requieren herramientas v3.5 SDK recurrirán a la ruta v4.0 si no se puede identificar la ruta a las herramientas 3.5: consulte la lógica utilizada para establecer la propiedad TargetFrameworkSDKToolsDirectory en C: / Windows / Microsoft. NET / Framework / v4.0.30319 / Microsoft.NETFramework.props si realmente está interesado.

Puede diagnosticar y solucionar este problema de la siguiente manera:

Instale Process Monitor y configure un filtro para supervisar el acceso al registro por msbuild (Clase de evento: Registro, Nombre del proceso: msbuild.exe, todos los tipos de resultados).

Ejecuta tu construcción.

Search Process Monitor para un acceso RegQueryValue que coincida con "MSBuild / ToolsVersions / 4.0 / SDK35ToolsPath". Tenga en cuenta que esto podría estar en "HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft" o "HKEY_LOCAL_MACHINE / SOFTWARE / Wow6432Node / Microsoft".

Si observa esta clave en el registro, verá que alía otro valor de registro, por ejemplo, "$ (Registro: HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Microsoft SDKs / Windows / v7.1 / WinSDK-NetFx35Tools-x86 @ InstallationFolder) "Poco después de esto, probablemente verá un resultado de" NAME NOT FOUND ". Si observa dónde debería estar la clave esperada, verá que no coinciden con la clave solicitada (faltan guiones y posiblemente ninguna tecla que termine con "-86").

Debe quedar claro lo que necesita corregir. Elegí exportar las claves incorrectas, editar el archivo .reg y ejecutarlo para crear las claves correctas.

Una causa de las entradas de registro no válidas podría ser un error con la instalación de Microsoft SDK v7.1:

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

Answer 3

Encontré que esta es la manera más fácil y funciona con: <GenerateSerializationAssemblies> On </ GenerateSerializationAssemblies>

<SGenToolPath>C:/Program Files/Microsoft SDKs/Windows/v6.0A/bin</SGenToolPath>

Answer 4

El problema es $(SGenToolPath) no lo establece MSBuild. Si usa $(TargetFrameworkSDKToolsDirectory) , intentará resolver la ruta en función de $(TargetFrameworkVersion) .

Es útil hacer uso de etiquetas para la depuración de estilo printf (). Agregue lo siguiente temporalmente.

<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);@(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<Message Text="SGenPath: $(SGenPath)" Importance="high"/>
<Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
<Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>

Answer 5

Lo he solucionado configurando manualmente el ToolPath para que apunte a la versión anterior (versión 2.0.50727.3038) de sgen.exe

En mi máquina, esto está en: C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin

Cambié el atributo ToolPath para que sea:

ToolPath="C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Bin"

y esto resolvió el problema.

Parece que, de forma predeterminada, está ejecutando la nueva versión de Framework 4.0 en: C: / Archivos de programa (x86) / Microsoft SDKs / Windows / v7.0A / Bin / NETFX 4.0 Tools

Espero que esto ayude a alguien más.