One of the greatest advantage .NET offered over earlier windows deployment model was that you no longer had to rely on Registry settings to install/deploy the application. .NET works with configuration files which are primarily XML files. These XML files define the tags which replace the need for registry keys. This also helps in XCopy deployment of the applications.
Whoever has worked with .NET must be aware of what assemblies are. If you have any doubt regarding assemblies I would suggest reading following article, as it is outside of the scope of this blog to explain about assemblies. Basically there are two types of assemblies private and public or shared assemblies. Private assemblies reside within the application or in any of its su folders. Assemblies which can be used across applications can be installed in a special folder called Global Assembly Cache (GAC). Microsoft also provides a framework tool for managing shared assemblies.
The runtime searches for assemblies in a specific order. This process of locating the assemblies is called Probing. Probing is applicable only for private assemblies as they are stored within the application directories.
Shared assemblies are located using different mechanism. Each application can have a configuration file of its own. In case of windows applications, it is same as the name of the exe with .config appended to it. For. eg. if your exe name is SapleApplication.exe the config file name will be SapleApplication.exe.config. If there are many directories within the root directory and the private assemblies are deployed in one or two directories, you can configure the settings to direct the runtime to probe for an assembly only in specific folders. Following code snippet is used to demonstrate the same
assemblyBindings tag of runtime element is used to specify the probing path, using the private path attribute. As a result of above settings, runtime will probe for private assemblies within the path1 and path2 subdirectories of the bin directory.
Shared assemblies are identified by the name, public key token and the culture of the assembly. .NET framework allows side-by-side execution of assemblies, which means that two versions of same assembly can be loaded by the runtime without affecting the programs which use individual versions. In case the older version of the shared assembly had some bugs which were fixed in the next version, the publisher of the assembly can create a file called publisher policy file or policy file. This file contains the configuration setting for redirecting the runtime to use newer version of the assembly wherever the older version is referenced. Policy files are also installed in the GAC. The bindingRedirect tag is used to change the dependency among assemblies. This is depicted using following code
culture="neutral" />
dependentAssembly tag is used to link the two versions of the assembly. The assemblyIdentity tag is used specify which assembly along with its public key token. The bindingRedirect tag specifies the older version of the assembly and the newer version of the same assembly which is to be used.
Once the publisher policy file is created it has to be linked to an assembly using the assmebly linker (al) tool. Refer to this article for how to use al tool. A publisher policy file is used to describe the compatibility of the assembly which is issued by the publisher. The old version attribute can be set to a range of values as well. Eg. you can say 1.1.*.*-2.0.*.*
Sometimes due to some reasons it becomes neccessary for the client applications to use the older version of the assembly even if the newer version is installed in GAC and publisher policy is supplied by the publisher. In that case the client application can override the publisher policy settings in its own apllication config file. To know more about applying publisher policies refer to msdn article.
I had encountered similar situation in one of the projects which I had worked on. We were using Sybase as backend database. To connect to the DB we were using ASE client for .NET. But due to some reason the version of Sybase was different on the development machines and the production machines. The code which was working perfectly fine on development boxes was throwing exception in the production environment. After investigating we realised the difference in versions and the publisher policy which was installed in GAC. We had to configure the application not to apply publisher policy and work with the older version of Sybase.
Hope this is of some help. Happy Programming :)
No comments:
Post a Comment