| 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 |
Introduction
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
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\<version>\Addins\MyAddIn.Connect]
"LoadBehavior"=dword:00000000
- For add-ins registered for all users:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\<version>\Addins\MyAddIn.Connect]
"LoadBehavior"=dword:00000000
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 back to the 'Resources for Visual Studio .NET extensibility' section for more articles like this
|
