Benefit of adding assembly in GAC

Question

4.20/5 (2 votes)

See more:

I have been searching for benefit of adding assembly in GAC.
I have created an assembly suppose 'myGac' then sign it and added it to GAC using GacUtil. Here i am using .Net 4.0 so my assembly is now in 'C:\Windows\Microsoft.NET\assembly\GAC_MSIL' folder. Now I wanted myGac to be available at 'add reference' dialog box of visual studio 2010 for that I add myGac location to 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\Version}\AssemblyFoldersEx\'. Now i create one console application and add the reference of myGac using 'add reference' dialog box, it works well.
I am confused why i did all this things like (sign an assembly, add it to GAC, modify regedit), even i can add reference from local drive mean a local assembly. Ok msdn and all other tutorial say it will be shareable for many application run in same machine.
1. How it is shareable??
2. If i try to make one setup file of this console application the myGac appears in 'Application Folder' this thing happen with local assembly also. How this myGac is different from local assembly.
Please do not post any link, i already have searched most of them. I m here looking for some brief description or example, if any one have.
Thank U

Posted 25-Nov-13 5:56am

Brijesh Kr

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-11-25T06:22:00

A rule of thumb would be: you can benefit from putting some assembly to GAC, if you 1) have an assembly which can be referenced by more than one product, 2) multiple products using the same assembly are optional; some may be installed or not.

Also, assemblies installed in GAC are referenced by its strong names. Referencing them in projects using them should never involve using any path names of their executable modules (PE files). This is how GAC assemblies are different from local. The are added by the Gacutil.exe: http://msdn.microsoft.com/en-us/library/aa309379%28v=vs.71%29.aspx[^].

See also:
http://en.wikipedia.org/wiki/Global_Assembly_Cache[^],
http://msdn.microsoft.com/en-us/library/yf1d93sz%28v=vs.110%29.aspx[^],
http://msdn.microsoft.com/en-us/library/6axd4fx6%28v=vs.110%29.aspx[^].

You should also consider downside of them. They may contaminate the target system. Imagine you have two applications, "productA" and "productB", both using the assembly "myLibrary". You can install them independently in any order, and the first of product installation should also install the assembly "myLibrary". Now, you uninstall "productA" (not necessarily in the same order as installation). As "productB" is still used, "myLibrary" should remain in GAC. Now, you need to install "productB". You should remove "myLibrary', to prevent GAC contamination with unused assemblies. But how to detect if there are no more products still using "myLibrary"? You have to care about all that in your installations.

I, for example, sometimes use an alternative local approach, using application configuration. I put my products using some assembly "myLibrary" in separate sub-directories, and "myLibrary" in some sub-directory shared with all such products using relative path prescribed in application config files (say, some application "myProduct.exe" will need a configuration file named "myProject.exe.config"). Such configuration file can look like this:

XML

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath=".\mySharedLibraries\myLibrary"/>
        </assemblyBinding>
    </runtime>
</configuration>

—SA