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.

First Post

Well, it has been a long time in finally making it out the door, but today I realised that I may have something useful to contribute to the world after all. So here goes, first blog post (for me) ever!

This week I have been on a wcf course with DevelopMentor. Today when the instructor Dominick Baier, was deleting for the umpteenth time the "#region" tags (these are inserted when you use the smart tag in Visual studio 2005 to implement an interface) I smiled to myself, because this is one of my pet hates too. Then he said "does anyone know how to switch this off?", and I thought to myself "it can't be that hard". Well it is... and it isn't

Actually, it turns out my way is the really hard boring way. As Steve pointed out in the comments, if you go to tools-->options-->text editor-->c#-->advanced then there is a "Surround generated code with #region" checkbox. This is clearly the easy way! Thanks Steve

If you are looking for how to change the default startup settings for a solution you need to head here.

If you know how to switch it off it is easy, if you don't, it is undocumented and google doesn't quite get the answer.

I found a pointer in one of the comments here. Needless to say the registry key is a red herring for the rtm version of Visual Studio 2005. In fact I couldn't even find the full path in the registry, which got me to thinking "where did they move all this config if it isn't here anymore"? Well one of the nice features of Visual Studio 2005 is that you can export your user settings. One of the things I remembered thinking, when I exported my settings was, "There is a lot more being exported than I see in the UI". Turns out that "ImplementInterface_InsertRegionTags" is exported with a value of 1. if you export your settings, set the value to 0 (zero) and (re)import the settings again, the "#region" tags disappear :)

So the exact steps:

1. Backup your current visual studio settings (follow step 1..9 but select everything in step 6)
2. Visual Studio --> Tools Menu
3. Select Import and Export Settings...
4. Select the "Export selected environment settings" radio button (default)
5. Hit "Next"
6. Make sure you have "All Settings"-->"Options"-->"Text Editor"-->"C# Editor" checked.
7. Hit "Next"
8. Select a file name and location
9. Hit "Finish"
10. Open the file in your pet xml editor
11. Search for "ImplementInterface_InsertRegionTags"
12. change the value to 0 (zero)
13. Save the change
14. Repeat steps 1 and 2
15. Select the "Import selected environment settings" radio button
16. Select "No, just import the new settings, overwrite my current settings"
17. Hit "Next"
18. Select or browse for the file that you made the changes to
19. Hit "Next"
20. Make sure you have "All Settings"-->"Options"-->"Text Editor"-->"C# Editor" checked.
21. Hit "Finish"
22. Restart Visual Studio (optional I think, seemed to work without it)
23. Implement interfaces without regions :)

Note: This passed the "it works on my machine" test, but I make no guarantees.