Think First, Code Later

{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.

adam note to self note to self, silverlight, tdd, unit tests, visual studio 2008

{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)!

adam azure, note to self azure, note to self