Take control over your applications on multiple monitors


Our new project space came equipped with a nice big widescreen monitor on every desk. I had used multiple monitors a few years back while I was still running Windows XP and back then I tried a lot of tools which made multiple desktop management easier. Back then I ended up using ATi HydraVision, as it was free and as it did exactly what I wanted.

My work laptop comes equipped with an nVidia notebook graphics solution, but the default Dell driver hadn't installed nView (nVidia's version of HydraVision). So I started a little hunt and finally found the following options.

XBox 360 Wireless controller on Windows 7/2008r2


A friend recommended me to buy an xbox 360 controller to play Skyrim on the TV, because my TV and PC are quite far from the couch I decided to buy a wireless controller and an usb wireless connector for Windows on ebay. The one I picked looked real (had the right logo in the picture and has a hologram sticker on the bottom), though now that I received it, it looks like the wireless receiver might not be as genuine as the seller told me it would be.

The wireless controller wasn't being recognized, even after installing the latest official version of the driver.

A short search lead me to this post which explains how to tell Windows which driver to load. I deviated a bit from the steps presented here, as I found it easier than trying to find the right driver in the long list of drivers that ship with Windows.

Referencing Public/Private/Reference Assemblies folder from your project


When you're working on Code Analysis Rules, Custom build activities, MSBuild tasks or anything that integrates directly in Team Build or Visual Studio for that matter, you often need to reference assemblies that ship with Visual Studio.

These assemblies are usually stored somewhere in the Visual Studio installation path. Now if you're the only person working on your project, you'll probably not run into any issues here, but if you're using multiple machines, or more than one person is working on the project or you want to leverage the power of Team Build, you'll soon find out that your references become unreliable.

Things that make your unit tests unreliable


Over the past few months I've come across a lot of Unit Tests that triggered all kinds of crazy corner cases inside mstest. The most interesting observation is that the behavior inside Visual Studio is often different (or doesn't occur) than in Team Build when this happens. This post will cover some of the issues we've ran into so far.

This most crazy cases all seem to occur when types are loaded using Reflection (either directly by you, or indirectly by the framework) or when you rely on generated proxy classes (WCF's ChannelFactory for example). As long as the code is loaded directly by the Test Runner no issues occur.

In this post:

Helpful Visual Studio Add-ins


Over the past years I've found myself to rely more and more on a number of very handy, some well known, Visual Studio add-ins. I've split this list into two parts, the free and the paid tools:

Team Foundation Power Tools [link] [free]
These tools are now installed on our developer seats by default. They add Windows Explorer access to TFS and a number of very helpful additions to Team Explorer inside Visual Studio.Even if your team members don't really use the functionality inside Team Foundation Power Tools, have them install it to distribute your check-in policies and custom work item controls. They'll come to like the additional features as time goes by.

Team Foundation Server Source Control Explorer Extension [link] [free]
What the Team Foundation Power Tools bring to Team Explorer and the command line, this add-in brings to the Source Control tab. A number of items which were previously only available through the command-line are made accessible directly from the Source Control tab. Delete files permanently, drag and drop support for copying and moving files, merge/copy/move multiple files. It also disables certain items in the context menu's when they're not available and fixes a few other things in there as well.

Where to go with your development question


Last year I was awarded the Microsoft Community Contributor Award and as such I've been wandering through the Microsoft Support forums for quite some time. Enough to know that it's easy to get lost. So here's a short rundown of all the locations you're likely to get help:

The MSDN forums are the first port of call for anything related to Code, TFS, BizTalk etc. There are a few exceptions though (most notably ASP.NET), and they're usually not very clearly defined. Beta products usually receive their own (temporary) forum which will reside next to the forum for the current product version.

Some of these forums here are monitored directly by Microsoft MSDN staff and if you've set up your forum account correctly (meaning you're using the same account for your MSDN subscription) you'll have a better chance of receiving an answer.

I'm going to the Microsoft ALM Summit in Redmond


Yay! I just confirmed my flight and hotel reservations for the Microsoft ALM Summit in Redmond. I'll be coming a little early (flying in on November 11), so if anyone wants to meet up before the main event, drop me a note :).

FxCopContrib project and DoNotIgnoreResultOfImmutableMethods custom rule


Already a month ago I needed a place to store the code of the FxCop rules I was working on. I ended up at Codeplex, not only because they offer native TFS integration, but also because I hope others will join in on the effort.

As of this moment, the number of rule ideas is growing faster than the number of implemented rules, but some might argue that is a good thing :).

One of the rules I like most (and has dug up a few bugs in my other code already), is a rule which flags calls to methods on immutable types, but subsequently ignores the outcome.

Have your Custom CodeAnalysis rule integrate properly with Visual Studio


After porting the MSOCAF rules to FxCop 10, I noticed that you can't use the "Suppress in Source" option. Only the option "Suppress in Project suppression file" is available. Another problem with the global suppression is that it isn't scoped to a type or method, basically turning off that rule for the whole assembly. We don't want that!

As there is close to no documentation available on CodeAnalysis and FxCop, I looked at the difference between the MSOCAF rules and the standard Code Analysis rules that ship with Visual Studio 2010.

It turns out that to get the 'Suppress in Source' option to work, you must pass a Node to the Problem constructor. Setting the SourceContext manually or setting the filename and position won't allow you to suppress in Source.

Find the ID and GUID of any menu item in Visual Studio

When writing an extension to Visual Studio (or in my case to Team Explorer), you need to know the ID and GUID for context menus, tree's, etc. There is a setting in Visual Studio, which you can activate to get access to a debug window which contains exactly what you'll need. Most of it is explained in this blog post.

But you will need to make a few changes to make it work in later versions of Visual Studio.

For Visual Studio 2008:
Windows Registry Editor Version 5.00
For Visual Studio 2010:
Windows Registry Editor Version 5.00

Storing your TFS passwords for TFS servers in another domain


Working for a lot of different customers from my development laptop I've always wanted that little "Store my password" checkbox on the TFS login box, but somehow it's never there when you need it the most.

Turns out you can use the Windows Credentials Store to save your password. Today I found this little gem on the Codeplex docs while adding the re-targetted MSOCAF rules to Codeplex.

And if you're wondering what kind of account you should add, it is a Windows Account.

Maintainable Regular Expressions


I've seen a lot of regular expressions in my career. Some genius, others monstrous, some very subtle and some really blunt. The person who wrote the expression usually did his best to make the expression work and finally succeeded in making his expression pass all the test cases he thought up.

The end-result is usually a one liner that has too many ()'s, {}'s and []'s to be human readable ever again. And that is, lets face it, a huge problem. Because no matter how well it was tested, a time will come a bug is found or that the requirements change. 

Then what?!

Usually the expression is thrown away and written from scratch. Or, the expression is carefully dissected, placed over multiple lines, indented and prettied up, all to see what it was supposed to do.

I've also come across documentation where this nicely prettied up version is placed in a word document and each and every line is documented.

It would be so nice if you could just put that documentation right in the code. Wouldn't it?!

MSOCAF rules


As you might have read previously, I've been trying to incorporate MSOCAF directly in both Visual Studio 2010 and Team Build. The simplest solution would be to code up an msbuild task and put those in a target and reference that target in all project files. I know this, but it has a few shortcomings... (mostly that it doesn't play nice with the Supress option in Visual Studio).

So I've been decompiling re-targetting, recompiling the rules a number of times now, and I've become quite good not only in fixing the issues that come from converting FxCop < 10.0 rules to the latest version, but it's becoming easier to read the rules and actually understand what's going on.

Last week a developer came to me and gave me the bad news that MSOCAF had upgraded and that new rules had been added which aren't yet part of our converted ruleset. So I upgraded my local version of MSOCAF and did my usual 7 step program.

Run MSOCAF in Visual Studio and on the build server


UPDATE (1st of November 2011):
I've since uploaded the re-targetted MSOCAF rules to CodePlex and I've applied a few fixes to prevent CodeAnalysis from crashing under certain conditions. They're not part of any official release, but if you just download the solution and build it, you should be on your way. To build these rules you need to have the following items installed: Visual Studio 2010 with Code Analysis, ILMerge and the latest stable version of the MsBuild Community Tasks.

When building, there is a compiler directive which either builds the code to integrate deeply into Visual Studio and will allow you to suppress warnings inline. Or you can define the ORIGINAL constant to build the code to work exactly like the wizard would, allowing you to suppress messages in both Visual Studio (global suppressions only) and the MSOCAF wizard.

Anyone who has previously worked with SharePoint Online, has had to go through the MSOCAF verification tools. On my current project, it is also required to run these checks against every SharePoint project before they're actually released to an Integration environment.

MSOCAF is a pretty tool. Meaning it looks nice ;). Under the hood it is just a collection of tools that were available to developers.
And it brings a few additional FxCop rules that have been written to check for a lot of SharePoint code smells.


Most Reading