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

Question

I am using VS2019 and .NET CORE 2.2 I am getting the warning AL1073

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

I know this is close to the question as: ALINK : warning AL1073: Referenced assembly 'mscorlib.dll' targets a different processor

BUT:

1. I am on .NET CORE 2.2 not on 4.x

2. The solutions proposed there do not work on .NET core

in particular, attempting to add:

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

gives another warning

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 Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets

Really strange, since the location is the same according to the warning!

Additionally: I would be happy to suppress the warning in the build settings, since all my unit tests pass, but adding 1073 to the list has no effect on the AL1073 warning which still appears.

Alternatively, the warning suggests: Set the "SDKToolsPath" property to the location of the Microsoft Windows SDK, how can I do that?

UPDATE to answer comment: This is hard to reproduce in a simple setup. the project references several Github projects (fo-dicom) in particular. The fo-dicom lib uses imaging libs built for 32 and 64 platforms. I did try setting to 64bits but it did not help. I saw other people raise the bug in VS community that the suppression of warning seems buggy: https://developercommunity.visualstudio.com/content/problem/224196/suppress-warnings-from-project-settings-build-does.html . That issue was closed without follow-up also MSFT stated that the AL 1073 will not be fixed, but I would like to disable! can't have warnings when using continuous integration...

I am now trying to recompile everything in .NET CORE 3.0, will provide an update if it works.

UPDATE: After recompiling in .NET CORE 3.0 I still have the issue.

I also found another cause of this issue (mentione in other SO articles, but for .NET 4.x. Indeed I saw that the issue came up also with resource files however with .NET Core we do not see the "Generating Satellite Assemblies" message so it is hard to link the compiler warning to the generation of the resource files.

In order to solve the issue I copied the al.exe file from C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64 into my solution into Tools64 and added the following to my .csproj

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

Setting the SDKToolsDirectory directly to the original location did not work. Additional using the absolute path will not in my case where we use a devops build server for continuous integration (paths may be different). copying the al.exe tool locally seems to be an acceptable solution.

Mf

Hi, any update for this issue? Could you share some details to help reproduce this issue? If you create a new .net core project, and set its target platform to x64, this issue occurs? I can't reproduce this issue for further trouble-shooting :( – Collincolline

I updated the question to answer your comment, since there was not enough place in the comment. – Mf

fo-dicom includes the native codec libraries only for platforms Desktop and Universal. For platform NetCore fo-dicom does not offer the codecs. So are you referencing the desktop-assembly compiled for netframework452 from within your netcore assembly? Maybe that causes the warning. – Chauncey

if you need support for all codecs and compile on netCore then use the great packge from Efferent: nuget.org/packages/Efferent.Native – Chauncey

disclosure: i am contributor of fo-dicom – Chauncey

Lance which blog? I think you forgot the link. @gofal I will investigate according to your guidance the fo-dicom references – Mf

@Chauncey when referencing fo-dicom nu-get packages I see there is a fo-dicom and a fo-dicom.NetCore, do I need both? I saw the readme here: github.com/fo-dicom/fo-dicom, fo-dicom is the "dependencies" and .NetCore is "Core library for .NET Core applications, Level 1.3 and higher", but not so clear if both are needed, I will add fo-dicom tag as issue may well be with these references. – Mf

Maybe this blog can make some help, but I'm not certainly sure about that since I can't reproduce the issue to check it directly :( – Collincolline

if you reference nugetpackage "fo-dicom", then visual studio should select the correct version, depending on your project type. You can explicitly select "fo-dicom.Desktop" or "fo-dicom.netCore" alternatively. So you do not need both of them. – Chauncey

Answer 1

I was able to solve the issue, it seems in my case that I needed 2 things:

1. Suggestion from gofal3, I referenced .NET core fo-dicom package and fo-dicom dependencies (but not fo-dicom desktop).

2. It seems I had an old reference to Microsoft.ServiceFabric, it seems that that reference requires 64bit else we get the warning (Azure Service Fabric 32 bit support)

Lance: I tried the suggestoins in the blog to remove the warning, but that didn't help in my case. note that from the warning I was getting the path was the same.

Mf

Answer 2

The old workaround still works, but it has to be done before the GenerateSatelliteAssemblies target. When it is added as a PropertyGroup in the project file, it will be interpreted too late which results in the two locations warning.

As shown by Marcel Veldhuizen, it can be made to work by adding the following target:

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

Note: there is currently an open issue in the msbuild repository on GitHub about this.

Frentz

The issue has been closed, looks like once you get msbuild v16.10.0-preview-21181-07 or higher the warning should go away – Dishonorable