GAC - Global Assembly Cache is just a run-time thing.
People familiar with .NET will surely know about GAC. Its just a one stop for any application running on the .NET framework to look for the assemblies (DLLs). When ever we run any .NET application, the framework will look for the referenced assemblies in the GAC. Note that even the version number of the DLL must match. If the application was compiled with an assembly 'A' of version 1.0 and you currently have anything, but 1.0, the application will not run. It needs exactly what it was compiled with. And the best part is that multiple versions can co-exist in the GAC
But this GAC look up happens only at the run-time. In Visual Studio, we will add the required assemblies for a project under the project references. These references will be pointing to the locations where the assemblies are present on the file-system and may be remote locations in case of web references. When we build the project the compiler will look at these locations and not in the GAC. Now if you are referencing an older assembly but we have a newer version in the GAC, then the project will compile but not run. Because at run-time the framework will look for the older assembly but does not find it in the GAC. So be sure of updating your references when your assembly of a particular version in the GAC is updated or replaced by an assembly of a different version.
This problem becomes still more evident and a little tricky when we are using an assembly(say assembly 'A') which again depends on another assembly (say assembly 'B'). And in such a case the problem can become evident even before compilation itself(If the assembly 'B' is related to designer of the Visual Studio). Say assembly A-1.0 was built using assembly B-1.0. Now when we use assembly 'A' by adding it as a reference to our project we are using assembly 'A-1.0' that was built using assembly 'B-1.0'. 'B' does not come into picture during compilation at all. When we build our project and run it, the framework looks for 'A-1.0' and finds out that it needs 'B-1.0' and finds both in GAC and runs the application. Here as 'B' does not come into picture during compilation, it is sufficient if we have it GAC, where as 'A-1.0' has to be at some location on the file system (either local or remote).
Now if 'B' in the GAC is updated, i.e 'B-1.0' is replaced by something like 'B-1.1', and you try to run the previously built application, it fails. Though the assembly referred by you , 'A-1.0' has not changed, the assembly 'B' which is necessary for 'A' has changed. So at runtime the .NET framework will search GAC and the current-folder for 'B-1.0' and as it would not be found, the application fails.
There are a couple of other posts about GAC and references in VS2005. Look out for those.
People familiar with .NET will surely know about GAC. Its just a one stop for any application running on the .NET framework to look for the assemblies (DLLs). When ever we run any .NET application, the framework will look for the referenced assemblies in the GAC. Note that even the version number of the DLL must match. If the application was compiled with an assembly 'A' of version 1.0 and you currently have anything, but 1.0, the application will not run. It needs exactly what it was compiled with. And the best part is that multiple versions can co-exist in the GAC
But this GAC look up happens only at the run-time. In Visual Studio, we will add the required assemblies for a project under the project references. These references will be pointing to the locations where the assemblies are present on the file-system and may be remote locations in case of web references. When we build the project the compiler will look at these locations and not in the GAC. Now if you are referencing an older assembly but we have a newer version in the GAC, then the project will compile but not run. Because at run-time the framework will look for the older assembly but does not find it in the GAC. So be sure of updating your references when your assembly of a particular version in the GAC is updated or replaced by an assembly of a different version.
This problem becomes still more evident and a little tricky when we are using an assembly(say assembly 'A') which again depends on another assembly (say assembly 'B'). And in such a case the problem can become evident even before compilation itself(If the assembly 'B' is related to designer of the Visual Studio). Say assembly A-1.0 was built using assembly B-1.0. Now when we use assembly 'A' by adding it as a reference to our project we are using assembly 'A-1.0' that was built using assembly 'B-1.0'. 'B' does not come into picture during compilation at all. When we build our project and run it, the framework looks for 'A-1.0' and finds out that it needs 'B-1.0' and finds both in GAC and runs the application. Here as 'B' does not come into picture during compilation, it is sufficient if we have it GAC, where as 'A-1.0' has to be at some location on the file system (either local or remote).
Now if 'B' in the GAC is updated, i.e 'B-1.0' is replaced by something like 'B-1.1', and you try to run the previously built application, it fails. Though the assembly referred by you , 'A-1.0' has not changed, the assembly 'B' which is necessary for 'A' has changed. So at runtime the .NET framework will search GAC and the current-folder for 'B-1.0' and as it would not be found, the application fails.
There are a couple of other posts about GAC and references in VS2005. Look out for those.
No comments:
Post a Comment