Moved home

I have moved this blog to a domain name under my control.  You can find my new blog at http://acceptnobrokenwindows.com

Podcasts

I have recently developed the habit of listening to podcasts while I am not working as a way to try and get a little more learning time packed into a busy schedule (anyone else wishing for 36 hour days?). I have enjoyed quite a few and thought I'd share them.

I have enjoyed listening to Joel and Jeff talking about, well anything that comes up while they set up a community based site for finding answers to programming questions, at:
http://blog.stackoverflow.com/index.php?feed=podcast
It's not overly technical, but it is interesting to listen to two people with very different approaches to development talk about a variety of subjects.

Craig Andera and Tim Ewald have been podcasting occasionally and have some interesting insight on RESTful services and also interviewed Jon Lam about Iron Ruby. It doesn't have a feed that I can find or a tag so I have linked to the latest and there are links there to the previous podcasts:
http://www.pluralsight.com/blogs/craig/archive/2008/02/26/50317.aspx

and Software Engineering Radio has many really good podcasts and interviews on a really broad range of subjects. Because it focuses more on software engineering, they also talk about a wide range of technologies:
http://www.se-radio.net/

If you have any other suggestions please feel free to post them.

MSBuild features for vNext

I love MSBuild, Nant and CruiseControl.Net for the complete process that they bring to building a solution. It is not often you get to contribute to the features that you would like to see next in one of these products. The MSBuild team have got a blog post asking for a survey on which features you would like them to work on for vNext.

Go here and spend your 100$(virtual) and make a difference.

If you still need convincing that an automated build is important, Jeff Atwood has a good post on why F5 is not your build process. His reference to Hacknot's if they come how will they build is too scarily close to the reality in far, far too many companies.

I try to do something to improve the build process everywhere I work. I believe we all should.

Turning a c# project into a test project

Ever added a C# project by accident when you meant to add a Test project? And only realized after writing a test, adding all the references and not finding it in test manager?

I have; and I can never remember exactly how to fix it. I'll post the steps here so I can find it in the future, and maybe help other people with the same issue.

Test projects are aggregate projects (language and type) and these properties are set under an element in the project file called projecttypeguids.

A test project looks a little like this:

<propertygroup><configuration condition=" '$(Configuration)'== '' ">Debug</configuration>
  ...
  <projecttypeguids>{guid};{guid}</projecttypeguids>
</propertygroup>

So:

1. Right click on the project in question and choose "unload project".
2. Right click on the project again (it should now be grey and look something like [project name](unavailable) and select Edit [project name].
1. for c# add:
   <projecttypeguids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</projecttypeguids>
2. for vb add:
   <projecttypeguids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</projecttypeguids>
3. Right click once again and choose "Reload project"

Hope this helps someone out there.

Background compilation needs an on/off switch

Jeff Atwood has written a couple of entries recently about the C# Compilation tax and an article comparing Background Compilation and Background Spell Checking

I find the background compilation in vb.net, as it is currently implemented, does not work well for me. I often write the main structure of my code(which doesn't compile) and then fill in the gaps. And vb.net tells me it's wrong; except it isn't wrong, I just haven't finished. Ian finds this annoying as well and calls it Background Irritation.

Although it is, in someways, comparable to background spell checking, I find it is as irritating as MS Word's AutoCorrect. AutoCorrect decides that what I just typed is not what I meant to type and changes it. This works fine for "teh" and other such errors, but often AutoCorrect changes TLAs and other words until the meaning of what I have just written changes completely. Worse, it does it without telling me, which is very frustrating. But, I can switch it off when I know that I am writing something that it will cause me hassle with. In fact, now I think about it, I even use spell checking like I use the compiler. I write my text, I scan it to make sure that I think it's ok and then I ask the spell checker to double-check for me.

So what is wrong with background compilation? I want it on when I am bugfixing. I want it off when I am writing from scratch. I want it to work like that in c#. I don't care if it is on by default. But if it doesn't have a switch I don't want it. Therefore, for a tool to be useful to a good developer, it needs to be written as something that can be reached for when needed.

And on the subject of the c# compilation tax, VB.Net's bacground compilation is not free. The MSDN article Scaling Up: The Very Busy Background Compiler has some hints to help with large projects. But the idea of changing my code or switching off other features to help the performance of another feaure that I don't always want on, just seems to reinforce my perception that this needs a switch.

Changing the default startup project preference

By default, visual studio sets the first project that you add to a solution as the startup project when you hit the Debug-->Start (F5) or Debug-->Start without debugging options (ctrl-F5). This can be particularly annoying, especially when developing client server applications. You may want to start the server first, then when it is listening, start the client. You may want to start multiple projects at the same time. Now these options are available by right clicking on the solution and selecting Properties, Common Properties-->Startup Project.

By default single startup project is selected and the project currently in the drop down is what visual studio will try and start. I have recently acquired a taste for current selection (when you have are writing unit tests it is particularly handy for quickly running the current test project).

You can change the default for this by navigating to tools-->options-->Environment-->Projects and Solutions-->Build and Run. And there tick the check box "For new solutions use the currently selected project as the start up project". If you have a large solution it may also be worth checking the "Only build startup projects and dependencies on run" in order to avoid building everything to run some low level test.

Incidently, changing the default startup options doesn't just effect new solutions as the name suggests, it will effect any solution that doesn't have an options file (solutionname.suo). This means that in a team environment, as long as everyone has their own solution option files, changing this option will not effect other users.

Xml attribute formatting

If you spend a lot of time formatting your xml documents with each attribute lined up on a seperate line, you will be pleased to know that there is an option in VS 2005 which allows you to do this automagically.

Tools-->Options-->Text Editor-->Xml-->Formatting

switch the radio button to "Align attributes each on a seperate line".

then ctrl-k, ctrl-d your way to easy to read xml files.

Most useful when something updates your xml for you, like updating a WCF service reference.