Error: http://pbrd.co/1vTqOTb
I am getting an error in my XAML in my WPF project:
"Error 11 Could not load file or assembly 'NLog, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=5120e14c03d0593c' or one of its dependencies.
The system cannot find the file specified. MainWindow.xaml 73 9 TestApp"
I have searched the entire solution and cant find any 'NLog'
I have tried to add the NLog dll to each of my projects in the solution but it makes no difference.
Any idea?
Turned out to be the NLog was .Net 4.0 and the project was .Net 4.5
I changed the project to 4.0 and the other dependent project to 4.0 and its working.
Thanks!
Whenever you reference another library, there's the chance they will need some other library. When you reference WPF, there are a lot of underlying libraries that get pulled up.
First, make sure that the DLLs you've referenced are set to "Copy Local = True" under their Properties. Also make sure they have the same PublicKeyToken as your error - if they're referenced by strong name (and most of .NET is) a slightly different version won't be read as the correct file.
The other thing you should consider is checking whether the DLL exists in your GAC, and manually installing it if it doesn't. This can often be the cause of such frustrating errors due to a misinstalled sdk (I once has the same issue with the Blend libraries)
Related
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 newbie to .net projects. Although I was able to code in c# & use it's frameworks, Some times I face exceptions which I really didn't get any proper resource/suggestion to modify or rectify them. Hope I would get clear this time.
The exception which I faced is as follows :
Could not load file or assembly 'Microsoft.AspNetCore.Cryptography.KeyDerivation, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
I'm really confused with such type of exceptions. What's the reason for those & how we needs to cross check to clear those ?
Here is what I did install: "Microsoft.AspNetCore.Cryptography.KeyDerivation" from nuget console with version 2.2.0.
My installed packages list image :
The main reason for this type of error is a result of your output folder. Take a look at where your binary outputs were placed. Inside of that folder (usually your .exe or .dll output, not sure what kind of .NET project you're writing), you should also have all of your dependency dlls. In this case, the dll related to Microsoft.AspNetCore.Cryptography.KeyDerivation is missing. So when you go to run your executable, it complains "Could not load file or assembly KeyDerivation" because it couldn't find it.
To resolve this issue, double check your project's references and that there are no issues with the Microsoft.AspNetcore.Cryptography.KeyDerivation reference (what I mean is, make sure there are no yellow exclamations or other icons showing up next to this reference in your Solution Explorer). If you have any issues, remove the reference, then add the nuget package again.
I am running a project that had been running without issue for some time but recently started throwing an error stating,
"Could not load file or assembly 'Microsoft.Practices.Unity,
Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
or one of its dependencies. The system cannot find the file
specified."
I see that this assembly is for IoC/Dependency Injection support however I never explicitly added it to the solution; although I do see that it is in fact there.
When I check the version of the assembly it is showing the same version that is being referenced in the above error; so I cannot figure out why the file cannot be found by the project.
In effort of resolving the issue I've cleaned the solution, deleted my obj folder, rebuilt, removed and even reinstalled the assembly via nuget but the issue persists.
I've found somewhat similar issues reported here on SO but the proposed resolutions were either not applicable because it was not the same assembly reference as the one I'm having issue with OR it involved configuration of a XAML based application. This is ASP.NET.
The only other clue that I could find as to why I'm having the problem is that the targeted runtime framework of the assembly is v2.0.50727 and this application is .NET 4.5
Which would seem a reasonable explanation for the problem from my limited perspective except that the app was previously running without the problem.
I'd also mention that the assembly isn't explicitly being called from the block of code throwing the error; which is simply creating a web service client and calling a method.
long memberId = 1326728123;
ServiceClient sc = new ServiceClient("ServiceClientEndPoint");
var leadPackage = smc.GetLeadPackages(memberId);
So there could be other variables of this equation that may be attributing to the problem (e.g. Network blocking and etc)
I just wanted to make certain that I may not be missing something by running it past SO before wasting time going in the wrong direction for an answer.
Note that this could mean a number of things, including that one of the dependent assemblies of Microsoft.Practices.Unity could be loaded.
The first place searched is the GAC, if you are building and running on the same machine, this probably won't cause a problem because the runtime will also find the same library but if you are deploying, the project will sometimes bind to the GAC library whereas the production server might not have it installed and it will fail to run. CopyLocal=true should fix that but if you are deploying, you should check that the library is copied into the bin directory.
Secondly, you should open Microsoft.Practices.Unity.dll using reflector or ilspy.exe and see what other dependencies it has (other than the System.* libraries) since any other ones will need the same treatment as Microsoft.Practices.Unity i.e. adding to the project and copy local set to true.
Im having some serous issues with a .dll not being found in Nop.Core.dll (i think)
the dll message the PluginManager.cs writes in the output in VS12 is as follows:
Could not load file or assembly 'Telerik.Web.Mvc, Version=2012.2.607.340, Culture=neutral, PublicKeyToken=29ac1a93ec063d92' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Ive added the right version of Telerik.Web.Mvc to the Nop.Core lib and built a new .dll but the issue still remains.
Ive also checked for cached .dlls in th GAC but nothing.
The issue occured after a restart of VS12 so there´s smt weird going on here. Ive tried disabling/enabeling auto update nuget on build (as i thought that it might be fetching some new dlls that might create a conflict) but nothing.
I do see that the Solution is running .net 4.5 but the Telerik.Web.Mvc.dll target framework is :
TargetFramework(".NETFramework,Version=v4.0", FrameworkDisplayName=".NET Framework 4")].
Can this cause some dll´s to not find Telerik.Web.Mvc.dll?
As im new to nopCommerce im kinda lost at this point. What am i doing wrong here? =)
/seb
Edit:
Make sure you have non-corrupted Telerik.Web.Mvc.dll in your bin folder (download one that comes with nopcommerce and overwrite it to be sure)
This issue may be caused by a plugin that has wrong reference. If you have any custom/old plugins try removing them or readd their reference and recompile.
Current version in 3.10 is 2013.2.611.340 while you have reference to 2012.2.607.340
I have a rather large solution with some Silverlight and WPF projects inside it, as well as some class libraries and other things.
One of the project is a class library that references a SilverLight application which references System.Windows
But at runtime, I get the error:
{"Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified.":"System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"}
I looked in the GAC (C:\Windows\assembly) and couldnt see it in there...
Whats happening here?
The reference is to: c:\Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll which DOES exist.
Sounds to me like your WPF app is loading a class library that references a Silverlight assembly. That cannot work, cats and dogs. If an assembly is referenced by both a WPF and a Silverlight app then it has to be compiled twice with different framework assembly references. That takes two projects. Keeping the WPF and the Silverlight stuff separate in different solutions is the best way to keep out of trouble.
I've seen similar errors in two cases that might apply here:
When an assembly I reference required an assemble I have not referenced . . . in this case that would mean System.Windows is using something else you need to add a reference too.
The more interesting case is when VS2010 auto selected ".Net Framework 4 Client Profile" for me when I actually needed ".Net Framework 4" (no "client profile"). Select the project properties and see what your setting is.
Frank
Per you request additional instructions:
Open Solution in VS2010, right click the project in question (not the solution line) and select "properties" from the bottom. In the resulting GUI, select the "Application" tab and make sure "Target Framework" does not have "client profile" in the name . . . that is should be ".NET Framework 4" not ".NET Framework 4 Client Profile".
I have not found this solution anywhere else, but stumbled upon it as a trial-and-error-by-fire...
The error message was a bit misleading in my situation. The tip off was that it wasn't really the "System.Windows" assembly itself, but one of the dependant assemblies.
What you may want to do is to check your GAC and see if one of these assemblies are in it:
System.Windows
System.Windows.Controls
System.Windows.Controls.Toolkit
System.Windows.Controls.Layout.Toolkit
Try removing them from just the GAC, then do your rebuild. If it doesn't work, just open two windows explorer windows and copy them back from either the c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\System.Windows.dll folder or the folder for your Silverlight Toolkit and you'll be back to where you started from.
Here's what I suspect is happening:
The Visual Studio 2010 compiler is getting confused about where to get those referenced assemblies when doing the build because the GAC assemblies always takes precedence over another copy of an assembly (even the reference assembly folder that VS2010 uses). So even though the assembly is technically correct with the same ID key and everything there's something with the VS2010 compiler that can't determine which library to use for building and it will refuse to complete the build.
mmmm sometimes you put your classes in different project for example you can create a project for viewmodels , if is this the case then you need to reference PresentationCore.dll , this is the dll that give you access to System.windows so you can use ICommand for command bindings