Share via


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

  • Anonymous
    September 19, 2004
    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.
  • Anonymous
    September 19, 2004
    The comment has been removed
  • Anonymous
    September 23, 2004
    The comment has been removed
  • Anonymous
    September 23, 2004
    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.