Snagit + SkyDrive, just what I needed…

Noticed my cool screenshots and captures ? Ok, lame intro, but I’m so pleased with those tools…

I’m using Snagit for my screenshots and editing, then I set it up to save my files in my SkyDrive folder, so my work is backed up on the fly. I feel I have only advantages so I’m sharing this small combo.

As a technical blogger, the features I need

  • A handy screen-capturing interface, capturing pieces of screen with a pixel precision
  • The ability to add graphical objects on top of my shots: notes, squares, circles, arrows, text easily
  • The ability to modify those graphical objects without impacting the base image
  • Cool borders effects (torn, blended, etc.)
  • A lot of editing options for the graphical objects
  • A view of all my recent shots (a kind of explorer list)
  • The ability to name my screenshot with my own policy and save them all in sequence to a specified folder

I’ve been striving for this on the internet, with the first three features in mind. There are not that many offers. I tried the most popular free screen capturing tools, but I was disappointed. I started to look for non-free tools, and Snagit just did it too well.


All the aforementioned features are fulfilled by Snagit. To my eyes, the strengths of Snagit are:

  • “.snag” files: images are saved in a proprietary format that allows quick editing, and support quick modifications without altering the original image, this is so important to me
  • Easy interface with many options
  • I can save my favorite arrows and text formatting parameters in the quick style bar, this is good for my blog identity and helps keeping it homogenous (and productive)
  • I almost never go through a Save file dialog, files are automatically named, placed and saved in the right place

Custom profiles for different screen capturing contexts

To achieve the latter point, I set up a Snagit profile for my blog entries and tied it with a particular key combination (CTRL+SHIFT+S), so that the regular Print Screen key would still trigger Snagit, but not in the context of my “blog” profile, thus, not polluting my blog screen captures folder.


I’m sure I’m not using a quarter of all the features, I just use what I need and I’m very happy like this.

Cloud for easiness

Outputting files directly to a SkyDrive folder provides even more comfort. All my work in progress, my live writer drafts and their snag images are backed up on the fly.


I could use DropBox, but I’m more and more using SkyDrive because of its great value. 7 Gb free for a starter, and I bought an additional 20 Go for 8€ per year (that is the price of a basic lunch for me). DropBox is cool and I’ve loved it for quite some time, I’ve earned up to 8,75 Gb of free space just by convincing people to use it! Upgrading DropBox adds 100Gb for 99$ per year, there is no middle ground, too bad.

SkyDrive has been updated with cool features recently, it has now a proper trash bin, a selective file history (not for all file types, as strange as it sounds Sad smile ), and is able to sync from multiple folders on the same machine.

I was a Live Mesh lover, and SkyDrive is my new hero, cheap, works well, I’ll be fully satisfied with it when it has a file history for all file types, not just office files.

Today, I’m using both, DropBox for my personal files, and SkyDrive for all my professional needs and techie archives. And having my work being backed up in real time saved my life a few times already, since I’ve had bad experiences with my SSD, I’m becoming good at backuping stuff now…

Migrating Coded UI Tests to VS 2012: small issue with project dependencies

I’ve upgraded my Visual Studio 2010 Coded UI tests to Visual Studio 2012, and I faced a small issue. The migration considerations are documented in MSDN here. For me, it did not work out of the box, my tests were not found by the Test Explorer, and as soon as I could fix this, tests would not run either, spawning strange exceptions I never had before. I’ll describe below how I finally fixed my Visual Studio solution. The problem is covered by this blog post by the ALM team, but I’m providing the symptoms, and the resolution process in a detailed way. In case people face similar situations, I’m including the intermediate steps, but the real answer to my problem is in the middle of the post (emphasized with bold red font).

How my solution is structured


A smooth migration

When opening the solution with VS 2012, the projects containing Coded UI tests are “repaired”: some magic is performed in the project files in order to keep the compatibility with VS 2010 SP1. This cross-compatibility between VS 2010 SP1 and VS 2012 is quite cool, both versions can concurrently develop on the same project, unusual but true!

The “migration” log reports the following message:

FrontSiteUiTests.csproj: Visual Studio has made non-functional changes to this project in order to enable the project to open in this version and Visual Studio 2010 SP1 without impacting project behavior.

But where are my Coded UI Tests ?

In VS 2012, there is no more Test View, but a Test Explorer. The Test Explorer has a discovery process which asks you to compile the solution if no tests are found. Despite hammering CTRL+SHIFT+B on my keyboard, no test showed up in the box.


What to do then ? Well, there is a new Visual Studio Output for the Testing tools, you’ll find there discovery errors messages. Head to the Output Window, next to “Show output from:”, select “Tests”. The following error message is displayed multiple times:

Error loading C:\Sources\Platform Tests\Company\CodedUITests\FrontSiteUiTests\bin\Debug\Company.Testing.Ui.FrontSiteUiTests.dll: Could not load file or assembly ‘Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.

Accusing inheritance among Coded UI tests

I first thought the error was coming from the structure of my coded UI tests. I have a base class for all my Coded UI tests, this class is decorated by a CodedUITestAttribute, and moreover, there is an intermediate class in the inheritance tree. This one also has a CodedUITestAttribute on it.

I’ve always thought this was a small trick, but VS 2010 seemed support it, though I’m not sure about future versions… So I tried different combinations of attributes on the base and intermediate classes, varying from no attribute, to TestClass, to CodedUITest. I thought I was in the right direction since tests would now appear in the Test Explorer (restarting VS helped Winking smile ).


The details are no real matter here, but I faced various exception messages while playing with attributes, for reference sake I’ll post them here:

At compile time with no attribute in the base class, so TestClass or CodedUITest is at least required:

UTA005: Illegal use of attributes on Company.Testing.Ui.Core.CdsUITestBase.MyTestInitialize.The TestInitializeAttribute can be defined only inside a class marked with the TestClass attribute.
UTA006: Illegal use of attributes on Company.Testing.Ui.Core.CdsUITestBase.MyTestCleanup. The TestCleanupAttribute can be defined only inside a class marked with the TestClass attribute.

At run time, using TestClass instead of CodedUITest :

Initialization method Cdiscount.Testing.Ui.OrderProcess.Check_Customer.Customer_Login.CustomerLogin.MyTestInitialize threw exception. System.IO.FileNotFoundException: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.VisualStudio.TestTools.UITesting, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified.WRN: Assembly binding logging is turned OFF.

This message (similar to the one reported by the discovery process) pointed out the real problem: VS 2012 should use version references and not

The problem is actually pretty simple, the wizard has upgraded my Coded UI Test project but not the project that contains the base and utility classes. There is no messing around with attributes involved.

So all we need is to reproduce the “magic” on our referenced projects.

Additionally, beware of external dependencies directly built upon version of the testing tools assembly set, you’ll have to rebuild them upon

The problem was also reported and solved here.

Upgrading (or reparing) projects manually

Disclaimer: although I’m exposing here as a commodity the implementation of this “magic” performed by VS 2012 update 1, I advise to watch closely at what is done to your own Coded UI test projects as a base. Simply compare the changes before checkin-in your proj file. That said, the following should work for you.

In the first PropertyGroup with most global properties:

<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<ReferencePath>$(ProgramFiles)\Common Files\microsoft shared\VSTT\$(VisualStudioVersion)\UITestExtensionPackages</ReferencePath>
<UpgradeBackupLocation />

After the last ItemGroup and before the last Import:

  <When Condition="'$(VisualStudioVersion)' == '10.0' And '$(IsCodedUITest)' == 'True'">
      <Reference Include="Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Common, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension.Firefox, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <Reference Include="Microsoft.VisualStudio.TestTools.UITest.Extension.Silverlight, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <Reference Include="Microsoft.VisualStudio.TestTools.UITesting, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<Import Project="$(VSToolsPath)\TeamTest\Microsoft.TestTools.targets" Condition="Exists('$(VSToolsPath)\TeamTest\Microsoft.TestTools.targets')" />

Next, in the <Reference … /> node under <ItemGroup>, delete all Reference to assemblies like Microsoft.VisualStudio.QualityTools.* and Microsoft.VisualStudio.TestTools.*, except for UnitTestFramework, so leave this entry:

<Reference Include="Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />

These evolutions actually make the ReferencePath depend on the version of Visual Studio. Cool.

Now all the references, including those from the utility project are mapped to the correct version, that is v11.0.0.0:


So in the end everything’s fine, tests are properly discovered, and run fine as they just ran with VS 2010.

Finalizing the migration

There have been deep evolutions in the testing tools between VS 2010 and VS 2012, for example vsmdi files, which used to contain test lists, are no longer supported. This is all well documented in MSDN. This may be qualified as a regression in functionality, but personally I absolutely don’t feel angry at all or even surprised, those lists needed to evolve, I’ve never been keen on them and I’m quite happy the way it is today. Now, the test tagging system is the only rightful way to categorize tests and define running lists: just as it has always been with other testing frameworks. Less ambiguity, better tools, more productivity.

You’ll surely want to add multiple categories to single test methods, it is good practice:

[TestMethod, TestCategory("Daily"), TestCategory("Nightly"), Priority(1), Description("Check the customer login")]
public void CodedUITestMethod1()

eg: some database tests may be eligible for your nightly builds.


Just in case

As a final word, just in case you have some mess in your class attributes for your Coded UI Tests, TestClass is not suitable as base class for Coded UI Tests, as you will have the following message at run time:

Result Message:    Initialization method Cdiscount.Testing.Ui.OrderProcess.Check_Customer.Customer_Login.CustomerLogin.MyTestInitialize threw exception. Microsoft.VisualStudio.TestTools.UITest.Extension.TechnologyNotSupportedException: Microsoft.VisualStudio.TestTools.UITest.Extension.TechnologyNotSupportedException: The browser  is currently not supported..