tl;dr: My .NET Core 3.1 console application crashes with a FileNotFoundException because a (referenced?) assembly is present in version A, but required in version B. What to do?
I am trying to get a console application to run that is now built for .NET Core 3.1, but that used to be a .NET Framework 4.8 project before it was converted.
The console application crashes with a System.IO.FileNotFoundException, saying that the assembly Microsoft.Extensions.FileProviders.Physical in version 3.1.0.0 cannot befound. Now, I can confirm it's not there - in the directory where the .exe file of my console application resides, there is a file named Microsoft.Extensions.FileProviders.Physical.dll, but its assembly version is 3.1.6.0.
The console application and its dependencies are a part of a bigger project in said folder, with a total of over 1,200 DLLs.
In .NET Framework, I'd have used a binding redirect to use the present version 3.1.6.0 of the indicated assembly. In .NET Core, though, I understand these binding redirects are not a thing anymore. Thus, I'm not sure how to proceed, or how to even find out why the runtime thinks it needs to load Microsoft.Extensions.FileProviders.Physical.dll.
I may have found a partial solution that loads the version-mismatched assembly nonetheless (see observation (6) below), but then, I'm still getting a FileNotFoundException, this time for Microsoft.AspNetCore.Mvc.Abstractions.
Some observations and attempts to solve this:
(1) None of the > 1,200 .csproj files contains the string "Physical".
(2) More than 400 of the .deps.json files mention "Microsoft.Extensions.FileProviders.Physical.dll", all of them referring to version 3.1.0.0.
(3) All of the respective DLLs are loaded in an ASP.NET Core application where the version mismatch appears to cause no issues.
(4) The .deps.json file of my console application itself does not mention "Microsoft.Extensions.FileProviders.Physical.dll".
(5) Putting the right version of the file (3.1.0.0) into the directory where the .exe file resides and from where the .exe file is also executed does not change anything. The FileNotFoundException still occurs, still complaining about an absence of "Microsoft.Extensions.FileProviders.Physical.dll", version 3.1.0.0.
(6) Based upon the information on assembly resolution in .NET Core provided in a CodeProject article, I have attempted to force loading of the assemblies from the same directory myself (preliminary code, relying on the working directory):
AssemblyLoadContext.Default.Resolving += (context, name) =>
{
var dllPath = System.IO.Path.Combine(Environment.CurrentDirectory, name.Name + ".dll");
if (File.Exists(dllPath))
{
return AssemblyLoadContext.Default.LoadFromAssemblyPath(dllPath);
}
return null;
};
This appears to help to some extent! Now, the "Microsoft.Extensions.FileProviders.Physical.dll" assembly, and plenty (more than 250) of others, can be loaded. But this fails once "Microsoft.AspNetCore.Mvc.Abstractions", 3.1.0.0, needs to be loaded, which is not actually anywhere around the .exe file. Apparently, it must be loaded from somewhere else (?)
(7) While the above appears to provide a partial solution concerning the version mismatch, our entire source code contains no other occurrence of "AssemblyLoadContext". Therefore, the ASP.NET Core application apparently avoids the version mismatch issue using some other mechanism.
(8) Building my console application with build output set to Diagnostic1 confirms the suspected behaviour for the "Microsoft.Extensions.FileProviders.Physical.dll" file (shortened excerpt of the output):
Dependency "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Could not resolve this reference. Could not locate the assembly "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "C:\(...)".
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.dll",
but its name "Microsoft.Extensions.FileProviders.Physical, Version=3.1.6.0, Culture=neutral, PublicKeyToken=adb9793829ddae60"
didn't match the expected name "Microsoft.Extensions.FileProviders.Physical, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Considered "C:\(...)\Microsoft.Extensions.FileProviders.Physical.exe", but it didn't exist.
Required by "(A)".
Required by "(B)".
Required by "(C)".
In there, (A), (B), and (C) are assemblies of our own project. But as far as I can see, neither of their .csproj files mentions the text "Physical", so I do not understand why the DLL is allegedly being required by them.
(9) For the "Microsoft.AspNetCore.Mvc.Abstractions" assembly, diagnostic output says:
Dependency "Microsoft.AspNetCore.Mvc.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".
Could not resolve this reference. Could not locate the assembly "Microsoft.AspNetCore.Mvc.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
For SearchPath "C:\(...)".
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.dll", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.exe", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.winmd", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.dll", but it didn't exist.
Considered "C:\(...)\Microsoft.AspNetCore.Mvc.Abstractions.exe", but it didn't exist.
Required by "(B)".
Once again, (B) is an assembly (same as the (B) in (8)) of our own, but looking into the .csproj file does not reveal a single occurrence of "Mvc.Abstractions".
I have found a couple of questions that appeared to provide solutions, but none of them worked for me:
Assembly binding redirect in .NET Core - just points to another question (listed below).
Adding a bindingRedirect to a .Net Standard library - the answer points out that binding redirects do not exist in .NET Core, but that the .deps.json file can be used to resolve assemblies. It then goes on to describe .NET Framework binding redirects, without mentioning anything else on what to do with .deps.json in .NET Core.
Common practice to load the dependency(different version of dll) in program - the question is about .NET Core, but the answer applies to .NET Framework. For .NET Core, it links to one of the other questions listed here.
How can I add an assembly binding redirect to a .net core unit test project? - the answers to this question seem to suggest using binding redirects in app.config files, even though these are apparently not supported anymore in .NET Core according to another comment on that question. In any case, the suggested solution of adding
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
to the .csproj file (uh, which one? I tried the one of my console application; is that the right one?) has no effect to my .deps.json files or the exception I keep getting, as far as I can tell.
Error System.IO.FileLoadException: 'Could not load file or assembly 'log4net, Version=2.0.8.0 in .NET Core - in this case, the correct DLL was available in the right version, it was just not copied to the appropriate output folder.
.NET Core 3.1 - Could not load file or assembly System.Runtime, Version=4.2.2.0 - the solution in this case seemed to be to use another library/library version that would fit with the assembly reference. I do not think that is a viable way for me, as replacing the Microsoft.Extensions.FileProviders.Physical assembly might just cause any kinds of conflicts or issues in any of the > 400 of our assemblies that apparently somehow use the file, according to the .deps.json mentions.
Why is my .NET framework app looking for the wrong version of the .NET core/standard platform extension assembly, and how do I fix it? - it seems this question's OP just accidentally stepped into the .NET Core topic, while they were actually working in a .NET Framework context.
FileNotFoundException when referencing DLL in .NET Core Application - this issue was centered around deficiencies in earlier .NET Core versions, which do not apply to .NET Core 3.1 anymore.
FileNotFoundException with indirectly (.net to .net standard to NuGet) referenced DLL - this appears to have been another case of the correct DLL file being available, just not in the right location.
Can I control .NET Core assembly redirects programmatically? - once again, comments in this question point out that binding redirects are not a solution in .NET Core. Moreover, the answer appears to apply to compile time. As none of our .csproj files mentions the files with which I am observing a version mismatch, I suspect it is referenced from within one of the 3rd party libraries we are using and thus compile-time solutions may not be applicable.
How can I make the runtime load version of 3.1.6.0 of the indicated assembly rather than the requested version 3.1.0.0? Alternatively, how do I find out how the runtime does it when running the ASP.NET Core application?
1: in VS2019: Tools -> Options -> Projects and Solutions -> Build And Run -> MSBuild project build output verbosity -> Diagnostic
I'm working on converting a large WPF solution's projects to SDK style and ran into some issues.
The solution is large with multiple projects(old style) all targeting .net452 and some nugets(some made by me) installed, targeting both .net452 and .netstandard2.1
This all seems to work fine, somehow the nuget manages to install the correct version targeting .net452.
I have decided to slowly convert the projects inside the solution to SDK style targeting .net452 and .netstandard2.1 just like the nugets.
This is where the problem starts, one project was converted so far that is referenced by multiple other projects.
Localy everything seems to build and run fine, however when Azure DevOps(VS version 2019) is used to build the solution there are 2 scenarios:
The famous error message is shown:
"Error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.1.0.0"
It builds fine but on app launch it crashes with:
"Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified."
I'm suspecting that the problem is related to referencing the SDK project, it looks like that somehow it references the .netstandard2.1 instead of the .net452.
The reason this is my suspicion is that if targetframework is set to only .net452 on the referenced project everything works fine.
Google has led me to two possible solutions to tell the project what framework to use from the reference:
<ProjectReference Include="..\..\..\..\foo\foo.csproj"
AdditionalProperties="TargetFramework=net452">
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<Name>foo</Name>
</ProjectReference>
and
<ProjectReference Include="..\..\..\..\foo\foo.csproj">
<SetTargetFramework>TargetFramework=net452</SetTargetFramework>
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<<Name>foo</Name>
</ProjectReference>
This doesn't look like it's doing anything and the problem still persists.
At the moment I ran out of ideas and I'm here asking for help. Please let me know what I'm doing wrong or what else I can try.
I have found the problem. The issue was that I had set an output directory in AzureDevOps. When the builds for the projects were finished everything was copied there, first the .net4.5.2 target DLLs and then overwritten with the netstandard2.1 dlls. To avoid this issue in case it happens to anyone, let the compiler put the files into the root project by default and copy them afterwards wherever you want.
I have a web application built using .NET Framework 4.5.1
When i publish it from VS2017, VS2017 adds unwanted dll's, not listed in the references, which are :
System.Web.Mvc.dll
System.Web.Razor.dll
System.Web.Webpages.Deployment.dll
System.Web.Webpages.Razor.dll
When i try to publish from VS2013 it gives runtime error (razor missing) and my project doesn't have any cshtml file and of course it's not using any razor views.
Why does VS2013 require razor and is there any way to stop VS2017 adding razor and other unwanted dll's when publishing?
Thank you!!
**EDIT: ** From researching, i found that adding <PreserveCompilationContext>false</PreserveCompilationContext> in my csproj file, would stop VS2017 from adding razor, but after publishing now i get runtime error Could not load file or assembly 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Have you tried examining the Options under the Debug menu in Visual Studio, one of the settings allows you to control this (under package/publish) by choosing Items to deploy: Only Files Needed to Run This Application
It is also possible that one of the assemblies you are referencing is required by another assembly.
snapshot of the configuration window
I have a situation where I get a runtime error when running ASP.NET MVC4. I recently migrated to MVC4 from MVC3.
Upon starting the debugger, I instantly get faced with this error message:
The type 'System.Web.Mvc.WebViewPage' exists in both
'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
Files\promotionweb\20a5681f\9ce59023\assembly\dl3\29f671cf\37f0bcf2_4619d001\System.Web.Mvc.DLL'
and
'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Mvc\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Mvc.dll'
I'm running in IIS 7.5, with a solution setup of the MVC project itself, another C# library plus a console application project.
I've tried all steps mentioned in this answer, descended from a similar question. However it doesnt help at all in my case.
I had some doubts it had to do to different compilations models, so I've tried compiling for x86 and AnyCPU, cleaning all catalogs as mentioned above in-between. Nothing seems to help.
Any ideas what might cause this interference between the GAC and my Temporary ASP.NET files?
Below is quite a story, but I think it might benefit someone else.
First of all, I opened my project inside Visual Studio 2013, and got a complaint. I followed a link from inside VS2013 (cannot find it) to a Microsoft site where it explained how to manually upgrade an MVC3 to MVC4 project. The steps I followed required manual changes to web.config.
One of the changes I made was to modify the version number of the System.Web.Mvc reference. Previously it was 3.0.0.0, and according to the guide 4.0.0.0 was the number to change to. Another step was to go into the NuGet package manager, search for ASP.NET MVC4 and install it. This downloaded version 4.0.0.1 of System.Web.Mvc, as I think that was the correct version of the time the guide was written.
Once done, I compiled the project and got into the never-ending loop of the runtime error in the question that I posted. My project was compiled against version 4.0.0.1 (which seems to be the correct version number according to a windows update). The compilation was correct, but I had the following line in my web.config:
<add assembly="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
The application was compiled against 4.0.0.1, but was running and searching for 4.0.0.0 and found it in these two places:
c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
c:\Windows\Microsoft.NET\assembly\GAC_MSIL
and thew the error. I still do think this part is strange.
My solution was to modify the web.config, changing the assembly reference version as mentioned, and the binding redirects for System.Web.Mvc.
Some other sources:
System.Web.Mvc not functioning as expected after Windows Update
System.Web.Mvc broken after security update
I once had this error. I noticed that it is important that the reference in the project and the add assembly-tag in web.config is the same. What I did was remove the reference to the assembly that was not the same as in web.config and then adding reference with the correct version. I assume you could also do it the other way around.
I have developped an asmx webservice with visual studio and I deploy on IIS 7 which has 3.5 Framework by copying all the files.
When testing it says
Could not load file or assembly
'System.Web.Extensions,
Version=1.0.61025.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system
cannot find the file specified.
I don't use [System.Web.Script.Services.ScriptService] so I don't understand why it tries to load System.Web.Extensions.
So I change in Visual Studio from .NET 2 to 3.5 but got another error:
Could not load file or assembly
'WebServiceTest' or one of its
dependencies. An attempt was made to
load a program with an incorrect
format.
How to fix this ?
Note: I'm not using any other assembly/lib I'm just learning webservice so it's very simple: I create a webservice Test.asmx with one method which uses one class Test.cs within same namespace WebServiceTest. This works locally.
Finally I have started from scratch again now it works, I think I have mismatched by renaming namespace, class etc.
Maybe you are using a third party assembly which relies on System.Web.Extensions. Make sure this assembly is not referenced in your project either explicitly or implicitly. Also normally the version of this assembly is 3.5.0.0. From the error message it seems that your project is using version 1.0.61025.0 which is an old version. Try looking at every referenced assembly to see what uses this old version. You might need to deploy it on the target server.
Does the server have web extensions INSTALLED? I think they were an additional install before 4.0. Or: did you also copy the System.Web.Extensions.dll in the correct version? On your computer it may be in the GAC and not in the bin folder.
That said, you should not use that - use WCF to expose web services starting .NET 3.5. you Basically train outdated / retired technology.