Visual Studio 2010

Visual Studio: Platform Based References

I’ve been needing to jump back and forth between 32 and 64 bit builds recently. Unfortunately a few of the 3rd party assemblies my project is using are platform specific so I found myself having to manually swap out the references to prevent BadImageFormatExceptions from popping up.  Since Visual Studio doesn’t provide mechanism for this I started exploring external ways to get the right assembly.

On a previous project we where we had this problem we were building with NAnt. With this configuration it was somewhat straightforward to create a dependencies folder that held and organized the different assembly versions and prior to the build, copy the appropriate ones to a folder referenced by the projects. This ensured that we always built the project with the correct assemblies for the target platform.  On this project though, I’m not using NAnt, I’m using MSBuild and I didn’t want to do a custom build task so I looked for another solution.

A 2 year old post from provided the answer I was looking for.  The solution involves a simple project file “hack” where under each property group we define a variable whose value is the path to the appropriate assembly.

Note: The element name you use should be meaningful to your project. I’ve used ThirdPartyAssemblyPath for illustration purposes.

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'">
  <!-- snipped -->
  <ThirdPartyAssemblyPath>(path to 32-bit assembly)</ThirdPartyAssemblyPath>
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
  <!-- snipped -->
  <ThirdPartyAssemblyPath>(path to 64-bit assembly)</ThirdPartyAssemblyPath>

We also need to update the actual reference element to use a hint path based on the variable the variable.

<Reference Include="">

I was able to leverage a single variable for multiple references because I’m using several assemblies from the same vendor. Since they’re pretty well organized in the vendor’s installation folder I only had to define a single variable for the folder and left the .dll names in the reference definitions.

Once you’ve made these edits you can freely switch between target platforms. I’m not sure how sustainable this is in the long term or on larger projects but it’s definitely an option. Just be careful if you ever need to change that reference that you update the variables rather than the reference or you’ll find yourself right back where you started.


Operation could destabilize the runtime

Today I was trying to run the code for a project I’ve just been assigned to.  I’d brought down the code from SVN, built the common libraries, and punched F5.  Build succeeded.  Before long the browser loaded and the beautiful new UI stared back and virtually begged me to start clicking around.  Before I could do anything though Visual Studio rudely interrupted with an unhandled exception dialog.  This one looked nasty, particularly since I’d never seen it before: System.Security.VerificationException – Operation could destabilize the runtime…

I found a Stack Overflow question about this that pointed to Json.NET as a possible culprit.  Sure enough, the source of the exception was Newtonsoft.Json.  It seems that Visual Studio Ultimate’s IntelliTrace didn’t like something Json.NET was doing and would throw that exception.  The issue is said to be resolved as of release 6 but I haven’t upgraded the assembly yet.

For the time being I’ve added a rule to exclude *Newtonsoft.* from the IntelliTrace modules list as recommended by in the Stack Overflow answer.  Since excluding the assembly I haven’t seen the problem again.

Going Underground: Microsoft Moles

3/27/2012 Update: According to the Moles page, the Moles framework has been integrated into Visual Studio 11 as the Fakes framework and Moles is no longer under active development.   After a quick review of the changes it appears that most of this guide still applies but there are a few changes to be aware of:

  • Mole types are now referred to as Shim types
  • The configuration file now has a .fakes extension
  • The generated types are now placed in a .Fakes namespace (i.e.: System.Fakes)

6/25/2012 Update: In preparation for my Faking It talk covering the Fakes framework I compiled a list of the notable differences between Moles and Fakes. There are quite a few more than I listed above so if you’re using this post as an introduction to either framework you’ll probably want to look them over.

Despite having been around for several years I hadn’t heard about Microsoft’s Moles framework until a few months ago when one of my teammates mentioned it during the 2011 Indy GiveCamp. I was interested in learning more about it at the time but given how we were running on caffeine I’m not surprised I forgot about it until he mentioned it again a few weeks ago. This time I was much more alert and started reading about it almost immediately. After seeing what Moles offered and not finding much in the way of resources for it on the Web I knew I needed to spread the word.


VS2010: Box Selections

When I first saw the box selection capabilities in Visual Studio 2010 I thought “that’s kind of neat but I’ll probably never use it” and promptly moved on.  I couldn’t have been more mistaken.  In fact, nearly two years later, box selection has become one of those features that I use almost daily.  What surprises me now though is how many developers I run into that still don’t know about them.

Box selections let us quickly make the same change to multiple lines simultaneously.  Creating them is easy – just hold shift+alt and use the arrow keys or hold the alt key while left drag the mouse to define a rectangle.  If you just want to insert the same text onto multiple lines you can define a zero-length box by expanding the box vertically in either direction.

Non-virtual Properties

So what makes box selections so useful?  Some of the things I find them most useful for are changing modifiers and making local variables implicitly typed.  To illustrate, let’s take a look at a few non-virtual properties that we’d like to make virtual.

Zero-Length Selection

Making these properties virtual without a box selection certainly isn’t difficult but it’s definitely tedious.  A box selection lets us make them all virtual at the same time so we can get on with the task at hand.  The thin blue line immediately following the public modifier on each property identifies the zero-length box that serves as the point where we’ll insert in the virtual modifier.

Virtual PropertiesTo insert the virtual modifier we just need to type (or paste) “virtual.”  Here you can see that each property is now virtual and the zero-length box has moved to the end of the inserted text.  What if we decide later though that these properties shouldn’t be virtual after all?

Box SelectionWe can use box selections to remove the virtual modifier from each property just as easily.  In the example to the left we see a box selection highlighting the virtual modifier on each line.  Non-virtual Properties 2To remove the text we can simply delete it.  This will leave us with a zero-length box where the virtual modifiers used to be.  We can then simply click or arrow away to clear the box selection.

Box selections can go a long way toward increasing your productivity by reducing some of the more tedious aspects of programming.  The few seconds they save here and there can really add up over the course of a day.  More importantly though, that time can be spent on the real problems we’re trying to solve.

Further Reading

How to: Select and Change Text

Changing the AnkhSVN Merge and Compare Tools

When my team reverted back to Subversion the first thing I missed was the Visual Studio integration from TFS.  CollabNet provides AnkhSVN to fill that gap by exposing most common source control operations directly through the IDE.  I’ve been using AnkhSVN successfully for a few months but one thing that always bugged me was the default compare tool.  I love WinMerge and the default merge and compare tool just didn’t, well, compare.  Thankfully the merge and compare tools thank AnkhSVN uses are configurable.

AnkhSVN adds a Subversion User Tools page to the Source Control folder in the Visual Studio options dialog.  From here we can select the tools to use for:

  • External Diff
  • External Merge
  • External Patch

Not only does AnkhSVN provide a list of popular tools including WinMerge and KDiff, it also attempts to determine if any of them are installed and marks any it can’t find with “(Not Found)”.  To change the tool just select it from the list or enter the path to your favorite utility.

Each of the tools are preconfigured to run with a fairly thorough set of arguments but if we want to customize them we can click the corresponding ellipsis button to open the Command Editor.  AnkhSVN uses the macro paradigm to inject a variety of variables into the argument list for the selected editor.  Its macros follow the traditional $(name) format so it should look familiar to anyone familiar with configuring external tools from Visual Studio’s Tools menu.

Ever since I found these settings and replaced the default tool with WinMerge I’ve been much happier.  AnkhSVN is a much more natural extension of my workflow than TortoiseSVN so being able to use WinMerge simplifies the process immensely.

VS2010: Find in Files

I really debated with myself about writing this post but after an exchange with a friend I decided to go ahead with it.  My team recently upgraded to new laptops with a fresh new image.  When one of my friends remarked that he was glad that the new image contained wingrep I asked why he didn’t just use Visual Studio’s Find in Files feature.  His reason?  He didn’t know about some of its features.  After talking about it a bit he said he’d give it another shot.  Now, several days later he’s using it almost exclusively.


VSTS 2010 Load Test Browser Definitions

The list of browsers included in the VSTS 2010 browser list has a decent selection but with the release of IE9 and other browsers it’s already getting out of date. Luckily we can add additional browsers by creating new .browser files in Program Files\Microsoft Visual Studio 10.0\Common7\IDE\Templates\LoadTest\Browsers (Program Files (x86) on 64-bit systems).  The files are simple XML documents that include a name and a few header items such as user agent so there isn’t really anything scary in there.  For example, the definition for IE8 is as follows:

<Browser Name="Internet Explorer 8.0" MaxConnections="6">
    <Header Name="User-Agent" Value="Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1)" />
    <Header Name="Accept" Value="*/*" />
    <Header Name="Accept-Language" Value="{{$IEAcceptLanguage}}" />
    <Header Name="Accept-Encoding" Value="GZIP" />


VS2010 SP1 Now Available

Visual Studio Magazine is reporting that Microsoft has released Visual Studio SP1 and it is now available for download.  Among other things the service pack addresses issues with general stability, the editor, the shell, and IntelliTrace.  It also improves support for 64-bit environments, Silverlight 4, IIS Express and a variety other areas.  A full description of the service pack is available from Microsoft Support.

TFS Power Tools Get a Facelift

Today the Visual Studio Facebook page had an announcement about the availability of an update to the TFS Power Tools.  Although I’ve been back in SVN-land lately this update is still pretty exciting.  Given that my most popular post is Everyday TFS I thought my readers would find it just as interesting.

Per the announcement the March update focuses on three main areas:

  • Addressed reported issues in the Backup/Restore Power Tool
  • Fleshed out the Windows Shell Extension for version control
  • Took the first step on the path to a bunch of new TFS Build Power Tools


Which Files Changed?

One of the complaints I’ve heard about TFS 2010 version control is that getting latest doesn’t show a listing of what was changed. This is untrue. TFS does indeed show such a listing it’s just not as obvious as in other version control systems.

After getting latest, jump over to the output window and select the “Source Control – Team Foundation” option from the “Show output from:” menu. The output window will then display the action taken and file name for each affected file.

It would be nice if TFS would present this information in a sortable/filterable grid format instead of relying on the output window but having the simple listing is typically more than enough. The output window itself is searchable so if you’re looking for changes to a specific file or folder just click in the window and press Ctrl + F to open the find dialog.

Now the next time someone claims that “TFS doesn’t show me which files changed!” you can tell them to check the output window.