Gacutil not supported on production?

The other day I got an interesting question from a customer:

We are documenting how our production assemblies should be deployed on our production servers. At first we wanted to deploy shared assemblies through the gacutil.exe utility.
By reading
this article we realized that Microsoft’s recommendation is to use gacutil in a development environment but that it should not be used to deploy assemblies in production.

This raises the following questions: How should we deploy our assemblies in production? Why not gacutil? Any alternative to MSI?

The customer was referring to this note box:


The reason is explained in this article:

In deployment scenarios, use Windows Installer 2.0 to install assemblies into the global assembly cache. Use Windows Explorer or the Global Assembly Cache tool only in development scenarios, because they do not provide assembly reference counting and other features provided when using the Windows Installer.

The preferred installation method is a MSI package, but using the appropriate command line switches you can still use gacutil as described in

Gacutil.exe provides options that support reference counting similar to the reference counting scheme supported by Windows Installer. You can use Gacutil.exe to install two applications that install the same assembly; the tool keeps track of the number of references to the assembly. As a result, the assembly will remain on the computer until both applications are uninstalled. If you are using Gacutil.exe for actual product installations, use the options that support reference counting. Use the /i and /r options together to install an assembly and add a reference to count it. Use the /u and /r options together to remove a reference count for an assembly. Be aware that using the /i and /u options alone does not support reference counting. These options are appropriate for use during product development but not for actual product installations.



Quote of the Day:
An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered.
–G.K. Chesterton

Comments (6)

  1. Trouble is the GacUtil is part of the DotNet SDK, which I believe you cannot distribute.  This means its still not a viable option for ISVs.  

  2. True. I don’t have an official statement at this regard at the moment (I’ll try to find out and update the post, I admin I’ve not fully read the EULA which comes with the SDK, shame on me!), but there are two facts:

    1. The SDK is freely available from the MSDN site
    2. If you copy gacutil on a machine without the SDK (but of course with the Framework installed) you should be able to run it anyway

    So, unless using a single utility without the entire SDK is forbidden by the EULA (or maybe it falls in a “non supported” area), you might be able to use it in production even if you’re an ISV.

  3. Ok, got a quick discussion with my team:

    • If you downloaded the SDK for use within your organization you’re free to to use is "as is" and copy it or the contained tools on other machines. You need to carefully evaluate the "risk" of using such tools (gacutil for example could lead to unexpected assemblies being used if you use it to register an assembly that is currently in use). By the way, in the gacutil sample above, if you’re an ISV and need to distribute your software, I think the recommended way is to create your own deployment package (and include a Framwork bootstrapper if needed)
    • If you need to redistribute the tools outside your organization (e.g. to your customers) then to stay on the safe side the answer is "no, sorry". It might be possible to apply for a license but getting a redistributable license for something which is not normally reditributable is an uncommon scenario, and I’m really not sure if that’s possible.

    So you’re right Aaron, this post does not apply to ISVs…

  4. Jigar Mehta says:

    Great post!

    Any idea where does gacutil.exe saves the reference counting data? Somewhere in registry? Can we access that? Because I think windows installer saves their reference counting data at some unknown location!


  5. Procmon quickly showed this key (SgenRefCountTest is he name of my sample assembly): HKEY_LOCAL_MACHINESOFTWAREMicrosoftFusionReferencesSgenRefCountTest, Version=, Culture=neutral, PublicKeyToken=d8c3a836383af51d, processorArchitecture=MSIL. There is another key below that one (not sure where the name comes from), and then on the right pane you have a string entry for every application which references the target assembly.

    I’m not sure if manipulating those values is safe, or a good idea (and I guess not supported)…

Skip to main content