Error loading .Net assembly

Question

I am trying to solve any problem when the ASSEMBLY assembly dynamically loads at run time using

Assembly.loadFrom("filePath") 

in some dll myDLL1. The same ASSEMBLY was statically linked to another myDLL2 DLL in the same solution, and there are calls for both DLLs from the solution, myExecutable, say. This works fine if the exact same ASSEMBLY is found in the folder to which the solution is being deployed. ASSEMBLY has, say, .Net version 1.0.1.1 and file version 1.0.1.7

Now a new version of the file 1.0.1.8 from the collection has been published, which has the same version of .Net version 1.0.1.1 as version 1.0.1.7 of the ASSEMBLY file. Assemblies have strong names, and the public key for different versions of files is also different. First question: is this reasonable?

If I put the new version of the assembly file in the folder where the solution is being deployed, now I get an error message. I suppose this is because the .Net runtime is unhappy with the public key token that does not meet the expectation in accordance with the myDLL1 manifest, can this confirm?

The output of fuslogvw with names adapted to the description of the example is as follows:

 Assembly Binder Log Entry (11.11.2011 @ 13:38:52) The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified. Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll Running under executable myExecutable --- A detailed error log follows. === Pre-bind state information === LOG: User = xxxxx LOG: DisplayName = ASSEMBLY (Partial) LOG: Appbase = (folder the solution is deployed to) LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = NULL Calling assembly : myDLL1, Version=2.1.2.0, Culture=neutral, PublicKeyToken=..... === LOG: Start binding of native image ASSEMBLY, Version=1.0.1.1, Culture=neutral, PublicKeyToken=xxxxxxxx. LOG: IL assembly loaded from ASSEMBLY. WRN: No matching native image found. LOG: Bind to native image assembly did not succeed. Use IL image. 

I tried using bindingRedirect for version 1.0.1.1 first with the public key token from the ASSEMBLY file version 1.0.1.8 created by sn -Tp, and also using the public key token for ASSEMBLY from the manifest information myDLL1 corresponding to the file version 1.0.1.7, but I getting the same error. I also added redirection information to myExecutable configuration.

Then I tried to use bindingRedirect for version 1.0.1.2 with the public key token of the new ASSEMBLY version. A new version of the file is uploaded, but then I get, of course, a revision mismatch.

Can someone tell me how to use the new version of the ASSEMBLY file in this setting without replacing the whole solution statically linked to the new version of the file, which of course works?

TIA and best wishes,

Thomas

Answer 1

Well, after several studies and experiments, I could now answer my own question. Here is what I found:

• ..Net framework will refuse to load the assembly for the application if the assembly is not signed with the same key with which the assembly was associated with which the application was statically linked at compile time. It seems that this cannot be changed using the application.config file or the machine.config file, although I could not find evidence for this in the documentation. After thinking about this for a while, I think this is reasonable behavior, as it proves that the application user is working with the same assembly that the developer used.

• The degree to which I am sure that 1) is correct is as follows: if the key is kept the same for different versions of the assembly, then forwarding redirection is great for these versions. This is true for rewriting using the application.config file as well as the machine.config file.

The same configuration files stop working, however, as soon as the assembly is signed with a different key. The disgusting thing in this case is that the log created by fuslogvw tells you that the binding failed for some other reason (e.g. version number mismatch). He does not complain about the wrong public key token.

Another nasty thing is that you can add the public key token as an attribute of the XML tag in the configuration files, which in the beginning leads me to the wrong way. I do not know why the public key can or should be added to the configuration files, since .Net can extract this information from the binary assembly and the application.

I do not know if the behavior described in 1) can be changed by messing with the security.config.Net Framework file. (Although even if it could be changed in this way, it will probably lead to security risks that I would not want to create on my PC).