GAC Temp and Tmp

I see people asking question about the Temp and Tmp directories under GAC.

Yes they are temporary directory fusion uses during GAC Assembly installation and uninstallation. Tmp is used for installation, and Temp is used for uninstallation.

The use of them is described in my article GAC Assemblies: Install and Uninstall.

The reason that fusion needs two temporary folders, is that fusion will always try to clean up the Temp directory used for uninstallation at the end of each installation/uninstallation. If fusion were to use the same temporary directory for installation and uninstallation, fusion may accidentally remove temporary files used by another assembly installation in progress.

Fusion does not clean up Tmp directory (used for installation). When an installation failed, fusion tries to remove the temporary directory it created during the installation. It does not touch anything else, for the same reason above.

Usually you should not see anything in Tmp unless during assembly installation. You may see things under Temp. When fusion is asked to uninstall an assembly, if the assembly is in use, fusion will be able to move the assembly to the Temp directory, but won't be able to delete it. That is OK though. Next time when get a chance, fusion will try to clean up that directory.

Comments (5)
  1. joshwil says:

    I believe that one of the questions asked however is "why does process explorer show me a path to an image in the temp(tmp) directory instead of somewhere else in the GAC where I’d expect". I believe this only happens with freshly added images and will go away after a reboot, and is due to some kernel file handle identification stuff being cached and not being updated when the file is moved from the temp directory to the final directory?


  2. Yes, Josh, you are right. Any time you open a file, close the file, move the file, you will see it happen. Nothing special about GAC.

  3. Norman Diamond says:

    > Tmp is used for installation, and Temp is

    > used for uninstallation.

    Good thing those names make it clear.  Who would want geeky stuff like tmpinstall and tmpuninstall.

    Good thing no one would be confused by historical quirks.  Consider this output from a system which was so antique that it didn’t even fully utilize long pathnames:

    C:Documents and Settingsndiamond>set




    (Mr. Zhang, I assume you didn’t code that stuff and I don’t blame you.  I thank you for reporting it, I thank you for informing readers.  Nonetheless the fact itself is laughable.  Why didn’t someone choose descriptive names?  Sheesh.)

  4. Brian Deacon says:

    Alright, this is only a tangentially related question.  But why does the Add Reference dialog in Studio 2005 (or 2003 for that matter) not have a "GAC" tab?  What is the reasoning behind this?  I know the GAC assemblies point to where they came from, and I can reference from there, but when I actually run my code, I’m going to be using the GAC’d versions anyway.

    And the registry entry that allows me to add my libraries to the .Net tab in add references also won’t let me reference the GAC, unless I want to hack the inner directory structure.

    I would vote for a "GAC://" syntax in the HintPath element.  But clearly Microsoft is discouraging this behavior.  I just don’t understand why.  It causes more trouble than it saves.  The trick I’ve learned is to just remove the HintPath element from my project files, and then Studio will reference directly from the GAC when it hunts for the assembly.

    Strange, though.  If you understand the thinking behind this move, I’d be interested to hear it.

  5. Norman, good point. Although you don’t really have to know all the stuff:)


    I kind of discussed this issue here

    The main point is to preserve predictability of the build. Not every machine has the same assembly in GAC.

Comments are closed.

Skip to main content