Home/ Questions/Q 6856215
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T01:51:26+00:00

I’m trying to anyalyse a problem where an assembly ASSEMBLY is dynamically loaded at

  • 0

I’m trying to anyalyse a problem where an assembly ASSEMBLY is dynamically loaded at runtime using

Assembly.loadFrom("filePath")

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

Now a new file version 1.0.1.8 of ASSEMBLY was published which has exaxtly the same .Net version 1.0.1.1 as file version 1.0.1.7 of ASSEMBLY. The assemblies have strong names and the public key token of the different file versions are different, as well. First question: is this reasonable?

If I place the new file version of the assembly into the folder the solution is deployed to, I now get an error. I assume this is because .Net runtime is unhappy about the public key token which is not as expected according to the manifest of myDLL1, could somone confirm this guess?

The fuslogvw output with names adapted to the example description 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 to use a bindingRedirect to version 1.0.1.1 first with the public key token from ASSEMBLY file version 1.0.1.8 as produced by sn -Tp and also with the
public key token for ASSEMBLY from the manifest information of myDLL1 corresponding to file version 1.0.1.7, but I get the same error. I also added the redirect Information to the myExecutable configuration.

I then tried to use a bindingRedirect to version 1.0.1.2 with the public key token
of the newer version of ASSEMBLY. The new file version is loaded but then I get, of course, a revision mismatch.

Can anyone tell me how to use the new file version of ASSEMBLY in this setup without having to replace the whole solution statically linked to the new file version, which, of course, does work?

TIA and best regards,

Thomas

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ok, after doing some more research and experiments I could now answer my question myself. Here’s what I found:

    1. The .Net framework will refuse to load an assembly for an application if the assembly is not signed with the same key the assembly had against which the application was statically linked at compile time. It seems this cannot be changed using the application.config file or the machine.config file, though I could not find proof for this in the documentation. After thinking about this for a while I think this is reasonable behaviour, as it kind of proves that the user of the application works with the same assembly the developer had used.

    2. The extent to which I’m sure now that 1) is correct is as follows: if the key is kept the same for different versions of the assembly, then binding redirection works fine for these versions. This is true for both rebinding using an application.config as well as a machine.config file.

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

    The other nasty thing is that you can add the public key token as an attribute to the XML tag in the config files, which lead me on the wrong road right in the beginning. I do not know why the public key may or should be added to the configuration files, as .Net can retrieve this information from the assembly and application binary.

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

    • 0