Strong name assemblies patching problem

  • Thread starter Thread starter twoj wladca
  • Start date Start date
T

twoj wladca

Hello all,

I got application that is based on strong name assemblies. I would like to
replace one of the assembly now (create a patch) at the client side. Let say
on the clients machine there is MyAssembly.dll V1.0.0.0 and I would like to
replace it with MyAssembly.dll V1.0.0.1. They are both signed with the same
snk key. All the others application binaires have references to
MyAssembly.dll V1.0.0.0. Now If I just replace the binary application will
fail with the 'reference does not match assembly manifest' error and that is
understandable because it was compiled with version v.1.0.0.0 and not
v.1.0.0.1. What is the correct way to replace that assembly?I do not want to
ship entire application again with just one new assembly (MyAssembly
V.1.0.0.1) and recompiled all other assemblies (to refresh their manifests).
I would like to create a patch with just one assembly
 
twoj wladca said:
I got application that is based on strong name assemblies. I would like to
replace one of the assembly now (create a patch) at the client side. Let
say on the clients machine there is MyAssembly.dll V1.0.0.0 and I would
like to replace it with MyAssembly.dll V1.0.0.1. They are both signed with
the same snk key. All the others application binaires have references to
MyAssembly.dll V1.0.0.0. Now If I just replace the binary application will
fail with the 'reference does not match assembly manifest' error and that
is understandable because it was compiled with version v.1.0.0.0 and not
v.1.0.0.1. What is the correct way to replace that assembly?I do not want
to ship entire application again with just one new assembly (MyAssembly
V.1.0.0.1) and recompiled all other assemblies (to refresh their
manifests). I would like to create a patch with just one assembly
Click to expand...

If you want to replace the strong-named assembly, but you don't want to
replace the assembly that calls into it, you can use the application
configuration file (myApp.exe.config) to provide a "bindingRedirect" node
that determines the version replacemente.

<?xml version ="1.0"?>
<configuration>
<runtime>

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<dependentAssembly>
<assemblyIdentity name="myAssembly" culture=""
publicKeyToken="12345678etcetc"/>
<bindingRedirect oldVersion="1.0.0.0"
newVersion="1.0.0.1"/>

</dependentAssembly>
</assemblyBinding>

</runtime>
</configuration>
 
Thank you, it works fine.

While changing strong name assemblies additional assembly binding is
required either in app, machine or publisher policy (GAC) config files. Do
you see any adventage of using publisher policy in GAC over app config file?
Somehow I like to idea of modifying app config more than messing with
client's global assembly cache.

Regards!

U¿ytkownik "Alberto Poblacion"
 
twoj wladca said:
Thank you, it works fine.

While changing strong name assemblies additional assembly binding is
required either in app, machine or publisher policy (GAC) config files. Do
you see any adventage of using publisher policy in GAC over app config
file? Somehow I like to idea of modifying app config more than messing
with client's global assembly cache.
Click to expand...

Well, imagine the following situation: An Independent Sofwtare Vendor,
"VendorA", sells a DLL that is bought by hundreds of companies and
referenced from hundreds of programs developed by those companies. Those
programs are then sold to hundreds of thousands of customers who install
them on their computers.
One day, a critical security issue is detected in that assembly, so
VendorA prepares and updated version that they publish on their website so
that all clients using that DLL can get the problem fixed. However, just
downloading and copying that DLL is not enough. The client programs still
try to access the old version of the DLL. In order to fix this by means of
the app.config, all those hundreds of thousands of clients would have to be
instructed to edit their .config files (which may contain additional
configuration for their thousands of different .exe files, so it is not
possible to simply publish a "fixed" .config file to replace the existing
ones).
The solution is "publisher policy". A special assembly is prepared that
contains the bindingRedirect instructions. This publisher policy assembly is
signed with the same key that was used to produce the strong name for the
DLL that is being fixed. Then, VendorA prepares a Setup program that
installs both the DLL and the publisher policy to the GAC. Now, users only
neeed to download this setup program and run it on their computers. This
will fix the initial security issue on all the applications that might be
referencing the "fixed" DLL on each user's computer.
 
Thank you for the explanation. In the senario you described it obviously
make sense. However, when there is just a single application using mentioned
dll and that dll needs to be replaced, I could provide patch that contains
'fixed' dll along with updated app config or 'fixed' dll along with updated
publisher policy file. Simply, I see the benefit of installing publisher
policy file if the dll is meant to be shared amongst applications, am I
right?

In my case, however
1) Do not want to share my libraries with any other programs
2) Do not want to install my libraries in the GAC (basicaly I would have to
install entire application because currenty I do not know which dlls I will
be replacing in the future)

One more question. Does the 'fixed' dll have to installed in the GAC to be
possible to redirect assembly binding by policy file? Or it might be any
assembly put anywhere on the file system?

Regards!
 
twoj wladca said:
In my case, however
1) Do not want to share my libraries with any other programs
2) Do not want to install my libraries in the GAC (basicaly I would have
to install entire application because currenty I do not know which dlls I
will be replacing in the future)
Click to expand...

Yes, of course in such a case it doesn't make any sense to use the
publisher policy.
One more question. Does the 'fixed' dll have to installed in the GAC to be
possible to redirect assembly binding by policy file?
Click to expand...

No, you don't need to install to the GAC. The bindingRedirect works
regardless of the location of the assembly.
Or it might be any assembly put anywhere on the file system?
Click to expand...

The assembly can be located anywhere, on the condition that the binding
process is able to find it, regardless of whether you are redirecting the
version or not. This means that it can be in the same folder as the invoking
..exe, or in a subfolder named the same as the assembly, or in a subfolder
specified in the "probing privatePath" element in app.config, or in any
folder specified in the codeBase element (presuming that the assembly has a
Strong Name, which is true in your case; otherwise the codeBase would only
work for a subfolder under the .exe).
 
Back
Top