The IDE doesn't talk to the GAC. The GAC is a runtime component. In order to get the IDE to see you're assemblies you'll need to install them to a standard directory as well as the GAC. Note that the framework itself does the exact same thing (Windows\Framework\v2.0.50727). There are a couple of good reasons for this. Firstly you can't store documentation files (XML) or PDBs in the GAC. Yet the IDE won't display Intellisense data for an assembly unless it can find the XML file. Therefore you'll have to create a directory to store your assembly XML files anyway. Secondly the GAC can contain assemblies that should not be displayed as options in the IDE. If the IDE looked in the GAC (when setting up references) then you'd see assemblies even if they should never be directly referenced. The IDE actually uses a registry key to identify the paths to search when displaying the references dialog.
A standard GAC-deployed library will consist of two setup projects. The first project is a merge module containing the GAC library and it is installed in the GAC. The second project is an SDK-style setup program that installs a copy of the GAC library along with the XML files, PDBs and any samples. This second project also modifies the VS search directory in the registry so that the library shows up in the references dialog. More importantly however is that Intellisense now works with the library. The path to this registry key is HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\AssemblyFolders. It contains subkeys that are unique and identify the path to assemblies to add to the references dialog. I believe it can also be placed in HKCU to limit to a specific user.
As far as runtime is concerned when you run the app (including debugging) it'll still load GAC assemblies from the GAC first. Therefore the only issue with GAC assemblies is keeping the GAC version up to date with the SDK directory that you create.
There is absolutely no benefit to installing an assembly in the GAC as far as the IDE is concerned. The GAC is strictly a runtime feature of .NET. When you install an assembly in the GAC you are reducing the load time of the assembly, making the assembly safer to use and allowing for multiple versions of the assembly. Only shared assemblies should ever be put in the GAC.
When you load an assembly in .NET the loader has to verify the assembly is valid and a few other things. This slows things down. When you place an assembly in the GAC the verification is done at that time. Therefore when loading an assembly from the GAC the loader does not have to do any validation and thus it loads faster. The GAC is also a secure storage area so anything loaded from the GAC is considered to be hack-proof (unless a hacker gets admin privileges) because it is strongly named.
More importantly is the fact that multiple versions of an assembly can reside in the GAC. This allows applications to always run against the version they were built for rather than whatever version is currently installed. This reduces backward compatibility issues. You can do this outside the GAC but it would require that you create elaborate directory structures for the different versions and ensure that the right assembly is referenced. Even better is that runtime policies allow you to dictate that applications load specific versions of an assembly. For example if you release v1.0 of your library and then release v2.0 then apps that were built with v1.0 will continue to use the older version while newer apps will target v2.0. Now suppose that you found a serious security hole in your library and you patched both versions to v1.1 and v2.1, respectively. You can publish a runtime policy that says that apps built against v1.0 will use v1.1 anyway and those built against v2.0 will use v2.1. This allows you to fix the security hole without requiring apps to recompile.
Shared Assembly in GAC
Justin Pyfrom
What problem are you encountering Have you added the assembly to your project's references
zeljko62
thnx for the technical reply.....
Then what is the benifit of installing assembly it in GAC....
Dietz
The IDE doesn't talk to the GAC. The GAC is a runtime component. In order to get the IDE to see you're assemblies you'll need to install them to a standard directory as well as the GAC. Note that the framework itself does the exact same thing (Windows\Framework\v2.0.50727). There are a couple of good reasons for this. Firstly you can't store documentation files (XML) or PDBs in the GAC. Yet the IDE won't display Intellisense data for an assembly unless it can find the XML file. Therefore you'll have to create a directory to store your assembly XML files anyway. Secondly the GAC can contain assemblies that should not be displayed as options in the IDE. If the IDE looked in the GAC (when setting up references) then you'd see assemblies even if they should never be directly referenced. The IDE actually uses a registry key to identify the paths to search when displaying the references dialog.
A standard GAC-deployed library will consist of two setup projects. The first project is a merge module containing the GAC library and it is installed in the GAC. The second project is an SDK-style setup program that installs a copy of the GAC library along with the XML files, PDBs and any samples. This second project also modifies the VS search directory in the registry so that the library shows up in the references dialog. More importantly however is that Intellisense now works with the library. The path to this registry key is HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\AssemblyFolders. It contains subkeys that are unique and identify the path to assemblies to add to the references dialog. I believe it can also be placed in HKCU to limit to a specific user.
As far as runtime is concerned when you run the app (including debugging) it'll still load GAC assemblies from the GAC first. Therefore the only issue with GAC assemblies is keeping the GAC version up to date with the SDK directory that you create.
Michael Taylor - 10/6/06
JohnWP
There is absolutely no benefit to installing an assembly in the GAC as far as the IDE is concerned. The GAC is strictly a runtime feature of .NET. When you install an assembly in the GAC you are reducing the load time of the assembly, making the assembly safer to use and allowing for multiple versions of the assembly. Only shared assemblies should ever be put in the GAC.
When you load an assembly in .NET the loader has to verify the assembly is valid and a few other things. This slows things down. When you place an assembly in the GAC the verification is done at that time. Therefore when loading an assembly from the GAC the loader does not have to do any validation and thus it loads faster. The GAC is also a secure storage area so anything loaded from the GAC is considered to be hack-proof (unless a hacker gets admin privileges) because it is strongly named.
More importantly is the fact that multiple versions of an assembly can reside in the GAC. This allows applications to always run against the version they were built for rather than whatever version is currently installed. This reduces backward compatibility issues. You can do this outside the GAC but it would require that you create elaborate directory structures for the different versions and ensure that the right assembly is referenced. Even better is that runtime policies allow you to dictate that applications load specific versions of an assembly. For example if you release v1.0 of your library and then release v2.0 then apps that were built with v1.0 will continue to use the older version while newer apps will target v2.0. Now suppose that you found a serious security hole in your library and you patched both versions to v1.1 and v2.1, respectively. You can publish a runtime policy that says that apps built against v1.0 will use v1.1 anyway and those built against v2.0 will use v2.1. This allows you to fix the security hole without requiring apps to recompile.
Michael Taylor - 10/6/06
thedo
I have installed the assembly in GAC.....But i don'y know how to refer it from GAC in my application
Nick Hart
thnx TaylorMichaelL