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:

• Incorrectly handled Exceptions from Async methods of a Proxy class can kill MsTest
• Throwing exceptions from types that are loaded through Reflection can break Code Coverage
• Using Accessors to call into private code is not supported by Team Build
• 3.5 Test projects and 4.0 Test projects don't mix well
• People keep forgetting to update the .testsettings and Test List files.