.Net – Assemblies – Create a configuration file

In our previous article, we have created a new version 1.0.0.0 for our hello assembly. The old version of hello assembly has already existed in Global Assembly Cache (GAC). Before we install the new hello assembly to GAC, let’s open the assembly through Microsoft’s ildasm.exe tool.

Observe that new assembly attributes are added to the .assembly hello section. We have added assembly title, assembly description, assembly file version, and assembly version attributes to our new hello assembly. You can find these details under the .assembly hello section.

Now we will install our new assembly into Global Assembly Cache (GAC) using the below command.

gacutil /i hello.exe

Let’s look at GAC where our assembly is installed. We have discussed locating GAC in our previous article. Once you navigate to hello assembly in GAC; it looks like below:

- hello
  - v4.0_0.0.0.0__f5d51cce1ddbf0b7
    . hello.exe
  - v4.1_0.0.0.0__f5d51cce1ddbf0b7
    . hello.exe

Observe that the two assembly versions are installed side-by-side in GAC. This is one of the beauties of an assembly. Unlike a normal DLL, it allows keeping multiple versions side-by-side.

We knew we have created one test application testapp.exe to test our hello assembly. Let’s run it.

It shows a “Hello, World!” message on the screen. Wonderful! It’s working fine! Great job!

Hey…Hey….hold on… What version of hello assembly is running when we run the testapp.exe application? It seems it is picking up an old version of hello assembly. Do you remember, in our new hello assembly, we have slightly modified the SayHello function to display the “Hello, Universe!” message? So, if it is using a new version it should display a “Hello, Universe!” message. But it is not happening.

Do we need to re-compile our testapp.exe to take the new version of hello assembly? This is also one solution. But, how do we instruct our application to take a new hello assembly without re-compile it? That is the reason, configuration files came into the picture.

Configuration files are nothing but XML files containing XML elements to instruct the applications where to look for assemblies, redirect assemblies, and several configuration settings to control the application or assembly behavior.

Let’s create a configuration file:

• Put the following lines of code into a file and save the file as testapp.exe.config. 

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="Hello" culture="neutral" publicKeyToken="f5d51cce1ddbf0b7" />
            <bindingRedirect oldVersion="0.0.0.0" newVersion="1.0.0.0"/>
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
  </configuration>

• Keep this file where our application testapp.exe is located.

assemblyIdentity – XML element is to target the assembly. We need to provide those details in its attributes.

bindingRedirect – This is useful to redirect to the new assembly version.

When we run the testapp.exe application, it will check the configuration file, and based on the values mentioned in the configuration file it picks up a new hello assembly. So, it displays a “Hello, Universe!” message. That’s what we are expecting.

Through this, we came to know that, it is not required to re-compile the test applications whenever we modify the associated assemblies. But, is this always true? That depends on how you are going to release new versions of existing assemblies. For eg: our hello assembly has the SayHello method. If you remove this method in the new version of hello assembly, all the applications calling this method will stop working. This is up to the assembly owner to decide, whether to support backward compatibility or decide to let all dependent applications to re-compile.

Think about the scenario, if our hello assembly is used by multiple applications. Do we need to create the configuration file for each application? Do you think this is a good idea? Certainly not.

Let’s explore other options in our next article.

..