Archives For note to self

{Every now and then I find that I have to do some kind of configuration magic to get my development environment working the way I want it to. I promptly forget it until I have to do it again 3-6 months later when I replace my machine. By then I have no idea what I did so I have to look it up again. The point of this Note to Self series is to remind me of exactly what I did so I don’t have to try to remember the name of some odd command line tool and the various parameters that go along with it.}

Let me start by saying that I’m a big fan of Team Foundation Server (TFS). I think the product has come a long way since it’s initial release in 2005. I wish it had some more features that could make it a distributed version control system (i.e. Git and Mercurial), but all in all it’s a good product

With that said, one of the things I’m not a fan of is how Visual Studio (VS) attempts to connect to TFS on startup. There are two specific reasons I don’t like this. First, it slows down VS startup. Second, I have multiple clients, not all of whom expose their TFS instances over http/s. If the last instance of TFS I was connected happens to belong to one of these clients, not only do I have to wait for the long startup, I have to endure a dialog telling me that VS could not connect to TFS. This is especially frustrating when all I want to do is create a simple console app to test out an idea or two. It’s so frustrating, that I’m acutally getting frustrated right now as I write this. Grrrr….

Luckily all is not lost and this no longer needs to be endured. With a small registry tweak you can prevent VS from connecting to TFS (2005, 2008, and 2010) on startup. Here’s what you do:

1. Backup your registry. Don’t skip this step. SERIOUSLY! DON’T SKIP IT!

2. Navigate to Team Foundation key:

For VS 2005 navigate to: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation

For VS 2008 navigate to: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation

For VS 2010 navigate to: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation

3. Add a registry key “AutoLoadServer” (type DWORD)

4. Setting the value to be 0 (Do not connect automatically or 1 to connect automatically).

This has made me a happier, well less frustrated, developer. I hope it does the same for you.

{Every now and then I find that I have to do some kind of configuration magic to get my development environment working the way I want it to. I promptly forget it until I have to do it again 3-6 months later when I replace my machine. By then I have no idea what I did so I have to look it up again. The point of this Note to Self series is to remind me of exactly what I did so I don’t have to try to remember the name of some odd command line tool and the various parameters that go along with it.}

If you’ve seen me give a talk you’ve undoubtedly heard me evangelize the new “Boot From VHD” feature available in Windows 7 and Windows Server 2008 R2. In a nutshell, boot from VHD allows you to mount a vhd as a bootable drive and, as the name implies, boot from it. It’s a great scenario for creating multiple OS installations without having to create multiple OS partitions on your hard drive. It also enables you to create run a VHD on the metal, just about, on your machine without having to host in something like Hyper-V.

Recently, as in 2:00 AM this morning, I found myself in a bit of a pickle. I needed to build out a VHD that I could leverage for the new Windows Azure VM Role. The problem I was facing was that my laptop was running Windows 7. You may be asking yourself “Why is this a problem?” Well, VHD’s configured to run in the Windows Azure VM Role must be a Hyper-V image of Windows Server 2008 R2 Enterprise Edition. “Well,” you may think “couldn’t you just use this cool boot from vhd feature to create Windows Server 2008 R2 image with the Hyper-V role installed, boot into it and create your images for Azure?” You can probably guess the answer, one big resounding NO! The simply reason is that you can’t run a virtual machine inside of another virtual machine. If you did here’s a description of what would happen:

It would be bad… Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.

-Egon Spengler, Ghostbuster

OK, so maybe it wouldn’t be that bad, but you get the idea.

Let’s get back on track. To solve this problem, I had to do a fresh pave (on a different hard drive) with Windows Server 2008 R2 as the host OS. This was pretty easy and quick to do. However, I wanted to be able to use my existing development bootable vhd, so I copied it over to the new drive as well. Finally, I needed to make the dev vhd bootable on the new hard drive. To do this, I knew I had to use the Boot Configure Data Editor (BCDEdit for short), but I could remember the exact set of commands to use. After all, it’s not one of those things you do on a regular basis, well, at least I don’t. With a little tinkering around I finally got it ironed out. Here are the steps I took:

  1. Run bcdedit /copy {current} /d “Display Name”
  2. Copy the CSLID displayed
  3. Run bcdedit /set {CLSID} device vhd=[C:]\vhdname.vhd
  4. Run bcdedit /set {CLSID} osdevice vhd=[C:]\vhdname.vhd
  5. Run bcdedit /set {CLSID} detecthal on

I then rebooted and BAM, I was able to boot from the vhd I had been using on my old hard drive with everything working as before. Pure awesomeness.

{Every now and then I find that I have to do some kind of configuration magic to get my development environment working the way I want it to. I promptly forget it until I have to do it again 3-6 months later when I replace my machine. By then I have no idea what I did so I have to look it up again. The point of this Note to Self series is to remind me of exactly what I did so I don’t have to try to remember the name of some odd command line tool and the various parameters that go along with it.}

So, I’m a big fan of Test Drive Development (a.k.a. TDD). One of the big statistics I like to get out of TDD is code coverage, that is, what percentage of code is being covered by my unit tests. I’m well aware that 100% code coverage doesn’t mean your application is completely and thoroughly tested, but it gives you an idea of how much of your code is covered and where you need to write some more testes (in case you didn’t write them prior to writing your code – but you wouldn’t do that now would you?)

Anyway, I’m currently working on a project with a large suite of unit tests and I wanted to get the code coverage metrics for the project. Naturally, I fire up the solution in Visual Studio 2008, go to the Test menu, click Edit Test Run Configurations, and click Local Test Run. I then click Code Coverage to turn on code coverage for a given assembly and *POOF* the Local Test Run Configraution window just disappears. This has happened to me several times in the past after re-paving machines and then trying to turn on code coverage in a solution that contains a Silverlight project. To remedy the problem, download and install this hotfix and you should be good to go.

Hope this helps.

Note to Self – DSInit.exe

November 18, 2009

{Every now and then I find that I have to do some kind of configuration magic to get my development environment working the way I want it to. I promptly forget it until I have to do it again 3-6 months later when I replace my machine. By then I have no idea what I did so I have to look it up again. The point of this “Note to Self” series is to remind me of exactly what I did so I don’t have to try to remember the name of some odd command line tool and the various parameters that go along with it.}

I don’t know how you have your development environment set up, but one of the things I don’t have installed is SQLExpress. I have SQL Server 2008 Developer Edition (I need some of the tools not included with the express version). I also don’t use a default instance, I use a named instance, just ‘cuz I’m picky. This is all well and fine, but it requires you to jump through an additional step if you want to use development storage when developing Azure applications on your local machine.

Enter DSInit.exe.

DSInit.exe is a command line utility that allows you to initialize the development storage environment on your location machine. By default, the storage wants to use an instance of SQLExpress on your machine named SQLExpress. DSInit allows you to work around this. The tool initializes the development store for usage by reserving http ports for the blog, table and queue services for the current user, and creating the database needed by the blob and queue services. Here’s the lowdown on how to use it:

Syntax
DSInit [/sqlinstance:<SQL server instance>][/forceCreate][/user:<Windows account>]

Options
sqlinstance: the name of the SQL Server instance on the local machine that should be used for development storage. Use “.” for unnamed instance

forceCreate: recreate the database event if it already exists.

user: user for whom ports art to be reserver. By default it is the current user.

DSInit.exe can be found in [install directory]:\Program Files\Windows Azure SDK\v1.0\bin\devstore

Hope this helps you (and me)!