質問

Winforms、General使用ライブラリ、Webアプリを含むVS 2008ソリューションを2010年VSにアップグレードしましたが、すべてのプロジェクトはまだ.NET 3.5 SPをターゲットにしています。 このテクニック 私の一般的なライブラリのためにXMLSERIALIZERSを生成します。 WinFormsアプリは正常に実行されます。私のWebアプリが同じXMLSERIALIZERSを参照するこれらのライブラリを使用して実行しようとすると、以下をスローします。

「/websubscribers」アプリケーションのサーバーエラー。ファイルまたはアセンブリ「ceoimage.basecamp.xmlserializers」またはその依存関係の1つをロードできませんでした。このアセンブリは、現在ロードされているランタイムよりも新しいランタイムによって構築されており、ロードできません。説明:現在のWeb要求の実行中に、未解決の例外が発生しました。エラーの詳細については、コードの発信先の詳細については、スタックトレースを確認してください。

例外の詳細:System.BadimageFormateXception:ファイルまたはアセンブリ 'ceoimage.basecamp.xmlserializersまたはその依存関係の1つをロードできませんでした。このアセンブリは、現在ロードされているランタイムよりも新しいランタイムによって構築されており、ロードできません。

XMLSerializerの参照を使用して見ました .NETリフレクター 2.0と4.0の両方のバージョンの両方を参照してください mscorlib 3.5および4.0バージョンと同様に System.Data.Linq. 。奇妙なことに、それは4.0バージョンのみを使用します System.Xml. 。それはおそらく私の問題です。

これらのXMLSerializersを使用してWebアプリを実行するにはどうすればよいですか?これらのXMLSerializersを削除するだけで、Webアプリは正常に実行されます。これはオプションですが、MSBuildにCLRの特定のバージョン用にシリアル化器を作成するように強制するにはどうすればよいですか?

XMLSerializersの作成を強制するプロジェクトファイルに追加するMSBUILDタスクは次のとおりです。

<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>
役に立ちましたか?

解決 3

SGENタスクのツールパスを明示的に指定して、次のように3.5バージョンを使用できることがわかりました。

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

他のヒント

MSBUILD 4は3.5ツールを使用して3.5プロジェクトを構築します。ただし、3.5ツールがどこにあるのか、4.0ツールを使用しているように見えます。その結果、3.5プロジェクト(CLR 2.0.50727アセンブリを使用)を正しく構築しますが、4.0 SGEN.EXEツールはCEOIMAGE.BASECAMP.XMLSERIALIZERS.DLLをCLR 4.0.30319アセンブリとして生成しています。

MSBuildはレジストリを使用してV3.5ツールへのパスを取得します。 V3.5 SDKツールを必要とするMSBUILDタスクは、3.5ツールへのパスを識別できない場合、V4.0パスに戻ります。C: Windows MicrosoftのTargetFrameWorksDKToolsDirectoryプロパティを設定するために使用されるロジックを調べます。 net framework v4.0.30319 microsoft.netframework.propsあなたが本当に興味があるなら。

次のように、可能なレジストリの問題を診断して修正できます。

プロセスモニターをインストールし、MSBUILDによるレジストリアクセスを監視するフィルターを設定します(イベントクラス:レジストリ、プロセス名:msbuild.exe、あらゆるタイプの結果)

ビルドを実行します

「msbuild toolsversions 4.0 sdk35toolspath」の一致するregqueryvalueアクセスの検索プロセスモニター。これは、「hkey_local_machine software microsoft」または「hkey_local_machine software wow6432node microsoft」のいずれかにある可能性があることに注意してください。

レジストリのこのキーを見ると、別のレジストリ値、例: "$(registry:hkey_local_machine software microsoft microsoft sdks windows v7.1 winsdk-netfx35tools-x86@ installationFolder)「この後まもなく、MSBuildが指定されたキーから値をロードしようとすると、「名前が見つかりません」結果が表示されるでしょう。

ここから追加 /修正する必要があるキーが明確になるはずです。

レジストリ値が間違っている理由はいくつかあります。私の場合、Microsoft SDK v7.1のインストールの問題は、レジストリキーに誤って名前が付けられたことを意味し、ここではバグとして識別されています。

http://connect.microsoft.com/visualstudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-3-5-5-5-5-5-5-5-5-ロング - 具体的にembedded-資力

4.0固有のものに依存していますか?

MSBUILD 4.0を呼び出すと、4.0ツールが表示されます。 MSBUILD 3.5を呼び出すと、3.5ツールが表示されます(2.0 CLRで明確にホストしているため、必要なものです)。

もう1つのオプションは、4.0 CLRをWebサーバーに配置することです。それが開いていない場合は、ストリームに4.0のターゲットを絞ったものがないはずです。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top