PRB: 'Could not copy temporary files to the output directory' error building Visual Studio .NET add-in.

Author: Carlos J. Quintero (Microsoft MVP) Applies to: Microsoft Visual Studio .NET 2002
Date: August 2005   Microsoft Visual Studio .NET 2003
Updated: March 2013   Microsoft Visual Studio 2005
      Microsoft Visual Studio 2008
      Microsoft Visual Studio 2010
      Microsoft Visual Studio 2012

When you build a Visual Studio .NET add-in, you get the error "Could not copy temporary files to the output directory".

More Information

This error happens because of this sequence of steps:

  • You create an add-in using an instance of Visual Studio .NET.
  • You debug the add-in, which opens a second instance of Visual Studio .NET.
  • If the add-in was marked to load on startup, it is loaded automatically. Otherwise, in the Add-In Manager of this second instance, you load the add-in but you also mark it to load on each startup (to avoid loading it manually again).
  • In the next session after closing Windows or turning off the computer, when you load the first instance of Visual Studio .NET with your add-in source code, the add-in is loaded too, because it was marked to load on startup. If you try to compile it at this point, you get the error "Could not copy temporary files to the output directory".
  • If you go to the Add-in Manager and unload it, you still get the error. This is because the add-in is a managed assembly which is loaded in an AppDomain, and assemblies can not be unloaded from AppDomains once loaded, you need to unload the whole AppDomain. So, you need to go to the Add-in Manager, mark the add-in NOT to load on startup, close Visual Studio .NET to unload the AppDomain and open it again. Since the add-in is not loaded on startup this time, you can now compile it.

You can avoid this annoying procedure in several ways:

  • For add-ins using COM registration (all Visual Studio versions):

    At the start of or at the end of each Windows session, or when you execute your backup script (assuming that you run one just before closing Windows each day), run a script that changes the LoadBehavior of your add-in. For example, you can create a deactivate_myaddin.reg file with this content:

    • For add-ins registered for the current user:

      Windows Registry Editor Version 5.00
    • For add-ins registered for all users:

      Windows Registry Editor Version 5.00

    where <version> can be:
    • 7.0 for Visual Studio .NET 2002
    • 7.1 for Visual Studio .NET 2003
    • 8.0 for Visual Studio 2005
    • 9.0 for Visual Studio 2008
    • 10.0 for Visual Studio 2010
    • 11.0 for Visual Studio 2012

    Then your script could include this line to merge that file into the Windows registry:

    regedit.exe /s "deactivate_myaddin.reg"
  • For add-ins using XML registration (Visual Studio 2005 and higher):
    • For Visual Studio 2005 and 2008 the simplest way to avoid the problem is to hold the left Shift key of the keyboard while Visual Studio is loading. That prevents add-ins being loaded even if they are marked to load on startup. This trick only works with Visual Studio 2005 or 2008, not with 2010 (which removed this trick to avoid a conflict with the Shift key used in Windows 7 to launch a new instance of an application).
    • For Visual Studio 2010 and higher you can add the /SafeMode switch to the shortcut to devenv.exe that you use to load the code of the add-in. That would disable the Add-in Manager for that instance (and therefore add-ins are not loaded). When you debug the add-in, the second instance can use the Add-In Manager as usual since it is not affected by the modified shortcut of the first instance. The /SafeMode approach works too with Visual Studio 2008, but not with Visual Studio 2005 due to BUG: The /SafeMode command-line switch of Visual Studio 2005 doesn't prevent the loading of add-ins.

Go to the 'Visual Studio Extensibility (VSX)' web site for more articles like this (Articles section)