Updating the application with a new .net dll gives me FileLoadException?

I have a .net 3.5 application with many dlls, I tried to rebuild specific dll without building the whole application, but after replacing the old one with the new, the application throws exception as it could not load the new dll exception: System.IO.FileLoadException: Could not load file or assembly .... I understand it searches for assembly with specific version and public token, how can I solve this problem without building the application again? also the application is signe开发者_如何学God but not registered in GAC. P.S: How can I skip building the app again, or it is a must as the dll is rebuilt?

The reason you get the error is because your assembly is signed, and most likely your reference to it has the Specific Version property set to True, and your version number of the assembly you made the change to has changed. I tried many scenarios, and this was the only scenario I was able to get the FileLoadException. If you had changed the Target Framework to a newer version like 4.0, you would get a BadImageFormatException instead. Even if you say you didn't change the version number, check it anyway, or set Specific Version to False by selecting your reference, and right clicking and selecting properties.

Your exception likely looked like this:

Could not load file or assembly 'LoadedAssembly, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=889080b75eb3bad2' or one of its dependencies. The located assembly's manifest
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

But your compiled version if the assembly that is being referenced is no longer 1.0.0.0 (or whatever version, for example). In the image below (beit small), you can see that the reference property is looking for version 1.0.0.0, Specific Version is set to True, and the reference assembly is signed and is actually version 2.0.0.0, thus resulting in FileLoadException.

Resolve this by changing the version number back and recompiling, or setting Specific Version to False and rebuilding only that DLL. You do not have to rebuild your entire application.

Did you try to make use of DEVPATH environment variable? This environment variable allows you to define a directory to act as "GAC during development". All you have to do is:

1) Add the following element to your machine.config (Double check what location of your machine.config is going to be used)

• C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG OR

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG*

2) Add a new environment variable with the name DEVPATH

set devpath="e:\temp\Message_DLL\bin\Debug"     /// manually, console
/// or open windows config form - see below

3) Afterwards go to your UI App/Project and add a reference to your dll in the DEVPATH directory.

Make sure that you configured "local copy = false, specific version = false". As you might see Strong name (Starker Name) is true.

4) Now you have to compile your UI application ONCE! After that you may choose to change your source in your DLL as you wish. Because of the DEVPATH variable, your UI application will always choose the latest build of your DLL!

NOTE! I tried to start the UI application from VS but failed with load exception. BUT starting it from the explorer windows - succeeded. Seems that starting the UI application from VS causes the CLR to look somewhere else for the referred DLL.

Also you may have a look at MSDN and MSDN2.

Remarks: Use this setting only at development time. The runtime does not check the versions on strong-named assemblies found in the DEVPATH. It simply uses the first assembly it finds.

You may have a look to the following articles/webPages, too.

CodeProject - Assembly location, binding, deploying

Social MSDN Questions about DEVPATH

I think this should do the trick!

You should rebuild those assemblies referencing this new dll.

The Windows EventLog should provide more information about what couldn't be loaded. Did you introduce another dependency in the new DLL? I've encountered something similar, where a 3rd party DLL required the C++ Runtime 2005 to be installed (which is the case on most Dev-machines and also most Desktops, since it is very common).

Wild guess... can you check if the folder where the DLL lives is marked ReadOnly.

Right click on folder > Properties > uncheck ReadOnly > click Apply > choose all subfolders and files > OK.

Rebuild your solution.