.Net: Assemblies (Part – 5)

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

Microsoft .Net - New assembly version

Microsoft .Net – New assembly version

Observe that new assembly attributes are added to .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 .assembly hello section.

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

gacutil /i hello.exe

Lets look at GAC where our assembly 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 beautiness of an assembly. Unlike a normal DLL it allows to keep multiple versions side-by-side.

We knew, we have created one test application testapp.exe to test our hello assembly. Lets run it.

It showing “Hello, World!” message on the screen. Wonderful! Its working fine! Great job!

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

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

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

Lets 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"?>
          <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <assemblyIdentity name="Hello" culture="neutral" publicKeyToken="f5d51cce1ddbf0b7" />
              <bindingRedirect oldVersion="" newVersion=""/>
  • Keep this file where our application testapp.exe 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 testapp.exe application, it will check the configuration file and based on the values mentioned in the configuration file it picks up new hello assembly. So, it displays “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 SayHello method. If you remove this method in 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 using by multiple applications. Do we need to create configuration file for each application? Do you think this is a good idea? Certainly not.

Lets explore other options in our next article.


Leave a Reply