Three years ago I wrote the article PRB: ‘Could not copy temporary files to the output directory’ error building Visual Studio .NET add-in explaining the common cause for that error when running an add-in project.

There is a second cause that happens when you have a dead devenv.exe process, which can happen from time to time while debugging add-ins, interrupting abruptly the debugging session, entering the computer in sleep mode or something else that I can’t determine for sure, but the fact is that you end with two devenv.exe instances in memory, a visible one with your add-in project and a hidden one locking the DLL. Since this second one doesn’t have a visible window, you have to use the Processes tab of the Task Manager to see it. And of course, you want to kill it, but how do you know which devenv.exe process to kill? The Task Manager of Windows is not of much help, but you can use the much more powerful Process Explorer utility from the former SysInternals (now owned by Microsoft and provided through Microsoft TechNet):

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

With Process Explorer, which can replace the Task Manager when pressing Ctrl+Alt+Del and clicking the Task Manager button (Options, Replace Task Manager menu) you can right-click a devenv.exe process and select the “Bring to Front” menu. If the main IDE window brings to front, you know that the devenv.exe process is active. Otherwise, it is a dead one and you can kill it. Before using Process Explorer, I always had to choose randomly and I almost ended killing the wrong one.

Quite a few months ago I published a post that became quite popular about the Frustrations with command-line add-ins for Visual Studio, where it was mentioned a bug in the Visual Studio 2005 IDE which didn’t loaded command-line add-ins. Today I have found that Microsoft released a hotfix for this problem:

FIX: A command-line add-in does not load when you start the Visual Studio 2005 IDE
http://support.microsoft.com/kb/934517

While it would have been better not to introduce this bug in VS 2005 SP1, it is nice that Microsoft fixed it after SP1 and the patch for Windows Vista, when VS 2008 was about to be released. It is also very very nice that you can download hotfixes without calling MS Support Services.

Now, the funny thing: the KB article says that this hotfix introduces an incompatibility with the XBox 360 SDK. It’s a good thing that I am in the Sony PS3 / PSP camp 😉

BTW, I found this hotfix while searching the list of hotfixes for Visual Studio trying to solve a very nasty problem with the VBC compiler (VB.NET) of VS 2008 that is crashing. It’s nice to see that there is a growing list of hotfixes, although none for my problem (it seems). UPDATE (8 August, 2008): I narrowed the problem to a custom attribute applied to a property and seeing the list of fixes of VS 2008 SP1 beta for VB.NET it mentions Connect ID 322131: “An application that contains a custom attribute causes the compiler to crash” so hopefully that’s my fix 🙂

When you have a variable (EnvDTE.CodeVariable) or function (EnvDTE.CodeFunction), their Type property returns an EnvDTE.CodeTypeRef with information about the type. If the type is an array then CodeTypeRef.Rank returns the dimensions (1, 2…). The problem is that if it is not an array, it throwns an exception, which can hurt the performance if you do that with lots of functions or variables (think an operation that processes the whole code of a solution). It would be much more better if the automation model returns 0 for the Rank if the type is not an array, but chances of MS changing that at this point are minimal, so as a workaround, you should try to call the Rank property only if you know in advance that it is an array (and therefore it is not going to throw an exception). You can know using the CodeTypeRef.AsString property: if the result contains “(” for VB.NET or “[” for C#, you know it is an array.