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 ryangerard.net 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.
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.
I’ve been doing a bit of Web UI work recently and everything was going fairly smooth until yesterday when I tried opening one of my CSS files in Visual Studio and was promptly greeted with a dialog reading “The operation could not be completed. Unspecified error” and the editor never opened. A little hunting for the error message and “CSS editor” revealed that the Web Standards Update for Microsoft Visual Studio 2010 SP1 was likely to be the culprit and uninstalling should resolve the issue.
I closed Visual Studio, uninstalled the update, and sure enough, when I reopened my project the CSS file opened just fine. I haven’t reinstalled the update yet. Maybe I’ll try again soon but it seems from the comments on the component’s page that this is a common issue.
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 Overflowquestion 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.
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.
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.
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.
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.
To 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?
We 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. To 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.
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:
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.
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.