Prefer32Bit flag produces invalid output assembly in .NET 7

[mike-ward]

Description

Project builds and runs using .NET 6.0 Switched to .NET 7 - Preview 5. App builds with no issues but when I run it, it immediately exits.

The debug console has the follow message.

Loaded application domain 'DefaultDomain (id 1)'
Loaded Assembly 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll'
Loading module C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll in application domain 1:DefaultDomain
Pdb file for assembly C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll was not found or failed to read
Started Thread 18556

Reproduction Steps

• Clone https://github.com/mike-ward/Loon/tree/net7 into Visual Studio.
• Switch to net7 branch
• Select Loon.Desktop as the startup project
• Press F5 to build and debug

Expected behavior

Program should display the initial view asking for PIN number.

Actual behavior

Program immediately exits. Debug console has the following message.

Loaded application domain 'DefaultDomain (id 1)'
Loaded Assembly 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll'
Loading module C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll in application domain 1:DefaultDomain
Pdb file for assembly C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll was not found or failed to read
Started Thread 18556

Regression?

Yes, this works in .NET 6.0. The main branch of the project is built using .NET 6.0

Known Workarounds

None

Configuration

• .NET 7.0
• Windows 10 [Version 10.0.19043.1165]
• x86
• appears not to be specific to debug/release configuration

Other information

This project uses the Avalonia UI framework.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Project builds and runs using .NET 6.0 Switched to .NET 7 - Preview 5. App builds with no issues but when I run it, it immediately exits.

The debug console has the follow message.

Loaded application domain 'DefaultDomain (id 1)'
Loaded Assembly 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll'
Loading module C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll in application domain 1:DefaultDomain
Pdb file for assembly C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll was not found or failed to read
Started Thread 18556

Reproduction Steps

• Clone https://github.com/mike-ward/Loon/tree/net7 into Visual Studio.
• Select Loon.Desktop as the startup project
• Press F5 to build and debug

Expected behavior

Program should display the initial view asking for PIN number.

Actual behavior

Program immediately exits. Debug console has the following message.

Loaded application domain 'DefaultDomain (id 1)'
Loaded Assembly 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll'
Loading module C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll in application domain 1:DefaultDomain
Pdb file for assembly C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0-preview.4.22229.4\System.Private.CoreLib.dll was not found or failed to read
Started Thread 18556

Regression?

Yes, this works in .NET 6.0. The main branch of the project is built using .NET 6.0

Known Workarounds

None

Configuration

• .NET 7.0
• Windows 10 [Version 10.0.19043.1165]
• x86
• appears not to be specific to debug/release configuration

Other information

This project uses the Avalonia UI framework.

Author:	mike-ward
Assignees:	-
Labels:	area-AssemblyLoader-coreclr
Milestone:	-

[vitek-karas]

This has the same root cause as #64255.

How to diagnose:
Since this is a UI app, it won't print out anything to the console (Windows behaves this way, even if the app itself writes to stdout or stderr).
The error is also written to Event Log though, so simply open event log and look for recent ".NET Runtime" events. In this case I got this:

Exception Info: System.BadImageFormatException: Could not load file or assembly 'C:\Repro\Loon\src\Loon.Desktop\bin\Debug\net7.0\Loon.dll'. Format of the executable (.exe) or library (.dll) is invalid.

This typically refers to bitness mismatch - that is trying to load for example 32bit assembly into a 64bit process.

In this case the Loon.Desktop project sets <Prefer32Bit>true</Prefer32Bit>. This marks the produces assembly as 32bit (preferred). You can read more details in #64255 (comment). In short, runtime itself ignores this setting and in .NET it has no meaning really, but Windows still reacts to it and there's an unfortunate behavior which cases the failure.

As noted in #64255 we don't plan to fix he runtime to handle this case (the complexity doesn't seem to be worth the trouble).

So the simple fix is to remove the Prefer32Bit property - then it works (verified). As noted above, it has no meaning for .NET, it only worked on .NET Framework.

[vitek-karas]

@agocke @VSadov : Since this is a second time it showed up I looked into this a little bit more from an "end user" point of view. A trivial repro is (using .NET 7 Preview 5):

dotnet new console
dotnet build /p:Prefer32Bit=true
.\bin\Debug\net7.0\app.exe

This produces output like:

Unhandled exception. System.BadImageFormatException: Could not load file or assembly 'C:\Repro\p32\bin\Debug\net7.0\p32.dll'. Format of the executable (.exe) or library (.dll) is invalid.

Given that it's really easy to hit this and that it is likely to affect apps migrated from .NET Framework (which might have this property set), I think we should consider doing something about this.

Personally I still prefer to not fix the runtime, but instead make a change in SDK and generate a warning that Prefer32Bit is not supported anymore and may break the app (for TFM 7.0). Thoughts?

[agocke]

Personally I still prefer to not fix the runtime, but instead make a change in SDK and generate a warning that Prefer32Bit is not supported anymore and may break the app (for TFM 7.0). Thoughts?

Agreed. LGTM

[agocke]

@VSadov Could you add an error to the SDK for this? And file a breaking change issue?

[VSadov]

Right. NT loader does not like it when a Prefer32Bit is applied to a PE32 dll and would not load it in a 64bit process.
We should ignore the setting and produce a build warning.

[hoyosjs]

@VSadov should this be closed?

[VSadov]

yes, dotnet/sdk#27796 has just merged