41

We are using VS2013 and .Net 4.5.1(recently migrated, but this error is there from .Net 4.0) . This error occurs only when compiling the project in platform target x64. Is this really a error which will break in runtime? Why MSBUILD does not resolve this mrcorlib.dll properly ? This happens only in projects which were created in VS2010 and does not occur in newly created projects. What am I missing here. All my third party assemblies are in x64bit.

In TeamCity build server, I get following error:

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
jero2rome
  • 1,548
  • 1
  • 21
  • 39
  • Yeah, this is a serious problem. Your project is using the reference assemblies in c:\windows\microsoft.net instead of the ones in c:\program files\reference assemblies. Very detrimental, especially when targeting .net 4.0. Your question has no clue whatsoever how this happened of course. – Hans Passant Aug 18 '14 at 15:00
  • 1
    @HansPassant I have added additional error Info. All the framework references are referencing C:\Program Files (x86)\Reference Assemblies\ folder only. Ex: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Data.dll. But this System.Data.dll seems to be build for 32-bit platform which references mscorlib.dll. – jero2rome Aug 18 '14 at 15:12
  • 1
    Same story, System.Data is also a mixed-mode assembly. Containing both MSIL and machine code. The copy in c:\windows\microsoft.net is the 32-bit version, at runtime the correct one gets loaded from the GAC. But the copy in c:\program files is special, all of the code is stripped from it and it only contains metadata. And thus should never generate this warning. Something you can double-check with Corflags.exe, ILOnly attribute. – Hans Passant Aug 18 '14 at 15:32
  • See also https://stackoverflow.com/questions/1272733/msbuild-csc-cleanest-way-of-handling-x64-mscorlib-warning-1607 – Colonel Panic Jan 12 '15 at 16:33

9 Answers9

42

Here is a workaround:

The issue can be avoided by using the AL.EXE that matches the platform (or bitness) you are attempting to build. That is, you'll see that when you are building x64, that it is trying to use AL.EXE at a path similar to

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

If you can get it to use the x64 version of AL.exe, the issue will go away. That is, use the AL.EXE at a path similar to:

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

Msbuild finds this path by using its TargetFrameworkSDKToolsDirectory. Thus, using the assumption that this directory is the correct directory when building x86, the workaround below essentially appends the x64 sub directory on to the path when building x64 and leaves it as is otherwise:

  1. Create an MsBuildAL1073WarningWorkaround.targets file (name doesn't matter) and add it to the project. It has the following contents:

    <?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. Edit the .csproj file to import this file near the end of the file (where you'll see the comment that says "To modify your build process...":

     <Import Project="MsBuildAL1073WarningWorkaround.targets" />
 <!-- To modify your build process... -->
Matt Smith
  • 17,026
  • 7
  • 53
  • 103
  • 12
    It looks like adding ` $(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\‌​ ` towards the end of the project file removes the warning – I-A-N May 11 '17 at 12:21
  • 1
    Adding the `` part directly into my .csproj file worked for me with VS 2015 and .NET 4.6. Be careful about copy/pasting though, as I got some extra whitespace chars that made it fail at first. – shoelzer Oct 23 '17 at 16:13
  • 3
    This definitely pointed me in the right direction, but didn't ultimately work in my case. Just adding the PropertyGroup as suggested by @I-A-N just added a warning. See https://thorarin.net/blog/post/2019/02/08/al1703-warning-mscorlib.aspx for my solution. – Thorarin Feb 08 '19 at 17:22
  • @Thorarin thanks! Matt's solution worked for me until I upgraded to VS2019, then the warning came back. Got rid of it again using your suggestion. – Niklas Söderberg Jul 02 '19 at 08:55
  • 3
    For vs2019, add a backslash(\) between `$(TargetFrameworkSDKToolsDirectory)` and `$(PlatformTarget)` so that the final PropertyGroup looks as follows: ` $(TargetFrameworkSDKToolsDirectory)\$(PlatformTarget)\ ` – Timothy Macharia Oct 17 '19 at 09:07
  • This was very helpful although it did not work directly. In my case (working in .NET CORE 3.1) I copied the resgen.exe and al.exe from C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64 to my solution\netfxtools64 and in my project file I added ..\netfxtools64 copying the tools locally was helpful in getting this to work locally and on the build server. al.exe and resgen were both needed since in my case the issue was related to resource compilation and linking. – shelbypereira Mar 31 '20 at 07:34
  • @Thorarin wrong link (remove the aspx at the end): https://thorarin.net/blog/post/2019/02/08/al1703-warning-mscorlib – Noman_1 May 06 '20 at 05:36
  • 2
    I had to replace `TargetFrameworkSDKToolsDirectory` with `SdkToolsPathMaybeWithx64Architecture` in the example above. See https://github.com/dotnet/msbuild/issues/5981#issuecomment-849808889 – Fatal705 Jun 23 '21 at 12:47
  • I had this as a targets file for a few years until Microsoft fixed VS 2019 so it was no longer a problem (https://github.com/dotnet/msbuild/issues/5981). Now that I have upgraded to VS 2022, I get the same error when trying to build in x86 mode. :) It seems when they changed VS to be a 64 bit application, it made it harder to build in 32 bit. – David Parvin Dec 17 '21 at 02:09
23

These warnings are shown in the projects that contain localization satellite assemblies(.resx files) in the solution.

This is the bug from Microsoft side and as of Aug 2017, Microsoft still hasn't fixed it.

Here's the quote from the MS feedback page:

It is resulting from a logic bug in the .NET framework binary alink.dll. But given the limited impact of this issue and the fact that this tool has a very high bar for servicing we will not be making a change to address this issue.

Regards,

Ed Maurer Development Lead, VB & C# Compilers

GorvGoyl
  • 42,508
  • 29
  • 229
  • 225
  • 1
    Was this bug solved in recent .NET/.NET Core platforms? I have the same issue now, using .NET Core 2.1... – Cheshire Cat Nov 15 '18 at 11:04
  • 1
    I still have the issue on .NET Core and still searching for a solution, none of the suggestions here work on .NET CORE 2.2 I opened a new question here: https://stackoverflow.com/questions/58555465/net-core-alink-warning-al1073-referenced-assembly-mscorlib-dll-targets-a-d – shelbypereira Oct 25 '19 at 11:47
11

This warning can be safely ignored. Since .Net will load the correct 64bit assemblies on runtime in a 64bit machine. Still microsoft can give a solid answer to this issue. It was unnecessary time wasting warning.

jero2rome
  • 1,548
  • 1
  • 21
  • 39
  • 1
    The link is now dead, even if you log in with an account. (I didn't downvote your answer, btw.) – JoshuaLawrence Oct 01 '15 at 03:22
  • 2
    Doesn't really answer the question, in many cases we need to remove the warning for example on build servers you often want to fail the build if there are warnings, unfortunately this particular warning cannot be ignored. – shelbypereira Mar 31 '20 at 07:30
9

We had the same issue and ended up with Matt Smith's workaround (https://stackoverflow.com/a/41945190/3506760) with one modification that made it work.

Due to feature/bug in MsBuild (https://stackoverflow.com/a/1367309/3506760) we needed to modify targets file described in step 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>
Community
  • 1
  • 1
Jan Peldřimovský
  • 285
  • 3
  • 11
  • I tested this and it fails on .NET Core 3.0, my issue seems to be with resource files since if I remove the resource files I no longer have the warning. – shelbypereira Mar 25 '20 at 09:11
8

While the bug referenced by @jero2rome is closed as Won't Fix, VS2015 RC w/ .NET 4.6 no longer emits this warning:

From VS2013/.NET 4.5.1, I would see the same issue:

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]

With VS2015 RC/.NET 4.6, no warning is emitted:

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
dirtybird
  • 422
  • 5
  • 8
  • 7
    How did you get this to work?? I am running VS2015 with .NET 4.6 and is still throwing me that warning, what's worst is that when i try to install and run the application, that exact dll is diving me error. – codenamezero Nov 24 '16 at 23:12
5

Just some addition to Matt's answer (I don't have enough reputation to add a comment): I believe

near the end of the file

is right after the line:

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

I have tested and if the above line precedes the (re)definition of $TargetFrameworkSDKToolsDirectory then AL1073 warning is gone. Otherwise it persists.

Levente Koncz
  • 103
  • 2
  • 6
2

Here is my solution:

<PropertyGroup>
  <CreateSatelliteAssembliesDependsOn>
    FixWarningAL1073;
    $(CreateSatelliteAssembliesDependsOn);
  </CreateSatelliteAssembliesDependsOn>
</PropertyGroup>
<Target Name="FixWarningAL1073">
  <PropertyGroup>
    <TargetFrameworkSDKToolsDirectory Condition=" '$(PlatformTarget)' == 'x64'">$(TargetFrameworkSDKToolsDirectory)$(PlatformTarget)\</TargetFrameworkSDKToolsDirectory>
  </PropertyGroup>
</Target>

Add these lines at the end of you .csproj.

Michael
  • 113
  • 6
0

In my case removing all attributes from Properties/AssemblyInfo.cs or deleting entire file fixes warning, but this may be not appropriate solution for most of libraries. Net461, SDK-style project, <GenerateAssemblyInfo> is set to false.

JL0PD
  • 3,698
  • 2
  • 15
  • 23
-4

To ignore that warning, you can install .Net Framework 4.5.2 developer pack for all OS_x86_x64, which is compatible with VS2013. http://www.microsoft.com/en-us/download/details.aspx?id=42637

user4342191
  • 1
  • 1