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 t
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.
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>
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.
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
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:
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>
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... -->
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