It is common to share an assembly between several applications.
Typically you will install the assembly to GAC. When you want to service the assembly, you create a publisher policy assembly, and install the publisher policy assembly to GAC. All the applications automatically pick up the service.
There are other solutions if you don’t want to install the assembly to GAC. You can put the assembly in a well known location. You then add a codebase hint for the assembly in machine.config. When you service the assembly, you upload the updated assembly in a new well known location and modify the codebase hint in machine.config.
If you don’t want to modify machine.config, you still have options. You can add the codebase hint to the config file for all the applications that want to use the assembly. When you service the assembly, you update all the application config files to point the assembly to the new location. The advantage of this option is that the change only affects the applications you modified, instead of all the applications in the machine, as the first and the second option do.
The discussion above assumes you follow the proper versioning guideline, and generate a new assembly whenever you service your assembly.
For one assembly on one machine, the solution is probably OK. But for several hundred of assemblies on thousands of machines, this clearly does not scale.
If there is a way for an application config file to include another config file, you can then have a common config file residing in a well known (network) location, and have all the application config files include that config file. When you service those assemblies, you change that one common config file. Suddenly all the applications are serviced automatically.
The way for application config file to include another config file, is a feature we introduced in .Net 2.0. This is called “linkedConfiguration”.
The syntax for linkedConfiguration is following:
You will specify the config file you intend to include in the href attribute.
Notice the assemblyBinding element is one level under <configuration>, instead of under <configuration><runtime>, where the normal binding policy resides.
The rules for linkedConfiguration are: