A few mornings ago I went into work, and per my usual routine, opened Outlook, opened IE 7 (we are developing an app that has to run against that sorry excuse for a browser), open Visual Studio, etc.

Once my laptop decided it was done with these seemingly simple tasks, I gave focus to VS, went to the File menu, down to Recent Projects and selected that VS solution which is the current source of my income. As soon as the previously-opened files were displayed, Visual Studio simply shutdown - rather quickly, too. There were no messages, warnings, requests for sending an error report to headquarters, etc. it simply shutdown.

Hmm, okay.

So, I tried it again and the same thing happens. So, I did something I rarely do, and rebooted Windows (XP Pro, of course), hoping that would "fix" the problem. Nope, no dice. Meanwhile, a coworker needed some help with something, so I go to his desk and in the process of that discussion, I mention PowerCommands for Visual Studio 2008 to him and he installs it because he really liked my description of the "Collapse Projects" feature, as we have quite a large number of projects in this solution (more than I think we should have, but whatever) and after a few of them are open, solution explorer becomes a bit unwieldy and useless.

No sooner than he installs PowerCommands and starts Visual Studio back up does it close up exactly as it had been doing for me. How serendipituous! Because I had been running PowerCommands for a week or two with no problems though, I was reluctant to think it was the cause of the problem; yet I couldn't deny what my eyes had just seen.

So, I searched around and after seeing this as being a problem for quite a few people, a lot of whom use XAML for WPF, and their various attempts at fixing the problem (my least favorite being to simply uninstall PowerCommands and cease using it), decided to try the following, which I found on Stack Overflow and has worked for all 3 of the people on my team which have had the problem - here is the solution:

You are going to modify the devenv.exe.config file, which can be found, typically, in this folder location:

32-bit Windows
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

64-bit Windows
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE

Open the file in Notepad or some other suitable text editor, and add the following (assemblyBinding node shown for context):

      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         ...
         <dependentAssembly>
            <assemblyIdentity name="Microsoft.PowerCommands" publicKeyToken="null" culture="neutral"/>
            
            <!-- For 32-bit systems, uncomment this one
            <codeBase version="1.1.0.0" href="href="C:\Program Files\PowerCommands\Microsoft.PowerCommands.dll"/>
            -->
            
            <!-- For 64-bit systems, uncomment and use this one  
            <codeBase version="1.1.0.0" href="C:\Program Files (x86)\PowerCommands\Microsoft.PowerCommands.dll"/>
            -->
            
         </dependentAssembly>
         ...
      </assemblyBinding>

Hopefully this helps someone, it's a sneaky bug.

Just released this today - it yet needs a bit of work; the only major part not completed are the methods that provide metadata for stored procedures (mainly because I don't need this feature at the moment, so it was the lowest on my list of priorities), which I am planning on finishing within the next two weeks.

You can download it at www.sapientdevelopment.com.

The company I work for is hiring -  whether you are a project manager, senior-level Java developer, Microsoft application developer or a web design/usability expert, Software Technology Group has something for you.

I have worked for STG for over 2 years now and can tell you that, without a doubt, working for STG has been one of the highlights of my career.

For the last client I worked for, we extensively modified a MochiKit port of a well-known 'Lightbox' implementation so that it would utilize IFrames - the users of the application loved it because they were used to primitive JavaScript alert and confirm boxes, and since a modal dialog was still the appropriate thing to do, it worked well.

A short time later, I found ThickBox - seems to be a much better implementation of this now-common technique, and I thought it might prove useful to have a MochiKit version of it in case I decide I want to use it (it is built on jQuery, which I don't personally use or care for, notwithstanding the library having a few useful constructs that I would like to see ported over to MochiKit).

In porting this script, I tried not to 'improve' it at all; i.e. I left nearly everything as-is with regards to naming conventions, use of certain constructs that I would like to improve, etc. and leave it up to you, if you choose to download it, to make any changes you see fit. Of course, any bugs you find would be great to know about, as well as ideas for enhancements, etc. and I will probably update this when I get time, because I would like to do things much differently (maybe I am smoking crack, but this whole idea of connecting to things based on the value of the 'class' attribute of a tag just seems stupid to me...).

My port of ThickBox isn't perfect and I did it as quickly as I could because I wanted to get it into the hands of those smarter than I - that means you. There are places in the code that are inconsistent and I will be working on that, but for now it does the job and should be a good starting point for those that find this useful.

Download ThickBox for MochiKit.