What's the 'correct' way of registering/installing an Assembly to the GAC?

Question

There seems to be lots of different ways to register assemblies with the GAC, as in, they 'work'. However, what's the "proper" way of doing it?

In response to Lou Franco (and gacutil):

I'm using Gacutil for development, but it seems to me to be not the proper way to install it, since gacutil isn't included in the basic .NET utilities past .NET 1.1 - it's only a developer tool.

Additional: Gacutil (as seen in responses below) is not redistributable, and therefore should not be used in any app that you intend to give to people who are not developers. AKA, customers. See This blog post (and comments) by Aaron Stebner.

In response to using WIX:

WIX might be great and all, but how does it work under the hood? What details makes the way WIX installs the assembly the right way to install it? How does it look it up? Is it a system/.NET call? Is there some call in a dll buried somewhere in System32 that needs to be made?

(Edit: it looks like WIX uses MSI under the hood. See my comments in the accepted answer.)

Final edit: It looks like the correct way to install an assembly to the GAC is using windows installer, and nothing else. I'm going to give Wix a try. Thanks all!

Answer 1

With Wix I would do something like this:

<DirectoryRef Id="MyDirectory" >
    <Component Id="MyComponent" Guid="PUT-GUID-HERE" DiskId="1">
        <File Id="MyAssembly" Name="MyAssembly.dll" Assembly=".net" KeyPath="yes" Source="MyAssembly.dll" />
    </Component>
</DirectoryRef>

When you use the attribute Assembly=".net" for a file in WiX, it will create entries in the MsiAssembly and MsiAssemblyName table for this component and mark it as a GAC component.

Answer 2

http://blogs.msdn.com/astebner/archive/2006/11/04/why-to-not-use-gacutil-exe-in-an-application-setup.aspx

It looks like the gacutil should be avoided; it's not a redistributable app. Instead, the 'proper' way of installing them seems to be using MSI, one way being WIX, as posted by CheGueVerra or another script.

Answer 3

Use System.EnterpriseServices.Internal.Publish's GacInstall method.

Advantages: Seems to be an internal tool. Probably does all the right stuff.

Disadvantages: As part of an installer, you'd still need to make and run an app that calls this (unless the installer you make is a custom app that does it anyway).

Answer 4

Doesn't your installer maker have a way of installing an assembly into the GAC? On your own, I'd say GACUTIL:

http://msdn.microsoft.com/en-us/library/ex0ss12c(VS.80).aspx

Answer 5

If you don't want to handle the gacutil stuff yourself, you can always create a setup project in visual studio.

But I'd stick with gacutil myself.

Answer 6

use gacutil.

Advantages: seems to always work. Disadvantages:

• must package an additional executable with your installer.
• As a development utility, seems to have additional side effects (like forcing the install no matter what).
• Should NOT be included in any redistributable given to customers.

Answer 7

The best way is to use gacutil -i Library.dll.

The only problem with gacutil is that it is not in the default PATH of the system. It is however in a fixed location relative to the windows directory, for a given .Net Framework version. So you can use the following command line to execute it from anywhere:

%SystemRoot%\Microsoft.Net\Framework\v1.1.4322\gacutil -i

PS: just copying your assembly into c:\windows\assembly won't work. Explorer only shows a simplified view of the folder, which contains in fact lots of different folders for different kinds of assemblies. Doing a copy in it from an installer won't trigger all the operations done by explorer on a drag-and-drop. (written here because I don't have enough reputation yet to comment on other posts).

Answer 8

copy directly to %WINDIR%\Assembly.

Advantage: Straightforward.

Disadvantage: AFAIK, %WINDIR%\Assembly just happens to be where it is right now, and it's location is subject to change. This would make it break in future versions of windows or if that folder's behavior chaneges. This probably isn't the right way.

Extreme Disadvantage: As said by madmath:

just copying your assembly into c:\windows\assembly won't work. Explorer only shows a simplified view of the folder, which contains in fact lots of different folders for different kinds of assemblies. Doing a copy in it from an installer won't trigger all the operations done by explorer on a drag-and-drop. (written here because I don't have enough reputation yet to comment on other posts).