Can VS.NET 2010 / MSBUILD produzieren XmlSerializers für .NET 3.5 SP1?

Question

Ich habe ein Upgrade eine VS 2008-Lösung WinForms, die allgemeinen Gebrauch Bibliotheken enthält, und einen Web-App VS 2010, aber alle Projekte zielen nach wie vor .NET 3.5 SP 1. Ich Verwendung diese Technik XmlSerializers für meine allgemeinen Gebrauch Bibliotheken zu generieren. Die WinForms App läuft gut. Wenn meine Web App versucht mit diesen Bibliotheken zu laufen, die die gleichen XmlSerializers verweisen, wirft es die folgenden:

  

Serverfehler in '/ WebSubscribers'   Anwendung. Konnte nicht geladen werden Datei oder   Versammlung   ‚Ceoimage.Basecamp.XmlSerializers‘ oder   eine ihrer Abhängigkeiten. diese Baugruppe   wird von einer Laufzeit neuer als die eingebauten   zur Zeit Laufzeit geladen und kann nicht sein,   geladen. Beschreibung: Eine nicht behandelte   Ausnahme trat während der   Ausführung der aktuellen Webanforderung.   Überprüfen Sie die Stapelüberwachung, um weitere   Informationen über den Fehler und wo   es entsteht im Code.

     

Ausnahmedetails: System.BadImageFormatException: Datei konnte nicht geladen werden oder Assembly ‚Ceoimage.Basecamp.XmlSerializers‘ oder eine ihrer Abhängigkeiten. Diese Anordnung wird durch eine Laufzeit neuer als die aktuell geladene Laufzeit gebaut und nicht geladen werden kann.

Ich habe in der XmlSerializer Referenzen sah mit .NET Reflector und sehen es beide verweist auf die 2.0 und 4.0 Versionen von mscorlib sowie die 3.5 und 4.0 Versionen von System.Data.Linq. Merkwürdigerweise verwendet er nur die 4.0-Version von System.Xml. Das ist wahrscheinlich mein Problem recht.

Wie kann ich das Web-App mit diesem XmlSerializers zu laufen? Wenn ich einfach diese XmlSerializers löscht, läuft der Web-App in Ordnung. Dies ist eine Option, aber wie kann ich MSBUILD zwingen Serializer für eine bestimmte Version des CLR zu erstellen?

Hier ist die MSBuild Aufgabe, die ich zu Projektdateien hinzufügen, dass Kräfte der Schaffung der 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

Ich fand ich die SGEN Aufgabe der explizit Tool Pfad angeben kann die Version 3.5 zu verwenden, etwa so:

<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 wird (sollte ...) Verwendung 3.5 Tools 3.5-Projekte zu bauen. Allerdings sieht es aus wie es nicht arbeiten können, wo die 3.5-Tools sind und unter Verwendung der 4.0-Tools. Das Ergebnis ist, dass es richtig ist Ihr 3.5-Projekt des Bau (mit CLR 2.0.50727 Baugruppen), aber das 4.0 sgen.exe Werkzeug erzeugt Ceoimage.Basecamp.XmlSerializers.dll als CLR 4.0.30319 Montag.

MSBuild verwendet die Registrierung, den Pfad zu den v3.5 Tool zu erhalten. Die MSBuild Aufgaben, die v3.5 SDK-Tools erfordern werden den v4.0 Weg zurückfallen, wenn der Pfad zu den 3,5-Tool nicht identifiziert werden kann - Blick auf der Logik verwendet, um die TargetFrameworkSDKToolsDirectory Eigenschaft in C einzustellen: \ Windows \ Microsoft. NET \ Framework \ v4.0.30319 \ Microsoft.NETFramework.props wenn du bist wirklich interessiert.

Sie können diagnostizieren und mögliche Probleme in der Registrierung beheben, wie folgt:

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

Führen Sie Ihren Build

Suchen Sie Process Monitor für einen RegQueryValue Zugang matching "MSBuild \ ToolsVersions \ 4.0 \ SDK35ToolsPath". Beachten Sie, dass dies entweder unter "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft" sein könnte oder "HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft"

Wenn Sie einen Blick auf diesen Schlüssel in der Registrierung haben, werden Sie sehen, dass es einen anderen Registrierungswert Aliase, z.B. "$ (Registry: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDKs \ Windows \ v7.1 \ winsdk-NetFx35Tools-x86 @ Installation)" Kurz danach, werden Sie wahrscheinlich ein „Name nicht gefunden“ sehen Ergebnis als msbuild versucht angegeben, den Wert aus dem Schlüssel zu laden.

Es sollte klar sein, welche Tasten Sie hinzufügen müssen / Änderung von hier.

Es gibt einige mögliche Gründe, warum die Registrierungswerte falsch sind. In meinem Fall ein Problem mit der v7.1 Installation Microsoft SDK dazu geführt, dass die Registrierungsschlüssel falsch benannt wurden, die als Fehler hier identifiziert wurden:

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

Answer 3

Sind Sie auf etwas 4.0 spezifischen angewiesen?

Wenn Sie invoke MSBuild 4.0, werden Sie 4.0 Tools. Wenn Sie invoke MSBuild 3.5, werden Sie 3.5-Tools zu bekommen (das ist, was Sie wollen, wie Sie klar in einer 2,0-CLR-Hosting).

Die andere Option ist die 4.0 CLR auf Ihrem Webserver zu setzen. Wenn das nicht offen ist, sollten Sie nicht jede 4.0 targetted Sachen in Ihrem Stream haben.