Wie man SGGEN Werkzeugweg in Msbuild zum Ziel 3.5 Rahmenwerk einstellt

Question

Ich habe gerade ein Projekt von VS2008 auf VS2010 aktualisiert, aber ich ziele immer noch auf das 3.5 Framework.

In meiner Projektdatei habe ich eine benutzerdefinierte Aufgabe, um SGEN zu starten, um meine XmlSerializers.dll zu generieren. Die Version von sgen, die ausgeführt wird, zielt jedoch auf das Framework 4.0 ab. Als Ergebnis, wenn ich meine Anwendung ausführen, erhalte ich die Fehlermeldung:

"Konnte Datei oder Assembly 'XXXX.XXXX.XmlSerializers' oder eine seiner Abhängigkeiten nicht laden. Diese Assembly wird durch eine Laufzeit neueren als die derzeit erstellt Laufzeit geladen und kann nicht geladen werden. "

Die Sgen Aufgabe sieht wie folgt aus:

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

Es gibt die ToolPath = "$ (SGenToolPath)". Wie kann ich die Version ausführen, die 3.5 anvisiert?

Es gibt eine ähnliche Frage here, aber es hilft mir nicht viel.

Answer 1

ich dies manuell gelöst, indem die ToolPath Konfiguration zur alten (Version 2.0.50727.3038) Version von sgen.exe

Auf meinem Rechner zu zeigen, ist dies in: C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ V7.0A \ Bin

ich änderte das ToolPath Attribut zu sein:

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

und damit das Problem behoben.

Es scheint, standardmäßig es läuft die neue 4.0 Framework-Version in: C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ V7.0A \ Bin \ netfx 4.0 Werkzeuge

hoffe, das hilft jemand sonst.

Answer 2

@Craig - Sie haben das 7.0A-Framework manuell auf Ihrem Build-Rechner installiert. Wenn dies der Fall ist, liegt Ihr Problem möglicherweise in den Registrierungseinstellungen und nicht in msbuild. Sehen Sie sich LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath an und stellen Sie sicher, dass der reg-Schlüssel, auf den verwiesen wird, gültig ist. (Tipp: Stellen Sie sicher, dass der -x86 gibt es nur, wenn der -x86 Schlüssel vorhanden ist.)

Answer 3

Ich fand dies der einfachste Weg zu sein, und es funktioniert mit: <GenerateSerializationAssemblies> Auf </GenerateSerializationAssemblies >

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

Answer 4

MSBuild verwendet die Registrierung, um den Pfad zu den v3.5-Tools abzurufen. Die MSBuild-Tasks, die v3.5-SDK-Tools erfordern, greifen auf den v4.0-Pfad zurück, wenn der Pfad zu den 3.5-Tools nicht identifiziert werden kann. Beachten Sie die Logik zum Festlegen der TargetFrameworkSDKToolsDirectory-Eigenschaft in C: \ Windows \ Microsoft. NET \ Framework \ v4.0.30319 \ Microsoft.NETFramework.props, wenn Sie wirklich interessiert sind.

Sie können dieses Problem diagnostizieren und beheben, wie folgt:

Process Monitor installieren und einen Filter einrichten, um Zugriff auf die Registry von msbuild zu überwachen (Ereignisklasse: Registry, Prozessname: msbuild.exe, alle Arten von Ergebnis).

Führen Sie Ihren Build.

Suchprozessmonitor für einen RegQueryValue-Zugriff, der "MSBuild \ ToolsVersions \ 4.0 \ SDK35ToolsPath" entspricht. Beachten Sie, dass das unter "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft" oder "HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft" sein kann.

Wenn Sie sich diesen Schlüssel in der Registrierung ansehen, werden Sie sehen, dass er einen anderen Registrierungswert, z. "$ (Registrierung: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1 \ WinSDK-NetFx35Tools-x 86 @ InstallationFolder)" Kurz danach werden Sie wahrscheinlich ein "NAME NICHT GEFUNDEN" -Ergebnis sehen. Wenn Sie sich ansehen, wo der erwartete Schlüssel sein sollte, sehen Sie, dass sie nicht dem angeforderten Schlüssel entsprechen (fehlende Bindestriche und möglicherweise kein Schlüssel, der mit "-86" endet).

Es sollte klar sein, was Sie korrigieren müssen. Ich entschied mich, die falschen Schlüssel zu exportieren, die REG-Datei zu bearbeiten und es auszuführen, um die richtigen Schlüssel zu erstellen.

Eine Ursache für ungültige Registry-Einträge könnte ein Fehler mit dem Microsoft SDK v7.1 Installation sein:

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

Answer 5

Das Problem ist $(SGenToolPath) nicht von MSBuild gesetzt. Wenn Sie $(TargetFrameworkSDKToolsDirectory) verwenden, wird versucht, den Pfad basierend auf $(TargetFrameworkVersion) aufzulösen.

Es ist hilfreich, Tags für printf() - Stil Debuggen zu verwenden. Fügen Sie das Folgende zeitlich hinzu.

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