http://maordavid.blogspot.com/2008/03/how-to-delete-build-agent-in-tfs-2008.html

http://blog.torresdal.net/CommentView,guid,BFEBE347-AD82-4C76-A96E-1C22AA39EFC9.aspx

Although there are plenty of tools available to extract icons from DLLs and EXEs, these are unnecessary if you have Visual Studio installed (I am using 2010). To extract an icon, do the following:

1. In Visual Studio, File -> Open -> File…
2. Select Petrel.exe -> Open
3. Expand Icon folder
4. Right-click on icon of interest -> Export…

Simple.

If you edit the sln file in a text editor, you will find a bunch of Project/EndProject statements towards the top of the file. It appears that the default startup project is the second project listed in this section (the first project, in my case at least, is the “Solution Items” project). This means you can manually move the appropriate lines for the project up to the second position and thus change the startup project.

Quite why there is no way of doing this in the UI is beyond me…

Scenario:

1. Plugin being installed using WIX-generated merge module and installer
2. Merge module has components that are potentially shared between several other plugins
• Each component is flagged as < … Shared=”yes” SharedDllRefCount=”yes”> in the merge module WXS file.
3. At some point in testing, the installer has failed on a particular machine.
4. When the plugin is uninstalled on that test machine, the shared components are not removed even if there is nothing still referencing them.

To help debug this, I ran a manual uinstall, using msiexec, with verbose logging enabled:

msiexec /x myInstaller.msi /lv c:\uninstall.log

After much wading through the printout, the following line caught my eye:

MSI (s) (BC:B8) [09:41:31:294]: Executing op: UnregisterSharedComponentProvider(Component={F84EDDFB-2E5F-401B-9649-7B7F9CC32AD6},ProductCode={CCD6CBDA-859B-4846-88CC-24F7D64A4BCA})
MSI (s) (BC:B8) [09:41:31:294]: Executing op: ComponentUnregister(ComponentId={F84EDDFB-2E5F-401B-9649-7B7F9CC32AD6},,BinaryType=1,PreviouslyPinned=1)

Specifically, the “PreviouslyPinned” count. This indicates that Windows believes something else is referencing this component.

This led me to the crucial bits of information I was lacking: (a) remembering that at some point the installer had failed, which hinted at that fact that something hadn’t been cleaned up properly, and (b) identifying how Windows keeps a track of the shared components. The latter part was obviously registry related, which led me to the following location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs

The solution was to manually delete all the relevent shared componenent entries (which are helpfully sorted by location) in that registry key. Once done, the install/uninstall cycle worked as expected.

The following page lists some approaches to debugging custom actions (see the “How do I debug a custom action/installer class?” section), however it took me fair amount of digging before I came across this nugget: running the msiexec from the command line allows you to turn on verbose logging of the install/uninstall process.  For example, the following will produce a verbose log of the uninstall process:

msiexec /x {Product Code} /l*vx somefile.log

The log file is, obviously, very detailed, however it does at least allow you to check whether, for example, a custom action is being called or not.

An initial investigation led me to suspect that Defraggler was the culprit, since this can trigger System Restores which eat up disk space. However, having checked my System Restore settings, I noted that System Restore was disabled for the D: drive, leading me to believe this was a deadend.

Next I fired up WinDirStat to try and identify what was using up so much space, however this revealed nothing unexpected – until I paid close attention to actual disk usage: although Windows calculated my totla disk usage of the order of 120GB, WinDirStat had it closer to 30GB! So, something was using about 90GB of disk without showing up in the disk scans. This again seemed to suggest a problem with System Restore, who’s files are not accessible by WinDirStat. Back to Google…

This time I turned up the following page: http://social.technet.microsoft.com/Forums/en-US/itprovistasetup/thread/578fbe25-65a4-4068-8503-bd6ad3ddaa45

Following the vssadmin instructions I discovered the following:


Shadow Copy Storage association
For volume: (C:)\\?\Volume{26f0eaa5-182a-11df-af43-806e6f6e6963}\
Shadow Copy Storage volume: (C:)\\?\Volume{26f0eaa5-182a-11df-af43-806e6f6e6963}\
Used Shadow Copy Storage space: 1.015 GB
Allocated Shadow Copy Storage space: 1.218 GB
Maximum Shadow Copy Storage space: 6.449 GB

Shadow Copy Storage association
For volume: (D:)\\?\Volume{26f0eaa6-182a-11df-af43-806e6f6e6963}\
Shadow Copy Storage volume: (D:)\\?\Volume{26f0eaa6-182a-11df-af43-806e6f6e6963}\
Used Shadow Copy Storage space: 87.576 GB
Allocated Shadow Copy Storage space: 89.996 GB
Maximum Shadow Copy Storage space: UNBOUNDED

A-ha! So, even though System Restore was disabled for the D: drive, it was still happily eating through my disk. Don’t you just love Windows sometimes?

As instructed, I ran the vssadmin Resize ShadowStorage /For=D: /On=D: /MaxSize=10GB command, with the following end result:


Shadow Copy Storage association
For volume: (D:)\\?\Volume{26f0eaa6-182a-11df-af43-806e6f6e6963}\
Shadow Copy Storage volume: (D:)\\?\Volume{26f0eaa6-182a-11df-af43-806e6f6e6963}\
Used Shadow Copy Storage space: 0 B
Allocated Shadow Copy Storage space: 0 B
Maximum Shadow Copy Storage space: 10 GB


That’s more like it!

Now my disk usage is back down to the expected 30GB and all is right with the world.

So, today’s lesson: if your disk space is disappearing for an unknown reason, use vssadmin to check your System Restore settings even if you have System Restore turned off!

I finally found the solution here. Since that appears to be the only page that shows up in google describing this, I will duplicate the solution here:

1) Close Visual Studio
2) Edit the following registry entry: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\[Your TFS server name]
3) Set AutoReconnect = 0
4) Set Offline = 0

When you next open your solution, you will be prompted to reconnect to the TFS server.

UPDATE: 10th January 2012
In Visual Studio 2010, it appears that the registry location has changed to the following:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\Instances\[Your TFS server name]\Collections\[Your TFS server name]

Also, the AutoReconnect property has been removed.

We experienced constant BadImageFormatExceptions when running our Nunit tests via Resharper 4.5 in Visual Studio 2008, on XP64. It turned to be due to the issue described in the following post:

http://www.jetbrains.net/jira/browse/RSRP-71135

As suggested in the post, we turned off the Read-Only permissions for the JetBrains.ReSharper.TaskRunner.exe assembly and then ran the following command in a command prompt:

corflags.exe JetBrains.ReSharper.TaskRunner.exe /32BIT- /force

Problem solved (although you do then get warning messages when launching Visual Studio, which you can ignore).

According to the latest entries on the post, it looks like this might have been fixed in the latest builds.

This was the post that led me to the solution:
http://social.msdn.microsoft.com/Forums/en-CA/tfsversioncontrol/thread/324cf94c-2009-48f4-ae5c-b7ff347d880e