How to edit/delete the TFS build agent in Visual Studio

Since this appeared to be non-obvious (to me), here is how you edit or delete a TFS build agent in Visual Studio:

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

Debugging WIX Custom Actions

The following site has some useful tips on debugging WIX custom actions:

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

Extracting icons from a DLL or EXE using Visual Studio

This is another post to file under “things that took me too long to discover via google”…

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.

Changing the default startup project in Visual Studio

The fact that there does not seem to be a way to change the default startup project in a Visual Studio solution has been bugging me for a while. Fortunately it appears that I have finally stumbled on the/a solution…

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…

Cannot uninstall shared component

Here’s another issue that had me stretching the limits of my google-fu:

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.

Verbose logging during install/uninstall

From my experience it can be quite painful to workout why an application fails to install or uninstall.  This is particularly the case when the custom actions are the point of failure.

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.

The Great Disappearing Disk Mystery

Late yesterday I noticed that the disk space on my 150GB D: partition was being used up rapidly. At the time I assumed that I had just been a bit lax in my housekeeping, however this morning I finally noticed that the disk space was disappearing in GBs every few minutes despite no obvious activity on the PC.

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!

Visual Studio 2008: The solution was offline during its previous session and will remain offline

I hit a problem recently where, after an attempt to connect to my local TFS server failed, I was left in a situation where Visual Studio would refuse to automatically connect to the TFS server, even when it was available. This meant that auto-checkouts would not work. When loading a solution, I would get the message: “The solution was offline during its previous session and will remain offline”.

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.

BadImageFormatException when running Nunit tests in Resharper 4.5

Another item to add to the list of pitfalls when getting up and running with a 64bit OS…

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.

Add/Edit Workspace locking up Visual Studio

Just encountered a problem where Visual Studio 2008 was locking up, in the manner associated with having a modal dialog open, and it turned out to be due to the display being extended onto a second monitor. Go figure.

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