MSBuild goes famous, MSDN docs don't

It looks like MSBuild 3.5 got a new champion – none other than Scott Hanselman himself! He recently published two posts on how build time may be drastically improved on multi-core machines with new 3.5 multiprocessor support.

While I certainly like that additional visibility for MSBuild coming from the popular online author, for me it also indicates something else (not as positive) – most people become really allergic to MSDN content, to the point where they never read it. In later years, MSDN content tends to be late/incomplete/not helpful, so it ceased to be first resource you look into (for MS technologies, that is). And additionally, the visibility of MSDN content in the search engines results is so lame, the content may just as well be non-existent.

But for MSBuild, the content is there, and it provides very decent handling of various MSBuild topics. For example, speaking of 3.5 specific features:

• Building for multiple processors
  
• Targeting specific .NET frameworks with MSBuild (aka ToolsVersion Project attribute)
  
• Item Definitions (aka ItemDefinitionGroup element)
  
• New Methods for Manipulating Items and Properties (properties and items under Target element, Remove Item attribute)
  
• Registry Look-Ups
  

Overall, MSDN MSBuild content node contains loads and loads of pertinent information. So I thought – what's the heck, I shall try to provide some visibility for the good stuff.

And speaking of content, if you are interested in everything MSBuild there is couple of must-have blogs to follow: MSBuild Team blog and Sayed Hashimi's blog. Oh, and probably Scott Hanselman will chime on as well, so make sure you keep reading his blog!

Sharing files between VS projects

One of the interesting features available in Visual Studio managed projects (VS2005 and VS2008) that I keep forgetting about is the ability to add same file to several projects as "link" rather as physical copy. To add existing file to the project as a link you just need to select "Add->Existing Item" and then use well-hidden "Add As Link" add option in the dialog:



The file added as link then will have special icon in solution explorer. And if the file linked is under source control, it will not be added to repository again; the icon will show the status of original file.

What is this feature good for? Several examples:

1. You have class library project where some class have internal methods, and you want to use those methods (for example, for testing). Then you can create additional project and link the files from the class library into it – and voila! you can use internal logic and do that in separate project
   
2. Share certain file between several projects. You might wonder what file is a good candidate for that kind of sharing; well, how about AssemblyInfo.cs file? That way you can easily make sure that all related assemblies have the same version
   
3. One interesting usage scenario was mentioned on MSDN forums: it is not a secret that when you build managed project it generates lots of junk in the project folder (obj and bin folders come to mind). While you can redirect output, it turns out getting rid of this obj folder is quite involved. But suppose you stored your source files elsewhere and would just link them into the project being built? That way you can make maintain clear separation between source code and build plumbing (which is the main purpose of C#/VB project)
   

I am not advocating the wide usage of the links instead of good ol' files; but that's a neat alternative to be aware of.

Debugging Visual Studio packages (stories from the crypt)

If you ever developed Visual Studio integration package, you should be familiar with load failure problem. The problem manifests itself when properly deployed package cannot be loaded with error message displayed.

I'd like to stress the deployed part of the above; when such problem occurs in the development environment, there are number of typical issues causing this such as invalid registry (missing CodeBase attribute etc.), invalid PLK key or missing dependencies (am assuming here that package with invalid PLK does not get distributed :). To diagnose such issues one can use Package Load Analyzer, distributed as part of Visual Studio SDK.

However, when the issue occurs at some other workstation where properly tested package is deployed, this option is not too useful (you cannot ask every user to install VS SDK, can you?). And believe it or not, these things happen even to the software that is rock solid in local test environment. So here is my take on figuring out why deployed package does not work:

1. Ask the user to export registry branch with package registration information
   
2. Ask the user to run Visual Studio with logging enabled (devenv /log [log file path]) and ship you the log; the log will tell you if you have PLK or similar problems – in a sense it is performing the same function as Package Load Analyzer only without fancy interface
   
3. And finally, do tracing in your code! By "tracing" I mean trace every single dubious statement in package Initialize method (and every exception elsewhere however unlikely it might seem). Though better approach would be to utilize Visual Studio Output pane, sometimes the overhead is too big for unlikely scenarios. But however unlikely, if you put Trace statement in that location it can be crucial in diagnosing the problem. Mind, I advocate tracing over message boxes and other UI elements only for the problems that are deemed unlikely (that is never occur in testing, for example).
   Then if you have copious tracing embedded in your code, you can instruct the user to place diagnostics section as into devenv.exe.config file (located in IDE folder together with devenv.exe) and thus get the snapshot of what is going on in your package
   

This sequence can be pretty helpful in diagnosing problems in packages that otherwise are functioning properly in most environments. If you have alternative approaches, it would be interesting to learn them – leave a comment on the blog!

Look and ye shall find. Or may be not.

Do you think that you could list the ways you employ to minimize the number of bugs in the software? It could have been an interesting exercise (similar to 5 facts about yourself nobody knows etc). Well, Patrick Smacchia of NDepend fame did it for you – here are seven (like in seven deadly sins :) typical ways to minimize number of bugs in the software.

I liked the post very much (and still do) but eventually I started thinking that I do not agree with some of the things said. So there – my take on those seven.

While I have no argument about Contract, Automatic Tests and Empirical Approach as effective ways of fighting bugs, other categories do not seem to me a bit questionable.

Prioritizing bugs fix over new features development is a good tactic when one can truly estimate the stability of the code. But frequent is the situation where the code is considered to be worth making more stable through bug fixing; but the stability of the code never actually increases. As the stability (increase) cannot always be estimated numerically, this technique to me seems to be giving a big name to somewhat arbitrary decisions of deciding what to maintain and what to leave alone.

Code quality that is supposed to be brought about through changes in programming styles such as LINQ is in the very least arguable. The argument VB is better than C++ since it is easier to understand comes to mind. Very good post on new trends that will revolutionize software development can be found here – I rather tend to subscribe to that view.

Finally, positioning Code Review and Static Code Analysis as tools for finding bugs misses the point. If we talk about doing code review (static code analysis can be thought of as automated code review process) in order to identify bad "smell" coming from certain piece of code (which FxCop does well) or coming from certain modules/design decisions (in which NDepend excels) that is a one thing; but to use code review (in any form) to find actual bugs always was pretty ineffective. While Patrick says so in his post, he still puts code review into his list. I wouldn't – I would rather call that code quality assessment using whatever tools are available (old-fashioned peer code review, static code analysis, Line Of Code counting whatever); and such an assessment would result in devoting more time to testing the questionable areas.

And what will be your take on bug fighting techniques – speaking theoretically?

Hear hear - VPC is here!

It is Fools' Day, but that is no joke –VS2008 Team System Trial VPC is released. It is full of goodies (nice touches include Office SP1 and Power Tools pre-installed) and it will expire in December (right, December) 2008. And if that is not enough, it has 38 labs with data inside.

If you do not have VPC and poo-poo it as a waste of bandwidth (well, yes, it is around 5 Gb compressed) I'd advise you think about getting one. VPC is invaluable for doing crazy things in TFS repository and verifying changes before going live. Get one and be wise!