Coffeehouse Thread

27 posts

Where is GACUTIL?

Back to Forum: Coffeehouse
  • Rossj

    Help - I've lost it.  I installed a .Net 2.0 runtime today and it didn't install gacutil ... anyone know..

    a. Why?
    b. Where I can find it ...

  • Yggdrasil

    Rossj wrote:
    Help - I've lost it.  I installed a .Net 2.0 runtime today and it didn't install gacutil ... anyone know..

    a. Why?
    b. Where I can find it ...


    a. GACUTIL doesn't come with the .NET Runtime, but with the .NET SDK - also a free download, but not part of the basic redistributable. The SDK is installed with Visual Studio, so development machines always have it.

    Yes, this sucks big-time. And no, there aren't any managed APIs that can register/unregister things in the GAC. GACUTIL binds to unmanaged functions.

    I'm guessing you need this for deployment? There are several ways to go about it:
    1) Bundle GACUTIL.EXE with your installation package.
    2) Install in the GAC by copying your DLL into C:\WINDOWS\Assembly. This isn't a perfect solution - I'm pretty sure only copying from Windows Explorer does the trick, and other methods may not work.
    3) Install in GAC using your MSI Installer of choice - the built in Visual Studio Installer project can install assemblies in the GAC simply by adding a Global Assembly Cache folder as part of the destination filesystem.

    If you need GACUTIL for other purposes - cleaning the Download Cache or whatnot - you'll have to find alternate ways of doing it. Sad

  • Sven Groot

    Yggdrasil wrote:
    Yes, this sucks big-time. And no, there aren't any managed APIs that can register/unregister things in the GAC. GACUTIL binds to unmanaged functions.

    Actually, there is a managed API that can install an assembly in the GAC: System.EnterpriseServices.Internal.Publish.GacInstall. I've used it, it works great.

  • Yggdrasil

    Sven Groot wrote:
    
    Yggdrasil wrote: Yes, this sucks big-time. And no, there aren't any managed APIs that can register/unregister things in the GAC. GACUTIL binds to unmanaged functions.

    Actually, there is a managed API that can install an assembly in the GAC: System.EnterpriseServices.Internal.Publish.GacInstall. I've used it, it works great.


    Is this new in 2.0? I don't remember it there in 1.1.
    And while I've used the EnterpriseServices.Internal namespace before (to create IIS virtual directories), I would hesitate recommending its use. I don't think they're committed to keeping it there without breaking changes.

  • Sven Groot

    Yggdrasil wrote:
    
    Sven Groot wrote: 
    Yggdrasil wrote: Yes, this sucks big-time. And no, there aren't any managed APIs that can register/unregister things in the GAC. GACUTIL binds to unmanaged functions.

    Actually, there is a managed API that can install an assembly in the GAC: System.EnterpriseServices.Internal.Publish.GacInstall. I've used it, it works great.


    Is this new in 2.0? I don't remember it there in 1.1.

    The docs say it's 2.0, 1.1, and 1.0 compatible. I've only used it in 2.0 though.

  • Yggdrasil

    Sven Groot wrote:
    
    The docs say it's 2.0, 1.1, and 1.0 compatible. I've only used it in 2.0 though.

    Cool. Didn't know about it. I'll keep it in mind.

  • Rossj

    Thanks guys, great help. I actually needed it for a quick pilot where I wrote a quick mockup but needed stdole from the GAC - quick question - to which I don't really expect an answer, why isn't that installed with the runtime either?

  • pacelvi

    Yggdrasil wrote:
    
    Rossj wrote: Help - I've lost it.  I installed a .Net 2.0 runtime today and it didn't install gacutil ... anyone know..

    a. Why?
    b. Where I can find it ...


    a. GACUTIL doesn't come with the .NET Runtime, but with the .NET SDK - also a free download, but not part of the basic redistributable. The SDK is installed with Visual Studio, so development machines always have it.

    Yes, this sucks big-time. And no, there aren't any managed APIs that can register/unregister things in the GAC. GACUTIL binds to unmanaged functions.

    I'm guessing you need this for deployment? There are several ways to go about it:
    1) Bundle GACUTIL.EXE with your installation package.
    2) Install in the GAC by copying your DLL into C:\WINDOWS\Assembly. This isn't a perfect solution - I'm pretty sure only copying from Windows Explorer does the trick, and other methods may not work.
    3) Install in GAC using your MSI Installer of choice - the built in Visual Studio Installer project can install assemblies in the GAC simply by adding a Global Assembly Cache folder as part of the destination filesystem.

    If you need GACUTIL for other purposes - cleaning the Download Cache or whatnot - you'll have to find alternate ways of doing it.


    I disagree with this advice.

    First off, GACUTIL is part of the .Net SDK not the .Net Redistributible, therefore you are not licensed to redistribute that code.

    Secondly, .Net and the CLR were designed to mitigate the problems associated with sharing library code files that everyone calls DLL Hell, the GAC , if used improperly, reintroduces all the pitfalls that COM DLLs had

    The GAC makes xcopy deployment moot.  If you're going to use the GAC, and since you can't use xcopy now, you should really be using a installation technology that was designed for end-user application installation.. like Windows Installer (MSI).  MSI knows how to register assemblies with the end-user's GAC.  Dont hack the installation APIs by using GACUTIL.

    GACUTIL is for developers not end-users. That's why it's in the SDK but not the Redistributable.

  • Rossj

    pacelvi wrote:

    GACUTIL is for developers not end-users. That's why it's in the SDK but not the Redistributable.


    You've never shipped anything with a CCW that requires stdole have you? Why isn't stdole in the runtime? It is in my local (SDK) GAC and it is required the moment I use CCW...

  • footballism

    pacelvi wrote:

        Secondly, .Net and the CLR were designed to mitigate the problems associated with sharing library code files that everyone calls DLL Hell, the GAC , if used improperly, reintroduces all the pitfalls that COM DLLs had

        Actually, the GAC is out there for solving the infamous DLL Hell problem, because GAC only allows assemblies signed with strong names to be installed into it, so it's impossible for an assembly to overwrite another assembly, because every signed assemblies have different strong names. signed assemblies have a lot of benefits, so sometimes using GAC is a good alternative.

    Sheva

  • pacelvi

    Rossj wrote:
    
    pacelvi wrote:
    GACUTIL is for developers not end-users. That's why it's in the SDK but not the Redistributable.


    You've never shipped anything with a CCW that requires stdole have you? Why isn't stdole in the runtime? It is in my local (SDK) GAC and it is required the moment I use CCW...


    I dont know if we're on the same page.  The statement you quoted is me refering to the GACUTIL.exe binary that is in the SDK to assist developer in managing their assemblies in the GAC.

    Your sentence menions just the GAC. I dont know if you mean GACUTIL.  If you mean just the GAC, then I'll have to say I wasn't making a blanket statement to not use the GAC, just that if you use it be sure you're using it for the right reasons.

    I stand by what I said about GACUTIL.  It's MS's code and they did not authorize it's redistributibility, it also was not designed to be used with installers and what not.  That's what MSI is for.

  • pacelvi

    footballism wrote:
    
    pacelvi wrote:
        Secondly, .Net and the CLR were designed to mitigate the problems associated with sharing library code files that everyone calls DLL Hell, the GAC , if used improperly, reintroduces all the pitfalls that COM DLLs had

        Actually, the GAC is out there for solving the infamous DLL Hell problem, because GAC only allows assemblies signed with strong names to be installed into it, so it's impossible for an assembly to overwrite another assembly, because every signed assemblies have different strong names. signed assemblies have a lot of benefits, so sometimes using GAC is a good alternative.

    Sheva


    Having the DLLs in the same location as the exe's is the solution to DLL hell as well.  When I first started .Net , I immediately assumed that the GAC was good and that's where I should be putting my class libraries because of the reasons you state (code signing,etc).. but I came to the conclusion that the GAC wasn't really giving me any value that would make up for the complexity of deployment and uninstalling.  Plus realizing that trying to save hard disk space is really a false economy since the DLL's i'm making are really insignificant in size relative to the sizes of HD now.

    I've also come to agree with the train of thought that says an application should only be using the versions of the DLLs that it originally tested/shipped with and the easiest way to implement this is through shipping all the code together and only updating the consumers of DLL updates that were specifically recompiled with those updated DLLs.

    So for me at least the benifits of the GAC didn't outweight the potential costs and I stopped using it. 

    That decision process is one that everyone should make on thier own taking into account their specifics.  So I didn't intend to say no one should the GAC, I just wanted to raise some points that are not so apparent up front but ultimately everyone makes thier own decisions.

    It was GACUTIL.exe specifically that I think peopel should avoid on the client deployment side.


    The .Net Documentation has this note:

    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.

  • brockweaver

    I agree, use MSI's whenever possible.  But I'm trying to distribute an ActiveX control that interops back to a .NET assembly.  What is the prescribed GAC installation method for this situation?

    According to this thread you have to put .NET assemblies into the GAC for them to be visible to ActiveX controls hosted on a web page (and preliminary tests show this seems to still hold true, the thread is from 2003).  So I need to put my assembly into the GAC via a CAB install (aka inf).

    Is my "best" option to write a .net app which calls the EnterpriseServices method mentioned earlier just to put my needed assembly into the GAC?  That seems like a bad hack instead of a solution. 

    Could I simply do a:

    copy [assembly file name] \windows\assembly\

    and shfusion.dll will do its magic?  This is scary to me as there doesn't seem to be a good way to get failure messages, and I don't know if that even works.

    Any help would be great!  I've been scratching my head all day long on this.

  • brockweaver

    Just fyi, the only thing I could get to work in my situation (auto-install .NET 2.0 assemblies via an ActiveX control on a web page) was to write a little exe myself that calls into the System.EnterpriseServices.Internal.Publish object methods to install into the GAC and register it for interop.  I could have used regasm to do the COM portion, but since some people do not have the 2.0 runtime in their path (and I didn't want to hard code it in the .inf file), I just did it through the exe.


    If anybody wants details, I'd be happy to post them.  It took me a good 3 hours to get everything working as it should, and I see no reason for anyone to go through the same pains I did!

  • Oberon.dot

    Well, I'm interested Smiley

    I'm looking for a solution to deploy a managed dll with an unmanaged dll as a linkresource in the GAC.

  • FrankOuyang

    I need your post:)

  • KeyboardG

    Information on this would be a great help.

  • JChung2006

    GACUTIL is part of the .NET Framework SDK. If you're curious where it is in your machine and you know it's in your PATH, try WHERE GACUTIL.EXE from the command line.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.