How to get the containing folder for a ProjectItem in a Visual Studio 2005 designer

It was a long search, and I must say that the item in question was very well hidden (congratulations to whoever put it there :)). The problem was this: how do you, from inside a Visual Studio designer or add-in, get a reference to the current ProjectItem's containing folder? And I don't mean the folder on the disk, but the Visual Studio project folder that may not be the same.

You'd never find it... It's in ProjectItem.Collection.Parent! Here's some sample code (the idea is to put the code into a component designer: I haven't tried this actual code, but the basic idea is the same as what worked for me):

public ProjectItem FindActiveDocumentsSibling(string fileName)
{
// we need the DTE to get the active document
DTE dte = (DTE)Component.Site.GetService(typeof(DTE));

Project ret = null;

// try-catch is necessary because Item() throws an exception if no item is found
try
{
   ((ProjectItem)dte.ActiveDocument.ProjectItem
.Collection.Parent).ProjectItems.Item(fileName);
}
catch { }

return ret;
}

So, what's this for? Well, I'm trying to put an NHibernate *.hbm.xml file next to a code class. (Look at a previous post as to why it isn't a child item but a sibling). Now if I could only figure out how to (or whether I should) open it using Visual Studio mechanisms - but without showing it to the user...

How to restore/reset lost Visual Studio 2005 menu items

For some strange reason, installation of various add-ins and add-ons for Visual Studio 2005 causes it to reset its menus - and possibly other settings. But they don't get reset to installation defaults: rather, Visual Studio goes into some kind of minimalistic state where you don't get a "Macros" item in the "Tools" menu anymore, the "Attach To Process" and "Exceptions" commands get lost etc. At first I resorted to going into the Customize dialog and bringing back the items each time (although I never was quite able to figure out how to correctly get back the "Build [project name]" item: occasionally it either appears twice or disappears). I did so much installing/reinstalling of various CTP's that eventually I gave up on customization and started using keyboard shortcuts instead of menus. Now, finally, I found out that there actually is a simple way to reset settings to "normal" instead of "obscure" (seems I hit the right magic word with Google: my searches for "reset Visual Studio 2005 menu" and such led nowhere, but once I asked it how to restore the Macros menu, I struck gold :)). The solution is as follows: go to Tools -> Import and Export Settings and choose Reset all settings.

The original link:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1114019&SiteID=1

Fix for the CAB sample visualiser bug

The Composite UI Application Block has a very useful feature called "visualisers". It's purpose is to give the developer an overview of what is going on inside a CAB application, which, due to a large amount of various mappings and automated dependencies, could othewise become an overwhelming task.

Great idea - but how about an implementation? Well, there is some documentation (very obscure, just like the rest of the CAB docs) and a single sample visualisation. The sample could be useful were it not buggy: it shows you a treeview with WorkItems and SmartParts in your application, but holds a strong reference to them (or something like that) which prevents them from being disposed. So, in effect you don't get a real overview of your application's state. I didn't know about this bug and wouldn't have noticed it were it not kindly pointed out by the CAB people themselves. But it seems it was too much for them to fix it (strange because the sample visualisation consists of a single windows control).

Or they waited for the community to do it - which at the end someone did. This seems to be the philosophy Microsoft is toying with these days. They seem to want to copy IBM's success with supporting open source projects like Eclipse, but are loath to give anything to open source. Microsoft, like always, wants it all - commercial software supported by a free community. Is the lacking documentation for CAB also supposed to be supplemented by community posts on CodePlex? Come on, people, it's been a year since CAB was released and all we have is a package of hands-on labs and a MSHelp file compiled from XML documentation in the source code.

Visual Studio 2005 Service Pack 1, part four: recovery

How to recover from a failed Visual Studio 2005 service pack 1 installation (or how I did it, in any case).

It seems that with a failed setup there is a hung instance of msiexec left running (it can be seen in the task manager) and some files are kept locked in the c:\Config.msi folder and cannot be deleted even when this msiexec is killed. I didn't have the time to fool around restarting the installer service but restarted the whole windows instead. I wouldn't be too surprised if the installation error was actually caused by the installer encountering a locked file.

So, these are the steps I made to recovery:

• Made some more space on the C: partition. In the end it totalled 2.7 GB, but it could be possible to succeed with less. This is not counting the TEMP folder which I moved to another partition (you do this by setting the environment variable in control panel -> system). Note that you can free up a lot of space by going to c:\windows\installer and deleting the previously copied SP1 packages - look for files of 466 MB with recent time of creation.
  
• Went to the c:\WINDOWS\WinSxS folder and deleted files with "8.0.50727.762" in their name, like it was mentioned in this post (scroll way down). Note that the post says I should delete files named like "8.0.50727.163" but I was unable to find any.
• Restarted windows. I believe this is important - at least find and kill the hung msiexec process and restart the windows installer service.

Visual Studio 2005 Service Pack 1, part three: check that!

Waitwaitwaitwait...

BEFORE you start installing the VS 2005 SP1, make absolutely sure you have enough disk space... Otherwise, you will surely regret it: if the installer runs out of space, it will mess up your .Net installation and not only Visual Studio will stop working but an assortment of other applications. I had the same problem on two installations, after the two mentioned successful ones.

The installer dumps a 460+ MB installer package into your c:\windows\installer folder and names it differently every time. So if you cancel an installation (e.g. to uninstall the damn web applications add-in that I always forget to remove) you could end up with multiple copies of the same half-gigabyte package and thusly short of disk space. The installer then reports that insufficient space is available and even if you clean up your disk and click retry it will eventually die with error 2908 and leave your system in a demented state.

So what do you do? Some say you need 4 gigs on your hard disk to make it work. I personally redirected the TEMP environment variable to another disk with lots of space, but that is only part of the solution because only part of the files go into the temporary folder. There is a batch file (see links further down) that turns off some kind of caching (haven't had time to go into details) that could save space and make things somewhat faster.

I'm trying as we speak (well, sort of) to repair a destroyed VS installation so stay tuned for results. In the meantime, some useful links:

How to disable the patch cache and make the installation somewhat faster (so you can retry more times in 24hrs :)):
http://weblogs.asp.net/jgalloway/archive/2006/12/19/things-i-wish-i-d-known-before-i-installed-vs-2005-service-pack-1.aspx

A sum-up on what goes on and how to get yourself out of the mess if you got into it:
http://asztal.net/2006/12/and-the-prize-for-worst-installer-of-2006-goes-to/

How to get a debug log from the installer (hopefully you won't need it):
http://blogs.msdn.com/astebner/archive/2005/03/29/403575.aspx