I am upgrading an application and running into some issues with it.
Now the old application was version 1.0 and loading a depedency assembly A at version 2.1.1 The assembly is present in application local directory.
I am upgrading the new application to version 2.0 that will load assembly A version 1.0.1 which is present in its application local directory. I've checked application references using ISpy and confirmed the new application references A version 1.0.1
But when I start the new application (v 2.0), it is still trying to load assembly version 2.1.1 and failing. I checked the app.config, machine.config and GAC and there is no redirection for version of assembly A. I also checked fusion log files but don't see any redirection. All I see is the fusion log is that application prebinds A at version 2.1.1 and hence fails to set up the assembly present in its local directory.
Is there something I am missing here? What could be the possible reasons for application still referencing the older assembly at runtime?
Update: Using some tools, I realized the the older assembly is being referenced from a native DLL that is referenced by my application, but I don't know which third party DLL is that, and the application loads a ton of them. The fusion log confirms it by logging "Calling assembly : (Unknown)." for the missing assembly.
Now my next step is to find which dll is referencing the wrong assembly and fix that. Now the problem is that ILSpy tool doesn't show the native DLLs references, and DLLDepends tool does not show the assemblies references, so I am not able to link the two.
thanks
Since the library your trying to reference is supposed to be apart of the GAC; you may want to try:
Control Panel
Small Icons(Administrative Tools)
Event Viewer
Application
Windows itself should throw an exception with some particular details it's attempting to reference when it has an error. Especially if it's apart of the GAC. It was more helpful for me to hone in mscoree.dll and mscorelib.dll libraries fairly easy. Granted those clients that I used that for had corrupt framework; but Event Viewer told me the exact library that it had an issue with.
You may want to try that. Not sure which library; but keep in mind this is usually beneficial to libraries that are found within the %windir%/Assembly folder. Hope that helps.
Related
I am getting this error message on one of my development computers:
Assembly File Selector
The following assembly name can not be resolved automatically.
System.XML, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Please select the assembly file manually.
The error is happening on a new computer I just setup. This error does not happen on any of the other computers I have used my program on.
The program uses .NET Framework 4.8. I have installed that framework on this computer. I am both building my program and running it on this computer.
Nothing I do with the dialog box seems to matter. My program works fine if press OK or cancel. Selecting a file does not prevent the dialog from appearing again.
I assume there's some configuration step that didn't happen right on this new computer. What can I do to track down what is going wrong?
That is a very old version of System.Xml - .Net 4.8 would have version number 4.0.0.0. If you are not intended to use an older version of .Net, verify your references are not set to "Use Specific Version" and that your project is targeting .Net 4.8.
That dialog looks like something from Redgate Reflector, which implies you are working with existing assemblies. In that case, you might check the version of the reference in Reflector to confirm.
Do you have the same versions of the older frameworks installed?
I was able to solve the problem thanks to hints from Mitch and Simon Mourier.
My specific application is an add-in for a program called Revit. During development, I use another add-in to load my add-in. I was using an older version of the other add-in. For whatever reason, on this specific computer, it was throwing this error. I am using the same old add-in on other computers with no problems.
I replaced the other add-in with the most recent version and it works correctly.
I looked at the referenced for the old add-in. I referenced the latest version of System.Xml (4.0.0.0). There were no references to System.XML version 1.0.0.0. I never did track down why that was specifically being ask for.
.NETCore just litters your disk a lot worse, too many versions, too many assemblies, too many standards and no GAC. Hopefully they'll get their act together sometime soon. – Hans Passant Aug 17 '17 at 10:37
No, it just keeps getting worse. : \
Have a .NET Standard 2.0 class library that references Microsoft extension classes. When we deploy to the server, we get runtime binding exceptions. My questions first:
Why aren't binding redirects being generated for transitive dependencies?
Since they're not, how do I come up with a full list to add manually?
How does the compiler know what version to redirect to unless it intends for me to deploy the version it compiled against?
How do I come up with a list of DLLs to deploy - excluding framework DLLs but including anything that wouldn't be on the server?
Is a nuget package broken if the assembly version in \ref\ is lower than the assembly version in \lib\?
Details:
We have a class library compiling against .NET Standard 2.0... it references Microsoft.Extensions.Configuration.Json.
MimExtension
\--Dependendencies
\--Packages
\--Microsoft.Extensions.Configuration.Json (5.0.0)
\--System.Text.Json (5.0.0)
\--System.Buffers (4.5.1)
System.Buffers resolves to \.nuget\packages\system.buffers\4.5.1\ref\netstandard2.0\System.Buffers.dll. The file version in that directory is 4.6.28619.1, date 2020/02/19. .NET Reflector shows the assembly version as 4.0.2.0.
The \lib\ version of that DLL is \.nuget\packages\system.buffers\4.5.1\lib\netstandard2.0\System.Buffers.dll... same file version and date, but the assembly version is 4.0.3.0.
Compiling the DLL gives me a .dll.config file with binding redirects that I could copy into the consuming application's app.config - but System.Buffers.dll and System.Text.Json.dll aren't there. Microsoft.Extensions.Configuration.Json.dll also isn't there - though another nuget package, Microsoft.Extensions.Configuration.Abstractions.dll, is.
I'm assuming this means the compiler thinks no redirect is necessary for the DLLs that aren't in there (see question #3). It makes sense that only DLLs with conflicts across references get added to the binding redirects (if that's what's happening), but conflict or not, our app won't bind to the \lib\ version of the System.Buffers.dll the compiler uses and RTE's (question #1).
To resolve this I can add binding redirects manually. But how do I look at all the nuget references in my project and determine (recursively) what version was chosen for each dll? Short of dumping verbose build output to a text file with some fancy regex and an hour of copy and paste, that is (question #2).
Note: I can add <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to the .csproj file and get all referenced dlls dumped to the output directory - including .NET dlls like System.Threading.dll and System.Runtime.CompilerServices.Unsafe.dll- but that still doesn't get me a full list of what versions each one are... especially since I need assembly versions, which I can't even display in explorer.
Regarding that... some of the binding redirects generated automatically are for .NET assemblies like System.Threading... does VS really expect me to deploy the version of System.Threading I compiled against? For that dll, I have newVersion="4.0.11.0"... our server has assembly version 4.0.0.0, file version 4.8.3761.0. VS expects me to deploy assembly version 4.0.11.0, file version 1.0.24212.01 (wtff?!?). The 4.0.11.0 version pulled down by nuget is dated 2019/12/26... the 4.0.0.0 server version is dated 2021/01/21.
I'm guessing that's a Core vs. Framework versioning wtf - but binding redirects don't care. The app that will load our library is .NET Framework 4.8... am I supposed to deploy the System.Threading 4.0.11.0 dll with my app, or manually change the binding redirect and let it load the server's version? It's absolutely ludicrous that a core DLL has a higher assembly version than its newer .NET Framework counterpart (question #addingnewonesasigo).
So when we're referencing nuget packages, how do we know what needs deployed and what doesn't (or worse, shouldn't be)? (question #4) I feel like the build process should copy dlls that aren't part of the framework/won't be in the GAC to the output directory - but there's nothing TIAO to indicate that in the nuget package specs.
Regarding #5... shouldn't the dlls in a nuget package have the same version in the \ref\ and \lib\ folders? The breakdown in Microsoft.Extensions.Configuration.Json is in System.Text.Json... S.T.J's .nuspec lists a .NET Standard 2.0 dependency to <dependency id="System.Buffers" version="4.5.1" />. So why would the System.Buffers.dll nuget cache have different versions in \ref\ and \lib\? Shouldn't they both be either 4.0.2.0 or 4.0.3.0?
There are a lot of questions out there on this - even some specifically to System.Buffers. But nobody has resolved this satisfactorily (that I can find) for a class library. I'm going to try adding a scratch website to the solution and reference the library - just to see whether .NET gets the necessary dlls/redirects in place for its only love: Web
Update
I manually added a binding redirect to 4.0.3.0 for System.Buffers... and immediately got the next mole to whack: Could not load file or assembly 'System.Numerics.Vectors, Version=4.1.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies
And so it will go, until we find a way to list everything that VS probed. And without 100% regression coverage, there's no guarantee we won't miss something when we deploy.
For an executable, dotnet publish; and ship the resulting folder is always correct.
But for a dll compiled against .net standard; I've only had success building a nuget package and referencing it and letting the compiler (whole package thereof) figure out what final dlls the project needs. You can make a nuget package with dotnet pack.
I have never needed binding redirects to link .netstandard to .net framework.
Compiling the library for specific platforms pulls the dependent DLLs into the bin folder. This makes sense in retrospect - compiling for .NET Standard is only meaningful when the target platform isn't known and won't be chosen by the developer of the library. That scenario requires a centralized package manager.
Targeting for .NET 4.8 (highest version currently supported by MIM) gave us the DLLs in the bin directory and set binding redirects in the config file.
That said, the System.Buffers.DLL version issue only went away because the .NET 4.8 dependencies were defined correctly. The Microsoft.Extensions.Configuration.Json .nuspec indicates a different assembly version than the dll that gets downloaded when compiling for .NET Standard 2.0. I don't know if that's an issue with the references when the .NET developers compiled the nuget package or an unavoidable artifact of nuget packaging itself.
My sample console application (say App1) developed using .Net Core 3.1 and it calls another .NetCore dll (Say Dll1). I have added as reference dll with "Copy Local = Yes". I am using Visual Studio 2019 as Dev environment.
It works fine in direct scenario. Means, when I set "Copy Local = Yes" in App1.
I have registered that .Net Core dll (Dll1) in GAC and set "Copy Local = No" in App1.
Now I could not load .Net Core (Dll1) and it throws below exception.
Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=66f432805192946d'. The system cannot find the file specified.
File name: 'xxxxx, Version=1.0.0.0, Culture=neutral, PublicKeyToken=66f432805192946d'
at xxxxx.Program.Main(String[] args)
My doubts:
Whether .Net Core supports calling dll from GAC?
Kindly help me to resolve this issue.
Regards,
Hari
Your Question
Does .Net Core load assemblies from the Global Assembly Cache (GAC)?
The Short Answer:
Nope
The Long Answer:
When you use an assembly, with CopyLocal = false set, it means that the Assembly (.dll file) will not be placed into the output directory of whatever you just built.
Here, .Net Core acts differently than .Net Framework:
In .Net Framework
As soon as the missing assembly is used somewhere in your executing code, the runtime environment will try to search for it, find and load it. For .Net Framework, this happens in a very specific way, which includes loading it from the GAC (Global Assembly Cache) when available.
And this is how dotnetcore does:
Those dotnetcore apps are designed to be standalones and easy to handle, and do not want to rely on their environment. You deliver all they need to know along with them. So, those apps won't go searching around for missing dlls, and they will not look into the GAC. This is the normal deployment method, and this is called "self contained deployment"
There is, however, something called the runtime package store, that can help optimizing your deployment, by defining that your .Net Core Application is not "self containing", but is deployed against a defined "framework (= where a set of libraries are defined to be present). This is called "framework dependent deployment"
If you need more Information of Framework-Dependent Deployment of .Net Core Apps
Have a look at this
Is there any GAC equivalent for .NET Core?
i'm trying to develop an application but then these warnings popped out. I have tried disabling my anti-virus (Avira) but it still won't work.
Warning 1 Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'MyAssembly.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. ConsoleApplication1
Warning 2 The referenced component 'MyAssembly' could not be found.
Can anybody please help me? Thanks!
What .NET runtime version is your application being developed with?
If the error is to be trusted, your project is say a .NET 3.5 (2.0 runtime) project but the MyAssembly library is developed in .NET 4.0 resulting in the error you see.
You cannot reference newer runtime version assemblies in an older runtime version project. You'd have to "upgrade" your project to at least match the framework version of the assembly given to you.
Right click on your project file and choose properties. Depending on what version of Visual Studio you are using this screen may look different, but go to the application tab and see what the target framework is.
Then go to the assembly you referenced in your references and check the "Runtime Version" in the properties section:
I'm using ClickOnce for installing my application written in C#. Everything worked fine till the last update after which start of my application ends with an error saying:
Could not load file or assembly MyAssembly... HRESULT: 0x80131040.
After some research I've found that there is an old version of MyAssembly located in my application's ClickOnce cache folder (C:\Documents and Settings..\Apps\2.0...). However there is an actual version in the deployment package.
I've also found this old version of MyAssembly in a standalone directory in the ClickOnce cache named after this assembly (plus some characters added).
It seems to me that for some reason ClickOnce used this old version of MyAssembly from the cache instead of the new version from the deployment package.
Uninstall/install of my application won't help.
How is this possible?
I have had the same behaviour. It mentioned the problem in another question. Since then, it has happened several times for us with different applications. One strange thing is that it behaves differently on different computers. So one computer could have been updated with the new assembly while another got the old one copied.
.NET ClickOnce deployment and wrong assemblies called after updated version
This appears to be a bug in .NET framework 3.5 SP1.
See Microsoft KB 971052.
Make sure this old assembly is loaded. You can use DllProfiler for that.