Unable to load assemblies using SDK 7.0.202 but worked on SDK 7.0.201 #83526
Comments
|
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: File Configuration on the target machine.NET version: .NET 7.0.4 ASP.Net Core runtime and .NET Windows Desktop runtime. |
jeffschwMSFT
removed
the
untriaged
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsDescriptionWhen compiled using .NET SDK 7.0.202, code that uses Here's how you can reproduce the bug.
The application is quite simple. It finds all Use the Here's a snippet of the output when using 7.0.201: And here's a snippet of the output when using 7.0.202: Configuration
I've tried using 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
|
|
I think we should revert the change. |
|
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. |
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? |
|
The original bug was - #77697 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? |
Yes, it was trying to fix a relatively minor regression in behavior of obsolete APIs.
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. |
|
Is going back to 7.0.201 the right workaround at this point? |
Also, if code change is an option, it may help to set the ProcessorArchitecture property to |
|
Show stopper for us, is there a workaround beside rollback ? |
|
We got this issue with an Workaround to use at the start of #pragma warning disable SYSLIB0037
assemblyName = (AssemblyName)assemblyName.Clone();
assemblyName.ProcessorArchitecture = ProcessorArchitecture.None;
#pragma warning restore SYSLIB0037 |
See dotnet/runtime#83526 MEF uses the APIs affected to load assemblies. To workaround the issue we pre-load all the assemblies we're adding to the MEF composition
|
When will this be fixed? It still occurs in SDK 7.0.203. |
|
In the last few weeks we have experienced twice an intermittent error in our ASP.NET Core MVC web site: FileNotFoundException(Could not load file or assembly 'System.Net.Mail, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.). The other time another system assembly could not be found. A restart of the application (IIS app pool) resolved the issue. The web site is published self containing. In both cases the assembly with the correct PublicKeyToken existed on the server. We have never seens such issues with 7.0.3 and below. Could this be the same issue? |
|
I believe the fix for this issue should appear in 7.0.6, which should ship in May. |
|
I just noticed this issue today but have had the problem with System.Net.Mail FileNotFoundException as well as the same exception for the following: System.IO.FileNotFoundException: Could not load file or assembly ‘System.Diagnostics.TraceSource, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’. The system cannot find the file specified. The systems.diagnostics.Tracesource exception was triggered when executing an OrderBy the System.Linq.Dynamic.Core library. The exceptions only occur when I use Self Contained instead of Framework Dependent as the publishing option. |
|
@agocke Is there an issue tracking the fix for this in 7.0.6? |
|
@reduckted I hope there is. All of the problems that have occured for that apps I work on are with Self Contained publishing. So if others are looking for a short term solution, Framework Dependent is an option. |
|
Another option is to put
In your project files |
|
@reduckted This is the issue. I'm waiting for the fix to ship and confirm that it fixes the problem, then I'll close this issue. |
|
Seems to be fixed in .NET SDK 7.0.304. |
|
Thanks for the confirmation @reduckted . Closing. |
ghost
locked as resolved and limited conversation to collaborators
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.
run.ps1.The application is quite simple. It finds all
.dllfiles in the current working directory, gets the assembly name from each file, then usesAssembly.Load()to load that assembly.Use the
run.ps1script 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:
And here's a snippet of the output when using 7.0.202:
Configuration
I've tried using
Microsoft.NET.Sdk.WebandMicrosoft.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
The text was updated successfully, but these errors were encountered: