.NET CORE ALINK:警告 AL1073:引用的程序集 'mscorlib.dll' 针对不同的处理器

.NET CORE ALINK : warning AL1073: Referenced assembly 'mscorlib.dll' targets a different processor

我正在使用 VS2019 和 .NET CORE 2.2 我收到警告 AL1073

ALINK 警告 AL1073:引用的程序集 'mscorlib.dll' 针对不同的处理器

我知道这与问题很接近:ALINK : warning AL1073: Referenced assembly 'mscorlib.dll' targets a different processor

但是:

  1. 我使用的是 .NET CORE 2.2 而不是 4.x

  2. 那里提出的解决方案不适用于.NET core

特别是尝试添加:

<PropertyGroup> 
<TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\
</TargetFrameworkSDKToolsDirectory>
</PropertyGroup>

再次发出警告

Warning MSB3084 Task attempted to find "al.exe" in two locations. 1) Under the "\x64\" processor specific directory which is generated based on SdkToolsPath 2) The x86 specific directory under "\x64\" which is specified by the SDKToolsPath property. You may be able to solve the problem by doing one of the following: 1) Set the "SDKToolsPath" property to the location of the Microsoft Windows SDK. C:\Program Files (x86)\Microsoft Visual Studio19\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets

真奇怪,根据警告,位置是一样的!

另外:我很乐意在构建设置中取消警告,因为我的所有单元测试都通过了,但是将 1073 添加到列表中对仍然出现的 AL1073 警告没有影响。

或者,警告建议:将 "SDKToolsPath" 属性 设置为 Microsoft Windows SDK 的位置,我该怎么做?

更新以回答评论:这很难在简单的设置中重现。该项目特别引用了几个 Github 项目 (fo-dicom)。 fo-dicom 库使用为 32 位和 64 位平台构建的成像库。我确实尝试设置为 64 位,但没有帮助。我看到其他人在 VS 社区提出了警告抑制似乎有问题的错误: https://developercommunity.visualstudio.com/content/problem/224196/suppress-warnings-from-project-settings-build-does.html 。这个问题在没有跟进的情况下就被关闭了,MSFT 也表示 AL 1073 不会被修复,但我想禁用它!使用持续集成时不能有警告...

我现在正在尝试重新编译 .NET CORE 3.0 中的所有内容,如果可行,将提供更新。

更新: 在 .NET CORE 3.0 中重新编译后,我仍然遇到问题。

我还发现了这个问题的另一个原因(在其他 SO 文章中提到,但对于 .NET 4.x。事实上,我看到资源文件也出现了这个问题,但是对于 .NET Core 我们没有查看 "Generating Satellite Assemblies" 消息,因此很难 link 编译器警告资源文件的生成。

为了解决这个问题,我从 C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64 复制了 al.exe 文件到我的解决方案到 Tools64 并将以下内容添加到我的 .csproj

<PropertyGroup>
  <TargetFrameworkSDKToolsDirectory>..\Tools64</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>

将 SDKToolsDirectory 直接设置到原始位置无效。在我使用 devops 构建服务器进行持续集成的情况下,不会额外使用绝对路径(路径可能不同)。在本地复制 al.exe 工具似乎是一个可以接受的解决方案。

我能够解决这个问题,在我的情况下,我似乎需要两件事:

  1. gofal3 的建议,我引用了 .NET core fo-dicom 包和 fo-dicom 依赖项(但不是 fo-dicom 桌面)。

  2. 我似乎对 Microsoft.ServiceFabric 有一个旧的引用,似乎该引用需要 64 位,否则我们会收到警告 (Azure Service Fabric 32 bit support)

Lance:我尝试了博客中的建议来删除警告,但这对我的情况没有帮助。请注意,从警告中我得到的路径是相同的。

旧的解决方法仍然有效,但必须在 GenerateSatelliteAssemblies 目标之前完成。当它作为 PropertyGroup 添加到项目文件中时,将被解释为时已晚,从而导致两个位置警告。

Marcel Veldhuizen所示,可以通过添加以下目标使其工作:

<Target Name="FixAL1703Warning" BeforeTargets="GenerateSatelliteAssemblies" Condition="'$(PlatformTarget)' == 'x64'">
  <Message Text="Adjusting SDK tools directory to use x64 version of AL.EXE">
  <PropertyGroup>
    <TargetFrameworkSDKToolsDirectory>$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>
</Target>

注意:GitHub 上的 msbuild 存储库中目前有关于此的 open issue