Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Warning AL1073 when .resx files is compiled under x64 #5981

Closed
CyberSinh opened this issue Dec 21, 2020 · 28 comments · Fixed by #6207 or #7051
Closed

Warning AL1073 when .resx files is compiled under x64 #5981

CyberSinh opened this issue Dec 21, 2020 · 28 comments · Fixed by #6207 or #7051
Assignees
@benvillalobos
Labels
bug triaged

Comments

@CyberSinh
Copy link

Issue Description

msbuild reports a "Warning AL1073 Referenced assembly 'mscorlib.dll' targets a different processor" when you try to compile .resx files under x64.

Steps to Reproduce

Simply try to compile .resx file under x64 platform.

Expected Behavior

No warning.

Actual Behavior

Warning AL1073.

Analysis

msbuild seems to always call x86 al.exe even when the platform is x64.
The issue is described at this post.

The workaround is to manually add the following code in your project file:

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

Versions & Configurations

Visual Studio 2019 v16.8.3
WPF .NET 5.0 project
@CyberSinh CyberSinh added bug needs-triage Have yet to determine what bucket this goes in. labels Dec 21, 2020
@jeroenvdbrink
Copy link

jeroenvdbrink commented Dec 24, 2020 •
edited
Loading

Thank you so much for posting this workaround! This issue has been driving me nuts for a couple of days while converting our old-style csproj files to the Microsoft.NET.Sdk format.

This AL1073 warning problem has existed since forever (it is also present in .NET Framework). I used the same workaround of setting the TargetFrameworkSDKToolsDirectory in the old projects, but not as a target. However, that causes an error in the Microsoft.NET.Sdk projects.

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.

I would like to see this fixed in msbuild itself (to save many people's headaches), but the workaround helps for now.

Note: I only get the problem when I add a second localized resource file. With just one resx file everything is fine, but adding a localized file (for example filename.resx and filename.fr.resx) results in the warning. I get one warning for each additional localized file.

@benvillalobos benvillalobos self-assigned this Jan 13, 2021
@benvillalobos
Copy link
Member

Note to self: get a repro of this.

@benvillalobos benvillalobos mentioned this issue Mar 2, 2021
Merged
@CyberSinh
Copy link
Author

Thanks for the fix. Do you know which future update of Visual Studio will contain the fix?

@benvillalobos
Copy link
Member

@CyberSinh This should release with VS 16.10 preview 2

@CyberSinh
Copy link
Author

I installed Visual Studio 16.10 RTM, and the issue is still here.
Is that expected? Thanks.

@benvillalobos
Copy link
Member

@CyberSinh Definitely not 😟 Could you provide binlogs of your build? Also let me know if you'd rather provide them more securely in a feedback ticket.

@CyberSinh
Copy link
Author

The issue seems to be still here if the project is rebuilt.

Please find below the msbuild binlog
msbuild.binlog.log

@benvillalobos
Copy link
Member

benvillalobos commented May 25, 2021 •
edited
Loading

@CyberSinh I think I see the issue.

Could you test something for me? I'm fairly confident that adding this command line argument will fix your build: /p:SdkToolsPathMaybeWithx64Architecture="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\". If it fails, providing another binlog would help greatly.

Edit: If it does fail, providing a minimal project to reproduce this issue would also help quite a bit

@benvillalobos benvillalobos reopened this May 25, 2021
@benvillalobos benvillalobos removed the needs-triage Have yet to determine what bucket this goes in. label May 25, 2021
@CyberSinh
Copy link
Author

No more warning with your command line argument. Well done!
Now, what is the definitive fix?

@benvillalobos benvillalobos mentioned this issue May 25, 2021
Merged
@benvillalobos
Copy link
Member

@CyberSinh To use the variable I created in the original PR 😅 I overlooked it during a refactor of that PR. See #6484

A temporary fix for your project would be to add a property group that defines SdkToolsPathMaybeWithx64Architecture to that same path. If your build doesn't always build as x64, you can condition it based off of PlatformTarget. The logic for how I did it is shown here:

https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3738-L3741

@onyxmaster
Copy link

There is some kind of a problem with multi-targeted builds and setting SdkToolsPathMaybeWithx64Architecture doesn't help.
Please check out the al1073.binlog.zip. While the netstandard2.0 TFM build works fine, invoking x64 al.exe for GenerateSatelliteAssemblies target's AL task, the net5.0 one invokes the x86 one.

@benvillalobos
Copy link
Member

@onyxmaster I do see that net5.0 isn't calling the x64 al.exe. Is SdkToolsPathMaybeWithx64Architecture set for both your netstandard2.0 and net5.0 projects? I don't see it defined in the net5.0 build.

Could you do a command line build of your project and provide that binlog? Should look something like msbuild your.sln /bl on a dev command prompt.

@onyxmaster
Copy link

My apologies; it appears to be some fluke in VS 16.10. After cleaning VS temp folder .vs and rebuilding from scratch, the issue is gone, SdkToolsPathMaybeWithx64Architecture works just fine.

@benvillalobos
Copy link
Member

To be clear for those hitting this, the workaround should be very similar to the workaround in the OP. Add this to your projects that need it, or into a Directory.Build.props file in your directory containing your projects:

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

@benvillalobos
Copy link
Member

So we figured out what the fix is for this and it'll be released along with 16.11 in the coming months. The workaround (in the post just above this) should be used in 16.10 for the time being. For those hitting this pre-16.10, the original workaround in the OP should solve your issue. Will leave the issue open until the fix is out 🙂

Forgind pushed a commit that referenced this issue May 28, 2021
@benvillalobos
Use new variable for the AL tool path (#6484)
5656cb5 
Fixes # #5981

Summary
MSBuild didn't support customers using the x64 AL.exe tool by default when their projects targeted x64. #6207 implemented a fix to include x64 in the path when relevant, but this commit mistakenly forgot to update one property name which results in an empty parameter being passed. This results in the x86 version of AL.exe being the default choice.

This fix changes the name of the property to the correct one that is set just before AL is called.

Customer Impact
Customer's that want to compile .resx files using 64-bit AL.exe require a workaround to do so. This change will allow this workaround to become default behavior.

Testing
Customer did a manual fix here that manually set SdkToolsPathMaybeWithx64Architecture to the value that _ALExeToolPath would be and their build succeeded.

Risk
Low. The previous value is preserved when not on x64, and only appends the platform to the path to AL.exe when targeting x64.

Code Reviewers
Description of fix
Rename property passed into AL from SdkToolsPathMaybeWithx64Architecture to _ALExeToolPath, which is set a few lines above the AL call.

Context
#6207 introduced logic to fix the above issue. Unfortunately we need to update one location (the one that matters) to use that newly created variable. I missed this during the refactor in this commit

Changes Made
Update the variable used for SdkToolsPath when calling AL.

Testing
See the linked issue. The customer passing /p:SdkToolsPathMaybeWithx64Architecture="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\" (the value that _ALExeToolPath has) fixed their issue.

Notes
_ALExeToolPath is defined just above the AL call that this PR modifies, if you're wondering where it came from.
@benvillalobos benvillalobos pinned this issue Jun 30, 2021
@mavasani mavasani unpinned this issue Jul 22, 2021
@ContentsMayVary
Copy link

ContentsMayVary commented Nov 15, 2021 •
edited
Loading

With Visual Studio 2022, I'm getting this warning for every single C# 0x86-targeted executable project with a resource file.
This is quite irksome...

@benvillalobos
Copy link
Member

Can someone who's running into this supply a sample project that reproduces this? Or supply a binlog to this feedback ticket where it'll be confidential?

It sounds like a reverse issue of the original bug 😕

@Thieum
Copy link

Thieum commented Nov 15, 2021

@benvillalobos see my comment: https://developercommunity.visualstudio.com/t/Warning-AL1073-when-compiling-x86-NET-F/1582168#T-N1584478

@benvillalobos
Copy link
Member

benvillalobos commented Nov 15, 2021 •
edited
Loading

Workaround

For those that hit any issue related to this in the future: set the property ALToolPath in some .targets file toTargetFrameworkSDKToolsDirectory like so:

<PropertyGroup>
		<!-- You could also condition this based on $(PlatformTarget) -->
        <AlToolPath>$(TargetFrameworkSDKToolsDirectory)</AlToolPath>
</PropertyGroup>

Why it works

AlToolPath is an override for the path that the AL tool would look for. If you need AL to find the x64 tool, append x64\ to that path. Note the x86 version of the tool is located directly in TargetFrameworkSDKToolsDirectory.

The Underlying Issue

The AL task looks for its own .exe based on the current processor architecture. This means an x64 VS or MSBuild will find the x64 AL tool, where previously it found the x86 AL tool that caused the same issue when targeting x64.

Use the workaround in the meantime while we patch this. Thanks @Thieum for supplying the repro project & binlog!

@Thieum
Copy link

Thieum commented Nov 15, 2021

@benvillalobos Can the variable ALToolPath be set directly in the csproj like this: Thieum/AL1073-Repro@b1ec93c ?

It doesn't seem to fix the issue on my side.

@benvillalobos
Copy link
Member

@Thieum It can be set directly in the project, but it would have to be in a target so TargetFrameworkSDKToolsDirectory could be defined beforehand. If it's not in a target then TargetFrameworkSDKToolsDirectory won't be defined by the time msbuild sets the AlToolPath property.

@Thieum
Copy link

Thieum commented Nov 17, 2021

That's the workaround that works for me inside the project:

    <Target Name="ALBeforeBuild" BeforeTargets="PrepareForBuild">
        <PropertyGroup>
            <AlToolPath>$(TargetFrameworkSDKToolsDirectory)</AlToolPath>
        </PropertyGroup>
    </Target>

@benvillalobos benvillalobos mentioned this issue Nov 18, 2021
Merged
ladipro pushed a commit that referenced this issue Nov 25, 2021
@benvillalobos
Al.exe finds the correct tool based on platform (#7051)
5492fe8 
Finally puts #5981 to bed.
(to trigger an auto-close: fixes #5981)

### Context
The underlying problem with the Al issues is that **the Al task finds its own tool based on the current process' architecture**. This means:

x86 msbuild.exe -> x86 Al.exe
x64 msbuild.exe -> x64 Al.exe

Now, if your x86 msbuild.exe is building with `Platform=x64`, the x86 Al.exe gets passed `platform:x64` and logs its own warning because of mismatched platforms.

So we fixed that by checking if the platform was x64, then look in the x64 tools directory in common.targets.

Now we're hitting problems where the x64 msbuild.exe is calling the x64 Al.exe and being passed `platform:x86`, causing the reverse of the original issue!

### Changes Made
The Al task checks the platform that was passed. If it's x86, it will find the 32 bit al.exe. If x64, it will append x64 to the path before finding the tool.

This also reverts appending x64 to the tools directory in common.currentversion.targets before calling the Al task. It shouldn't have worked in today's x64 msbuild.exe, but does because of the x86 fallback behavior. Apending x64 before the task is called is no longer required.

### Testing

### Notes
I allowed `_ALExeToolPath` to be overridden to account for projects that may be using it today with older msbuild binaries.

**A mismatched common.currentversion.targets & microsoft.build.dll can fail**.

Old targets & new dll: if platform is x64 it will double append x64, but the fallback will find the x64 al.exe. no fix required. if platform is x86 and x64 is appended to the path: will likely find the x64 tool and log the error. fix: customer should no longer append x64 to the path.

new targets & old dll: for platform=x64, `x64` needs to be manually appended. The "source of truth" is setting `AlToolPath` to end in `x64`. for platform=x86, no fix needed.
@gallettoNL
Copy link

If this is closed, why is the issue still there in VS 2022 v. 17.0.5?

What am I missing?

@ladipro
Copy link
Member

ladipro commented Jan 24, 2022

@gallettoNL the latest fix was merged into the main branch but unfortunately hasn't made it into 17.0.*. It will first appear in 17.1 which is already available as a preview.
https://visualstudio.microsoft.com/vs/preview/

@gallettoNL
Copy link

Ok, @ladipro, stanx!

@ContentsMayVary
Copy link

I can confirm that this appears to be fixed in Visual Studio 2022 version 17.1 that was recently released.

@gallettoNL
Copy link

gallettoNL commented Mar 22, 2022 via email

NightOwl888 added a commit to NightOwl888/ICU4N that referenced this issue Mar 24, 2022
@NightOwl888
ICU4N.csproj: Added Target to set AlToolPath as in: dotnet/msbuild#59…
3b23348 
…81 (comment)
NightOwl888 added a commit to NightOwl888/ICU4N that referenced this issue Mar 24, 2022
@NightOwl888
ICU4N.csproj: Added Target to set AlToolPath as in: dotnet/msbuild#59…
468009c 
…81 (comment)
@ericsia
Copy link

ericsia commented Jan 25, 2023

Version 17.3.6 have this problem when I work on .net 3.5 project

Severity	Code	Description	Project	File	Line	Suppression State
Warning		Task attempted to find "AxImp.exe" in two locations. 1) Under the "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\" processor specific directory which is generated based on SdkToolsPath 2) The x86 specific directory under "C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\" 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.

what should I do?

@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@benvillalobos benvillalobos

Labels
bug triaged
Projects
None yet
Milestone
No milestone
10 participants
@onyxmaster @Thieum @benvillalobos @jeroenvdbrink @CyberSinh @ContentsMayVary @ladipro @ericsia @AR-May @gallettoNL