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.
Related
We are developing an add-in for Autodesk Inventor. Our software is a bunch of dll assemblies loaded into Inventor at runtime. We have decided to use the Microsoft Enterprise Library 5.0 for logging and exception handling.
Now we have a problem, because it turns out Inventor 2013 uses Enterprise Library 4.1. When our add-in is loading, it fails to load the proper version of an assembly, because Inventor already has an older version in its Bin directory.
Options we have considered so far:
During deployment of our product, overwrite the old libraries in Inventor's Bin folder
Use EL 4.1 in our assemblies
Both are bad and I'm running out of ideas, so I'm asking for help.
Option 1 raises this question: is the Enterprise Library backwards compatible and will replacing those DLL's in the Bin folder cause problems? I have tried it, Inventor doesn't complain and works as expected (haven't checked the EL functionality).
Option 2 makes us use the older version and binds us to the version Autodesk is using, so we would have to watch when they upgrade, especially when they release a new version of Inventor.
What is the best practice in this scenario?
UPDATE:
We solved this by just putting the newer version of Enterprise Library in GAC. I think what happened here was that .NET tried loading the older version first (because it was higher in assembly search order) and after failing never went any further to look for the proper version. When in GAC, it correctly resolves.
From what I can see, a reasonable solution would be to embed the assemblies and access them using the ResourceManager class, this would allow you to use the newer versions whilst maintaining the parent projects logging mechanism.
You might find this question useful:
Embedding assemblies inside another assembly
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.
I am having a visual studio 2010 window service application in .net framework version 3.5 but I need to use a dll in my service which was built in .net framework version 4.0.So I have upgraded my version to 4.0 but while installing my service i am having system.BadImageFormatException.How to fix this.Please suggest some solution.
This is the error message I am getting
Error 1001.Exception occurred while initializing the installation: System.BadImageFormatExceptio: could not load file or assembly 'file://C:.....exe' or more or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
Thanks in advance
The application and the DLL (including all dependencies of each) must all be either 32-bit or 64-bit. Most likely, the binaries you are using are not. To fix the problem build or otherwise obtain access to the correct binaries.
If this is not the problem, the "remarks" section of the documentation lists all the reasons that can cause this exception to be thrown, including solutions for each.
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.