Unable to load assemblies using SDK 7.0.202 but worked on SDK 7.0.201

[reduckted]

Description

When compiled using .NET SDK 7.0.202, code that uses Assembly.Load(AssemblyName) fails to load assemblies that exists in the application directory.

Here's how you can reproduce the bug.

1. Make sure you have .NET SDK 7.0.201 and 7.0.202 installed.
2. Clone https://github.com/reduckted/LoadAssemblyBug
3. Open PowerShell and run run.ps1.

The application is quite simple. It finds all .dll files in the current working directory, gets the assembly name from each file, then uses Assembly.Load() to load that assembly.

Use the run.ps1 script to reproduce the bug. It will first publish the application using SDK 7.0.201, then run the application. This will succeed and you will see it log the name of each assembly that it loads. Next it will publish the application using SDK 7.0.202, then run the application. This will fail for the vast majority of assemblies.

Here's a snippet of the output when using 7.0.201:

Loading assembly: LoadAssemblyBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Loading assembly: Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60

And here's a snippet of the output when using 7.0.202:

Loading assembly: LoadAssemblyBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Loading assembly: Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.

Configuration

• .NET version: .NET SDK 7.0.202, self-contained published application.
• OS: Windows 10
• Architecture: x64

I've tried using Microsoft.NET.Sdk.Web and Microsoft.NET.Sdk, and both exhibit the same bug.

I have not tried using a different OS.

Regression?

Yes. This works flawlessly when compiled with .NET SDK 7.0.201.

Related to dotnet/core#8285

[MWin10]

I've a similar problem: When trying to run my application on .NET 7.0.4, I get assembly loading errors messages as below. Uninstalling 7.0.4 versions of the runtime and using 7.0.3 version instead brings my app back to work.

Error message is:
System.IO.FileNotFoundException: Could not load file or assembly 'NodaTime, Version=3.1.6.0, Culture=neutral, PublicKeyToken=4226afe0d9b296d1'. The system cannot find the file specified.

File NodaTime.dll exists in version 3.1.6.0 on the target machine in the same directory as my .exe file and all the other DLLs.
For me, this issue only occurrs when publishing the app to another machine running .NET 7.0.4, but not on my development machine where I'm using Visual Studio 2022 and where 7.0.4 runtime is also installed.

Configuration on the target machine

.NET version: .NET 7.0.4 ASP.Net Core runtime and .NET Windows Desktop runtime.
OS: Windows 10
Target Framework: net7.0-windows10.0.17763.0
Target Runtime: win-x64
Used Publish Options (in VS 2022): ReadyToRun: Enabled, Produce single file: NOT enabled.

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

Issue Details

---

Description

When compiled using .NET SDK 7.0.202, code that uses Assembly.Load(AssemblyName) fails to load assemblies that exists in the application directory.

Here's how you can reproduce the bug.

1. Make sure you have .NET SDK 7.0.201 and 7.0.202 installed.
2. Clone https://github.com/reduckted/LoadAssemblyBug
3. Open PowerShell and run run.ps1.

The application is quite simple. It finds all .dll files in the current working directory, gets the assembly name from each file, then uses Assembly.Load() to load that assembly.

Use the run.ps1 script to reproduce the bug. It will first publish the application using SDK 7.0.201, then run the application. This will succeed and you will see it log the name of each assembly that it loads. Next it will publish the application using SDK 7.0.202, then run the application. This will fail for the vast majority of assemblies.

Here's a snippet of the output when using 7.0.201:

Loading assembly: LoadAssemblyBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Loading assembly: Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Loading assembly: Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60

And here's a snippet of the output when using 7.0.202:

Loading assembly: LoadAssemblyBug, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Loading assembly: Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Antiforgery, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Cookies, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication.Core, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.
Loading assembly: Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Could not load file or assembly 'Microsoft.AspNetCore.Authentication, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=AMD64'. The system cannot find the file specified.

Configuration

• .NET version: .NET SDK 7.0.202, self-contained published application.
• OS: Windows 10
• Architecture: x64

I've tried using Microsoft.NET.Sdk.Web and Microsoft.NET.Sdk, and both exhibit the same bug.

I have not tried using a different OS.

Regression?

Yes. This works flawlessly when compiled with .NET SDK 7.0.201.

Related to dotnet/core#8285

Author:	reduckted
Assignees:	-
Labels:	area-AssemblyLoader-coreclr
Milestone:	-

[jkotas]

@VSadov This looks like a regression from #81101

[jkotas]

I think we should revert the change.

[agocke]

Sorry, which change would we revert? My understanding is that #81101 was itself a fix for a regression. If we revert it that would presumably bring back the regression.

[VSadov]

I think we should revert the change.

This was supposed to be a compat fix making behavior closer to what was a while ago.

Do we need to re-do the change (i.e. make the algorithm even closer to what native code used to do), or we want to just revert the change?

[VSadov]

The original bug was - #77697
I do not recall that breaking any real scenarios, but it was an observable change, so we tried to get closer to the behavior of the native code (however ad-hoc it could be).

I think reverting this change and "Won't Fix"-ing the scenario is a possible way forward, so I am wondering - which way do we want to go?

[jkotas]

My understanding is that #81101 was itself a fix for a regression

Yes, it was trying to fix a relatively minor regression in behavior of obsolete APIs.

I think reverting this change and "Won't Fix"-ing the scenario is a possible way forward

Yes, I think it would be the best path forward. The problem with the obsolete ProcessArchitecture part of the assembly name is that it is apparently not handled consistently throughout the system. Trying to fix it is just going to introduce more problems than it is worth it.

[arunchndr]

Is going back to 7.0.201 the right workaround at this point?