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:

 

            <configuration>

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

                                    <linkedConfiguration href=“…”/>

                        </assemblyBinding>

            </configuration>

 

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:

 

  1. This feature is only meant for fusion binding policies. Only fusion understands the syntax. The included config files can have settings other than binding policies. But those settings won’t be read by anyone, nor will they have any effect.
  2. Only file:// HREF linked configurations are allowed. This includes local files, as well as UNC files.
  3. There is no constraint on the number of linked configurations per config file.
  4. The semantics is like #include in C/C++. In other words, all the linked configuration files are merged together to form one config file.
  5. This feature is only allowed in app.config. They are ignored if they are present in publisher policy/machine.config.
  6. We break the cycle if there is any.