Why do you use GAC APIs?


I can think of three reasons that you need to use GAC APIs, instead of the existing tools.

1. Customized installer: You need to install assemblies to GAC, and you cannot install MSI.
Example: The assemblies are created when your application runs. So those assemblies do not exist when the application is installed. You cannot use MSI in this case.

2. Customized Management tool:
The existing tool does not give enough flexibility to managed GAC. The cache viewer shell extension is good at visualize GAC’s content, but you can’t show trace reference, and you can’t install/uninstall assemblies with trace reference. Gacutil has enough features. But it is a command line tool and you want a GUI application. So you decided to roll your own tool.

3. Migration
Say you have some assemblies installed on machine 1, and you want to migrate them to machine 2.

What is your reason to use GAC APIs?

Comments (4)

  1. Kevin Westhead says:

    Option 1 in our case, although it’s not because we’re generating assemblies on the fly but rather that we’re still tied to pre-MSI installer technology. I imagine that MSI will be considered as more and more .NET code gets written, but right now we’re still primarily shipping COM and Win32 bits.

  2. David Levine says:

    All three reasons are valid. I am writing a custom sofware distribution service, and part of its requirements is the ability to manage the GAC.

    For example, I need to download both managed and unmanaged components from a server and install the assemblies into the correct target location, one of which may be the GAC, without necessarily requiring an MSI file.

    Item 3 is similar to an XCOPY service I was thinking of that would detect GAC dependencies and copy and install them to target machines along with the XCOPed files. Or perhaps to xcopy the gac itself.

    Another reason is to compare two machine GAC configurations to determine differences, or to compare an existing machine to a preconfigured standard, perhaps defined in a manifest. This would be useful in determining what a particular machine needs to have installed on it, or to aid support personnel in trouble-shooting customer problems.

    Another is to use the trace references to detect corruption – i.e. a program that installed a GAC component is no longer present, and describe what it should have been.

    Bottom line – you can never have too much diagnostics.

  3. Boris says:

    Well, I would like to use GAC APIs to iterate through GAC and identify assemblies which support certain interface, say IMyInterface.

    The bottom line is to implement GAC based plugins mechanism which will allow dynamic loading of assemblies on the fly from GAC.

    All described plugins discovery methods I am aware about based on plugins directory, common place where all plugins are stored. However that plugins discovery mechanism obviously doesn’t support versioning and side by side execution.

    Unfortunately I can’t use GAC APIs for described above purpose. Do you agree?

    Can you recommend any other approach to implement described above functionality?

    Thanks

  4. Boris,

    The approach you take sounds odd to me. To show an analog in Win32 world, it is like enumerating everything in System32, and call LoadLibrary and GetProcessAddress to see if a particular dll exports certain APIs.

    One option can you choose is to ask user to register a plug in. Once you have the file, you can have do whatever you want to do, like storing it in a directory with version aware.

    I can talk about my thinking on plug in in a separate blog. But I never thought you will use GAC APIs for that purpose.