4

最近、すべてのテストプロジェクトをdotnet4からdotnet3.5に切り替えました（CLR 2.0でコードをテストしたいため（ここを参照）。ほとんどの場合は正常に機能しますが、1つのテストプロジェクトはIWshRuntimeLibraryに依存しています。これは次のcsprojで指定されます。スニペット：

<COMReference Include="IWshRuntimeLibrary">
  <Guid>{F935DC20-1CF0-11D0-ADB9-00C04FD58A0B}</Guid>
  <VersionMajor>1</VersionMajor>
  <VersionMinor>0</VersionMinor>
  <Lcid>0</Lcid>
  <WrapperTool>tlbimp</WrapperTool>
  <Isolated>False</Isolated>
  <EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>

テストプロジェクトを「AnyCPU」としてビルドします。テストプロジェクトが.Net4の場合、これによりANYCPU相互運用DLLが生成されるようでした。現在は.Net3.5であり、相互運用DLLはx86であり、System.BadImageFormatException64ビットプラットフォームで実行時に発生します。この問題は、テストプロジェクトをダウングレードする前には発生しませんでした。

4

2 に答える 2

9

Visual Studio でタイプ ライブラリをインポートすると、常に相互運用アセンブリ ヘッダーに 32 ビット フラグが設定されます。これは、生成されたアセンブリで corflags.exe を実行することで確認できます。

VS からのプラットフォームに依存しない相互運用ライブラリの作成はサポートされていません。Tlbimp.exe を自分で実行する必要があります。Visual Studio コマンド プロンプトを使用して、プロジェクト ディレクトリに移動します。次に、次のコマンドを実行します。

Tlbimp /machine:Agnostic c:\windows\system32\wshom.ocx

そして、生成された Interop.IWshRuntimeLibrary.dll への参照を [プロジェクト] + [参照の追加]、[参照] タブで追加します。ソース管理で DLL をチェックインしても問題ありません。COM インターフェイスは固定されています。メイン EXE プロジェクトのプラットフォーム ターゲットを x86 に設定することも、別の回避策です。

于 2012-02-06T14:46:31.353 に答える
0

csproj ファイルでProcessorArchitectureプロパティを明示的に設定することで、プラットフォームに依存しない COMReference を生成するように MSBuild を取得できました。Agnostic

<PropertyGroup>
  <ProcessorArchitecture>Agnostic</ProcessorArchitecture>
</PropertyGroup>

この値をtlbimp.exe /machine flagに渡す Microsoft.Common.CurrentVersion.targets のResolveComReference MSBuild タスクを見て、それを理解しました。

そうは言っても、私は Hans Passant のソリューションを使用することにしました。つまり、DLL を手動で生成し、それをソース管理に追加するのは、ビルド サーバーに適しているからです。

于 2020-06-24T06:54:17.603 に答える