Can VS.NET XmlSerializers 2010 / MSBuild produrre per .NET 3.5 SP1?

Question

Ho appena aggiornato una soluzione VS 2008 contenente WinForms, biblioteche uso generale, e una web app per VS 2010, ma tutti i progetti ancora a indirizzare .NET 3.5 SP 1. Io uso questa tecnica per generare XmlSerializers per le mie librerie di uso generale. I WinForms app funziona bene. Quando i miei web app cerca di correre con queste librerie che fanno riferimento alle stesse XmlSerializers, getta il seguente:

  

Errore del server in '/ WebSubscribers'   Applicazione. Impossibile caricare il file o   montaggio   'Ceoimage.Basecamp.XmlSerializers' o   una delle sue dipendenze. questa assemblea   è costruito da un runtime più recente della   attualmente caricato runtime e non può essere   caricato. Descrizione: non gestita   verificata un'eccezione durante la   esecuzione della richiesta Web corrente.   Si prega di rivedere l'analisi dello stack per ulteriori   informazioni sull'errore e dove   ha avuto origine nel codice.

     

Dettagli eccezione: System.BadImageFormatException: Impossibile caricare il file o l'assembly 'Ceoimage.Basecamp.XmlSerializers' o una delle sue dipendenze. Questa assemblea è costruito da un runtime più recente rispetto alla fase di esecuzione attualmente caricato e non può essere caricato.

Ho guardato i riferimenti del XmlSerializer utilizzando .NET Reflector e vedere fa riferimento entrambe le versioni 2.0 e 4.0 di mscorlib così come i 3.5 e 4.0 versioni di System.Data.Linq. Stranamente, utilizza solo la versione 4.0 di System.Xml. Questo è probabilmente il mio problema proprio lì.

Come posso ottenere l'applicazione Web per l'esecuzione utilizzando questi XmlSerializers? Quando ho semplicemente eliminare tali XmlSerializers, la web app funziona benissimo. Questa è un'opzione, ma come posso forzare MSBUILD per creare serializzatori per una versione specifica del CLR?

Ecco il compito MSBuild aggiungo al file di progetto che le forze della creazione dei 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

ho scoperto che posso specificare esplicitamente il percorso gli strumenti del compito SGEN di utilizzare la versione 3.5, in questo modo:

<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 sarà (dovrebbe ...) l'uso di 3,5 strumenti per costruire 3.5 progetti. Tuttavia, sembra che non si può capire dove i 3,5 strumenti sono e sta usando gli strumenti 4.0. Il risultato è che sia correttamente costruendo il progetto 3.5 (con CLR 2.0.50727 assemblee), ma lo strumento 4.0 sgen.exe sta generando Ceoimage.Basecamp.XmlSerializers.dll come CLR 4.0.30319 assemblaggio.

MSBuild utilizza il Registro di sistema per ottenere il percorso per gli strumenti v3.5. I compiti MSBuild che richiedono strumenti SDK v3.5 cadrà indietro al percorso v4.0 se il percorso dei 3,5 utensili non può essere identificato - sguardo alla logica utilizzata per impostare la proprietà TargetFrameworkSDKToolsDirectory in C: \ Windows \ Microsoft. NET \ Framework \ v4.0.30319 \ Microsoft.NETFramework.props se siete veramente interessati.

È possibile diagnosticare e risolvere eventuali problemi di registrazione come segue:

Installa Process Monitor e impostare un filtro per l'accesso al registro monitor msbuild (classe Event: Registro Nome processo: MSBuild.exe, tutti i tipi di risultato)

Esegui la build

Cerca Process Monitor per un accesso corrispondente RegQueryValue "MSBuild \ ToolsVersions \ 4.0 \ SDK35ToolsPath". Si noti che questo potrebbe essere sia sotto sia "HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft" o "HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft"

Se si dispone di uno sguardo a questa chiave di registro, vedrete che essa alias un altro valore Registro di sistema, per esempio "$ (Registro: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SDK \ Windows \ v7.1 \ winsdk-NetFx35Tools-x86 @ InstallationFolder)" Poco dopo, probabilmente vedrete un "Nome non trovato" risultato come cerca MSBuild per caricare il valore dalla chiave specificata.

Dovrebbe essere chiaro che le chiavi è necessario aggiungere / modificare da qui.

Ci sono alcuni possibili motivi per cui i valori di registro sono sbagliate. Nel mio caso, un problema con l'installazione v7.1 di Microsoft SDK ha fatto sì che le chiavi di registro sono stati nominati in modo non corretto, che è stata identificata come un bug qui:

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

Answer 3

Sei affidamento su qualcosa di specifico 4.0?

Se si richiama MSBuild 4.0, si otterrà 4,0 strumenti. Se si richiama MSBuild 3.5, si otterrà 3,5 strumenti (che è ciò che si vuole come si sta chiaramente che ospita in un CLR 2.0).

L'altra opzione è quella di mettere il CLR 4.0 sul vostro server web. Se questo non è aperto, non dovreste avere alcun 4.0 roba mirato nel tuo flusso.