web-dev-qa-db-ja.com

ALINK:警告AL1073:参照されたアセンブリ 'mscorlib.dll'は異なるプロセッサを対象としています

VS2013と.Net 4.5.1を使用しています(最近移行されましたが、このエラーは.Net 4.0から発生しています)。このエラーは、プラットフォームターゲットx64でプロジェクトをコンパイルする場合にのみ発生します。これは本当に実行時に壊れるエラーですか? MSBUILDがこのmrcorlib.dllを適切に解決しないのはなぜですか?これは、VS2010で作成されたプロジェクトでのみ発生し、新しく作成されたプロジェクトでは発生しません。ここに何が欠けていますか。サードパーティのアセンブリはすべてx64ビットです。

TeamCityビルドサーバーで、次のエラーが表示されます。

GenerateSatelliteAssemblies
[17:01:18]AL
[17:01:18]C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\AL.exe /culture:de /keyfile:..\..\MyApp.snk /out:obj\x64\Release\de\MyApp.Hardware.Softing.resources.dll /platform:x64 /template:obj\x64\Release\MyApp.Hardware.Softing.dll /embed:obj\x64\Release\MyApp.Hardware.Softing.Properties.Resources.de.resources
[17:01:18]ALINK warning AL1073: Referenced Assembly 'mscorlib.dll' targets a different processor
26
jero2rome

@ jero2romeが参照するバグは「修正しない」としてクローズされますが、VS2015 RC w。NET 4.6はこの警告を出力しなくなりました。

VS2013/.NET 4.5.1から、同じ問題が表示されます。

GenerateSatelliteAssemblies:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\AL.exe /culture:zh-CHT /out:obj\x64\Debug\zh-CHT\MyComponent.resources.dll /platform:x64 /template:obj\x64\Debug\MyComponent.dll /embed:obj\x64\Debug\MyComponent.Resources.string.zh-CHT.resources
ALINK : warning AL1073: Referenced Assembly 'mscorlib.dll' targets a different processor [c:\svn\project\MyComponent.csproj]

VS2015 RC/.NET 4.6では、警告は出力されません。

GenerateSatelliteAssemblies:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64\AL.exe /culture:zh-CHT /out:obj\x64\Debug\zh-CHT\MyComponent.resources.dll /platform:x64 /template:obj\x64\Debug\MyComponent.dll /embed:obj\x64\Debug\MyComponent.Resources.string.zh-CHT.resources
7
dirtybird

回避策は次のとおりです。

この問題は、構築しようとしているプラ​​ットフォーム(またはビット数)に一致するAL.EXEを使用することで回避できます。つまり、x64をビルドしているときに、次のようなパスでAL.EXEを使用しようとしていることがわかります。

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools

AL.exeのx64バージョンを使用できるようになれば、問題はなくなります。つまり、次のようなパスでAL.EXEを使用します。

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools\x64

Msbuildは、TargetFrameworkSDKToolsDirectoryを使用してこのパスを見つけます。したがって、x86をビルドするときにこのディレクトリが正しいディレクトリであるという仮定を使用すると、以下の回避策は、x64をビルドするときにx64サブディレクトリをパスに追加し、それ以外はそのままにします。

  1. MsBuildAL1073WarningWorkaround.targetsファイルを作成し(名前は関係ありません)、プロジェクトに追加します。次の内容があります。

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0" xmlns="http://schemas.Microsoft.com/developer/msbuild/2003">
      <PropertyGroup>
        <TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
      </PropertyGroup>
    </Project>  
    
  2. .csprojファイルを編集して、このファイルをファイルの終わり近くにインポートします(「ビルドプロセスを変更するには...」というコメントが表示されます)。

     <Import Project="MsBuildAL1073WarningWorkaround.targets" />
     <!-- To modify your build process... -->
    
30
Matt Smith

これらの警告は、ソリューションにローカライズサテライトアセンブリ(。resxファイル)を含むプロジェクトに表示されます。

これはMicrosoft側からのバグであり、2017年8月現在、Microsoftはまだ修正していません。

MSフィードバック ページからの引用は次のとおりです。

これは、.NETフレームワークバイナリalink.dllの論理的なバグが原因です。ただし、この問題の影響は限定的であり、このツールにはサービスの水準が非常に高いという事実があるため、この問題に対処するための変更は行いません。

よろしく、

Ed Maurer開発リーダー、VB&C#コンパイラ

11
JerryGoyal

この警告は無視しても問題ありません。 .Netは64ビットマシンの実行時に正しい64ビットアセンブリをロードするためです。それでも、Microsoftはこの問題に対する確固たる答えを出すことができます。警告を無駄にする時間が不必要でした。

8
jero2rome

同じ問題が発生し、Matt Smithの回避策( https://stackoverflow.com/a/41945190/350676 )になりましたが、1つの修正で機能しました。

MsBuildの機能/バグ( https://stackoverflow.com/a/1367309/350676 )により、ステップ1で説明したターゲットファイルを変更する必要がありました。

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.Microsoft.com/developer/msbuild/2003">
    <Target Name="MsBuildAL1073WarningWorkaround" BeforeTargets="BeforeBuild" >
        <PropertyGroup Condition="'$(Platform)' == 'x64'">
            <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(Platform)\</TargetFrameworkSDKToolsDirectory>
        </PropertyGroup>
    </Target>
</Project>
5

マットの答えへの追加(コメントを追加するのに十分な評判がありません):私は信じています

ファイルの終わり近く

行の直後

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

私はテストしましたが、上記の行が$ TargetFrameworkSDKToolsDirectoryの(再)定義の前にある場合、AL1073警告はなくなります。それ以外の場合は持続します。

3
Levente Koncz