Cómo configurar la ruta de acceso de SGEN en Msbuild al framework de destino 3.5

Acabo de actualizar un proyecto de VS2008 a VS2010, pero todavía estoy apuntando al framework 3.5.Cómo configurar la ruta de acceso de SGEN en Msbuild al framework de destino 3.5

En mi archivo de proyecto tengo una tarea personalizada para ejecutar SGEN y generar mis 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 ensamblado 'XXXX.XXXX.XmlSerializers' o una de sus dependencias. Este ensamblado está creado por un tiempo de ejecución más nuevo que el actual tiempo de ejecución cargado y no se puede cargar ".

La tarea Sgen se parece a esto:

<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>

Ahí está la trayectoria de la herramienta = "$ (SGenToolPath)". ¿Cómo hago para ejecutar la versión que apunta a 3.5?

Hay una pregunta similar here pero no me ayuda mucho.

Fuente

2010-05-01 Craig Shearer

Nota rápida a otros que terminan aquí basado en el mensaje de excepción: si usted no necesita los XmlSerializers montaje puede simplemente desactivar su creación en la pestaña de construcción del proyecto. – Myster

P.S. si configura Generar conjunto de serialización en "off", recuerde hacerlo para configuraciones de versión y depuración (o relevantes). – Myster

He resuelto este configurando manualmente la trayectoria para que apunte a la versión anterior (versión 2.0.50727.3038) de sgen.exe

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

me cambió el atributo trayectoria de la herramienta a ser:

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

y esto resuelve el problema.

Parece, por defecto, se está ejecutando la nueva versión 4.0 marco en: C: \ Archivos de programa (x86) \ Microsoft SDKs \ Windows \ v7.0A \ Bin \ netfx 4.0 Herramientas

Espero que esto ayude a alguien más.

Fuente

2010-05-02 10:26:04

Ayuda. Gracias. – Marko

Gracias Craig! ¡Esto me ayudó mucho! – Mike

¿Dónde configura ToolPath? – chief7

@Craig - ¿Has instalado manualmente el framework 7.0A en tu 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. (Consejo: Asegúrese de que el -x86 es allí sólo si existe la clave -x86.)

Fuente

2010-06-30 19:14:18 pattersonc

He encontrado que esto es la forma más fácil y funciona con: <GenerateSerializationAssemblies> En </GenerateSerializationAssemblies >

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

Fuente

2010-12-14 21:19:52

Funcionó muy bien para nosotros, en mi opinión, esto es mejor porque le permite especificar la versión de Sgen para usar * PER PROJECT *. Tenga en cuenta que Visual Studio no tiene UI para esta configuración y, si abre el archivo de proyecto en VS, se muestra como no válido. Sin embargo, funciona. Otro recordatorio, especifíquelo para * ¡LIBERACIÓN Y DEPURACIÓN *! –

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:

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

Ejecuta tu construcción.

Search Process Monitor para un acceso de 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 alias otro valor de registro, p. "$ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1 \ WinSDK-NetFx35Tools-x86 @ InstallationFolder)" Poco después de esto, probablemente verá un resultado "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 de las causas de las entradas inválidas del registro podría ser un error con la instalación del SDK v7.1 de Microsoft:

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

Fuente

2011-04-18 10:43:52

@DanMalcom Esa es una respuesta muy completa, pero en mi caso, y posiblemente en este caso de los usuarios, el problema real no era configurar ToolPath en $ (TargetFrameworkSDKToolsDirectory). Si pudieras editar tu respuesta basándote en eso. Eliminaré mi respuesta a continuación. –

@Justin Si tiene el problema de registro que describí, entonces $ (TargetFrameworkSDKToolsDirectory) terminará siendo incorrecto, p. 4.0 Herramientas (tiempo de ejecución de v4) para un marco de orientación 3.5 de compilación (tiempo de ejecución v2.0). Si las herramientas SDK están instaladas correctamente, no debería tener que establecer $ (ToolPath), ya sea en $ (TargetFrameworkSDKToolsDirectory) o en una ruta codificada. –

@DanMalcolm, esto fue muy útil para mí, ¡gracias! –

El problema es $(SGenToolPath) no está definida por MSBuild. Si usa $(TargetFrameworkSDKToolsDirectory), intentará resolver la ruta basándose en $(TargetFrameworkVersion).

Es útil utilizar 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"/>

Fuente

2012-07-12 14:43:35

Cómo configurar la ruta de acceso de SGEN en Msbuild al framework de destino 3.5

Respuesta

Cuestiones relacionadas