If you have been following my posts here and here before you probably know that when I have to I use Moles from Microsoft Research. So the other day a friend of mine mentioned this new cool thing called Fakes, Stubs and Shims in Visual Studio 11 so I decided to look into that.

The first thing I actually did was to ask the following question on Twitter because I was curious to see if Moles and Fakes were similar:

Ok so Fakes in VS 11 are derived from Moles. My next question to Peter was one I’ve been thinking about alot lately:

So Microsoft are looking into adding verify support to Fakes, great!!! this means that you don’t have to use this hack going forward Thanks Peter for that fast feedback!

For all you using Moles this hack will still apply. And for all you SharePoint developers out there; YES this is for you guys because you need to be doing more TDD!

My next step was to create a bootable vhd with Windows 8 Consumer Preview and Visual Studio 11 using my preferred method here and start hacking away.

Step 1

Get up to speed with Fakes, Stubs, Shims by reading “Using shims to isolate calls to non-virtual functions in unit test methods” found here; go on I’ll wait until you’re finished.

You’ll probably end up with a test method looking like the one shown below:

    [TestClass]
    public class Y2KCheckerTests_Step1
    {
        [TestMethod]
        [ExpectedException(typeof(ApplicationException))]
        public void Check_WhenCalledWithTheDate_2000_1_1_ThenApplicationExceptionIsThrowned()
        {
            using(ShimsContext.Create())
            {
                ShimDateTime.NowGet = () => { return new DateTime(2000, 1, 1); };

                Y2KChecker.Check();
            }
        }
    }

Well this is all fine, but what if you have a thousand tests that want to detour DateTime.Now? If you read my previous post here I introduced a Testable object that encapsulates behaviour.

Step 2

So the next step is to encapsulate this into a Testable object that I call Y2KShimDateTime like the code below shows:

[TestClass]
public class Y2KCheckerTests_Step2
{
    [TestMethod]
    [ExpectedException(typeof(ApplicationException))]
    public void Check_WhenCalledWithY2KShimDateTime_ThenApplicationExceptionIsThrowned()
    {
        using (ShimsContext.Create())
        {
            Y2KShimDateTime shim = new Y2KShimDateTime();

            Y2KChecker.Check();
        }
    }
}

public class Y2KShimDateTime
{
    public Y2KShimDateTime()
    {
        ShimDateTime.NowGet = () => { return new DateTime(2000, 1, 1); };
    }
}

Wow now we’re getting somewhere. We can reuse our Y2KShimDateTime in all our test methods. But hey what if we really just want to verify that a specific method has been called? You could just add some counter to the Y2KShimDateTime and call a property like the recommendation here.

Step 3

I use Moq to Mock my code because it’s simple and I love the way I can control return values with setups but mostly I love the way I can verify that a certain method was called with a specific value! If you haven’t looked at Moq yet I strongly encourage you to do so!

To accomplish this with Fakes, Shims or Moles you will need to trick Moq a bit (a hack I know). First of all let’s take a look at my verifiable Y2KShimDateTime class called VY2KShimDateTime.

public class VY2KShimDateTime
{
    public void InitFake()
    {
        ShimDateTime.NowGet = () =>
        {
            return VNowGet();
        };
    }

    public virtual DateTime VNowGet()
    {
        return new DateTime();
    }
}

The first part of the trick is to move the initialization of the detour from the constructor to a public method. This enables us to initialize the detours from Moq as you will see soon. The next thing is to create a public virtual method (VNowGet in this case) that will be called by Moq. There you have it! Easy enough?

Lets see how we use the VY2KShimDateTime from Moq.

using (ShimsContext.Create())
{
    Mock mock = new Mock();
    mock.Object.InitFake();
    mock.Setup(v => v.VNowGet()).Returns(new DateTime(2000, 1, 1));

    Y2KChecker.Check();
}

As you can see from the highlighted row above we’re initializing our detours after we create our mock this way we can be sure our detours will work. And now we can use the usual setup from Moq to Control what our detour will return. Brilliant don’t you say?

Let’s throw a verify into this equation and look how that looks.

using (ShimsContext.Create())
{
    Mock mock = new Mock();
    mock.Object.InitFake();
    mock.Setup(v => v.VNowGet()).Returns(new DateTime(1, 1, 1));

    Y2KChecker.Check();

    //Uncomment line below to see verify that mock.Verify throws correct message
    //Y2KChecker.Check();

    mock.Verify(v => v.VNowGet(), Times.Once());
}

In this case we’ll have to supply a date other than Y2K because otherwise we’ll get an exception but as you can see in the verify method we verify that DateTime.Now is called only once. If I would to uncomment the second Y2KChecker.Clean(); call the verify on our mock would throw an exception.

Summary

I’ve showed how to create verifiable Fakes, Stubs and Shims (works for Moles as well) using a small hack. I use this approach daily when I work with Moles because I really like the combination of Moq verify and setup and Fakes/Moles isolation and detouring.

Hopefully Microsoft will incorporate this in a near future in Fakes but until then give this a try.

All code can be downloaded from GitHub here.

Cheers,

Hugo

I’ve just recently started my first Open Source project (there I said it now I definitely have to deliver it). I can go so far to say that it has something to do with TFS 2010 and a Visual Studio package. I got you curious now right! Anyway there are some challenges to be solved when integrating your own code with existing APIs like the TFS Client API, it’s hard to unit test right? Well some would argue that you shouldn’t care to test your interaction with other APIs but for me that’s not an option. So I’ve chosen 2 basic strategies:

1. Wrap the TFS Client API with my own classes and Interfaces.
2. Test my own classes with the help from Moles. Moles is a Mocking framework from Microsoft Research.

I’ve written about my experiences with Moles here and you should really read that post if you’ve never used Moles before and want to continue reading this post.

A simple wrapper class

Lets start off with a very simple wrapper class that enables you to connect to a TFS 2010 instance.

using System;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Framework.Common;

namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles
{
    public class TfsConnectionWrapper
    {
        private TfsTeamProjectCollection tfsTpc;
        public TfsConnectionWrapper()
        {
        }
        public void Connect(string url)
        {
            tfsTpc = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(url));
            tfsTpc.Connect(ConnectOptions.None);
            tfsTpc.EnsureAuthenticated();
        }
    }
}

As you can see this wrapper class uses some TFS Client API like the call to TfsTeamProjectCollectionFactory.GetTeamProjectCollection for instance. Well if we take a close look at TfsTeamProjectCollectionFactory we’ll find the following declaration:

using System;
namespace Microsoft.TeamFoundation.Client
{
    public static class TfsTeamProjectCollectionFactory
    { }
}

As you can clearly see TfsTeamProjectCollectionFactory is a static class with now chance of sub classing or extending to enables some sort of mocking. So this is really where a mocking framework like Moles comes to play.

Before we start looking at any unit test code I must confess that I’ve started to categorize all my unit tests that use Moles with a test category called MolesTest. I started using the

[TestCategory("MolesTest")]

notation at first but then I just created my own TestCategoryAttribute like this:

using System.Collections.Generic;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    public sealed class MolesTestAttribute : TestCategoryBaseAttribute
    {
        public override IList<string> TestCategories
        {
            get { return new[] { "Moles" }; }
        }
    }
}

Doing this enables me to just add MolesTest next to all my TestMethod attributes like so which makes it easy to filter Moles tests if necessary.

[TestMethod, MolesTest]

How I used to do Moles

The following example illustrates how I used to use Moles as part of my unit testing. (by the way looking at this code now makes my body shiver with disgust)

using System;
using System.Net;
using Microsoft.TeamFoundation.Client.Moles;
using Xunit;
namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    [Microsoft.VisualStudio.TestTools.UnitTesting.TestClass]
    public class TfsConnectionWrapperTests
    {
        private const string validUrl = "http://valid";
        [Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod, MolesTest]
        [Microsoft.VisualStudio.TestTools.UnitTesting.HostType("Moles")]
        public void using_an_valid_url_string_should_not_throw_the_old_way_I_used_to_do_moles()
        {
            Assert.DoesNotThrow(() =>
            {
                MTfsTeamProjectCollection mole = new MTfsTeamProjectCollection();
                MTfsConnection.AllInstances.ConnectConnectOptions = (connection, options) => { };
                MTfsConnection.AllInstances.EnsureAuthenticated = (connection) => { };
                MTfsTeamProjectCollectionFactory.GetTeamProjectCollectionUri = (uri) =>
                {
                    if (uri.Equals(new Uri(validUrl))) return mole;
                    throw new WebException();
                };

                TfsConnectionWrapper wrapper = new TfsConnectionWrapper(); wrapper.Connect(validUrl);
            });
        }
    }
}

Let’s go through a couple of things before I completely throw this in the recycle bin for ever:

1. Yes I’m using xUnit.net as my preferred Assert framework, because I think it’s more descriptive then the default in Visual Studio and it makes the transition to xUnit.net in the future simpler. And because of that I need to prefix all my attributes with Microsoft.VisualStudio.TestTools.UnitTesting. So why not use xUnit all the way? Well that’s a whole other future blog post to be written. Let’s stick with fact that the combination xUnit, Moles and TFS Build and getting stuff published back to TFS caused me some serious headache in the past and that deserves a place in an other post.
2. I’m not going to bother right now verifying the input to the Moles delegates except for the MTfsTeamProjectCollectionFactory.GetTeamProjectCollectionUri delegate where I want to make sure that any invalid uri throws.
3. This would be my starting point then I would probably write another test method to make sure that passing invalid url would indeed throw an exception. In creating that second method I would of course refactor all my moles setups into separate methods. The end result would look something like so:

using System;
using System.Net;
using Microsoft.TeamFoundation.Client.Moles;
using Xunit;
namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    [Microsoft.VisualStudio.TestTools.UnitTesting.TestClass]
    public class TfsConnectionWrapperTests
    {
        private const string validUrl = "http://valid";
        [Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod, MolesTest]
        [Microsoft.VisualStudio.TestTools.UnitTesting.HostType("Moles")]
        public void using_an_valid_url_string_should_not_throw_the_old_way_I_used_to_do_moles()
        {
            Assert.DoesNotThrow(() =>
            {
                SetupAllMoles();
                TfsConnectionWrapper wrapper = new TfsConnectionWrapper();
                wrapper.Connect(validUrl);
            });
        }

        [Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod, MolesTest]
        [Microsoft.VisualStudio.TestTools.UnitTesting.HostType("Moles")]
        public void using_an_invalid_url_string_should_throw_the_old_way_I_used_to_do_moles()
        {
            Assert.Throws<WebException>(() =>
            {
                SetupAllMoles();
                TfsConnectionWrapper wrapper = new TfsConnectionWrapper();
                wrapper.Connect("http://invalidurl");
            });
        }

        private static void SetupAllMoles()
        {
            SetupConnectMole();
            SetupEnsureAuthenticatedMole();
            SetupGetTeamProjectCollectionUriMole();
        }

        private static void SetupConnectMole()
        {
            MTfsConnection.AllInstances.ConnectConnectOptions = (connection, options) => { };
        }

        private static void SetupEnsureAuthenticatedMole()
        {
            MTfsConnection.AllInstances.EnsureAuthenticated = (connection) => { };
        }

        private static void SetupGetTeamProjectCollectionUriMole()
        {
            MTfsTeamProjectCollection mole = CreateTeamProjectCollectionMole();
            MTfsTeamProjectCollectionFactory.GetTeamProjectCollectionUri = (uri) =>
            {
                if (uri.Equals(new Uri(validUrl)))
                    return mole;
                throw new WebException();
            };
        }

        private static MTfsTeamProjectCollection CreateTeamProjectCollectionMole()
        {
            return new MTfsTeamProjectCollection();
        }
    }
}

So in the past I would feel reasonably happy with this and then move on with the next test case. But then I would come to a point that other test classes needed the same Moles setup and then I would create a class that all test classes derived from. Phuu…there had to be a better approach and as I never settle and always seek ways to improve my skills and code I’ve now reached an approach that for the moment feels comfortable.

Introducing Testable Moles classes

Nowadays I just create base classes that derive from (if possible) a Moles class. This way I can define my default behavior for my Testable Moles class and reuse it in any other test classes. And by marking the methods in the class used in the Moles delegates as virtual I can create different Testable Mole classes. Clever right? Let’s take a look at my implementation of a base class for a TestableTfsConnectionBase:

using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Client.Moles;
using Microsoft.TeamFoundation.Framework.Common;
namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    internal abstract class TestableTfsConnectionBase : MTfsConnection
    {
        protected TestableTfsConnectionBase()
            : base(new MTfsTeamProjectCollection())
        {
            InitConnectMole();
            InitEnsureAuthenticatedMole();
        }

        private void InitEnsureAuthenticatedMole()
        {
            AllInstances.EnsureAuthenticated = (connection) =>
            {
                SetupEnsureAuthenticatedMole(connection);
            };
        }

        private void InitConnectMole()
        {
            AllInstances.ConnectConnectOptions = (connection, options) =>
            {
                SetupConnectMole(connection, options);
            };
        }

        protected virtual void SetupConnectMole(TfsConnection connection, ConnectOptions options)
        {
        }

        protected virtual void SetupEnsureAuthenticatedMole(TfsConnection connection)
        {
        }
    }
}

After this I would just go ahead and create a “default” test class

namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    internal class TestableTfsConnection : TestableTfsConnectionBase
    {
    }
}

and if I need I can create another class that implements another behavior like the following class that always throws when trying to connect:

using System;
using Microsoft.TeamFoundation.Client;
using Microsoft.TeamFoundation.Framework.Common;
namespace HugoHaggmark.Blog.Moles.HowDoIDoMoles.Tests
{
    internal class TfsConnectionThatThrowsOnConnect : TestableTfsConnectionBase
    {
        protected override void SetupConnectMole(TfsConnection connection, ConnectOptions options)
        {
            throw new DivideByZeroException();
        }
    }
}

I hope you get the picture on how the testable classes works. Now let’s return to our unit test class and see how this would look in practice:

[Microsoft.VisualStudio.TestTools.UnitTesting.TestMethod, MolesTest]
[Microsoft.VisualStudio.TestTools.UnitTesting.HostType("Moles")]
public void using_a_connection_that_always_throws_should_throw_the_new_way_I_use_moles()
{
    Assert.Throws<DivideByZeroException>(() =>
    {
        MolesFactory.SetupMole<TfsConnectionThatThrowsOnConnect>();
        MolesFactory.SetupMole<TestableTfsTeamProjectCollection>();
        MolesFactory.SetupMole<TfsTeamProjectCollectionFactoryThatNeverThrows>();
        TfsConnectionWrapper wrapper = new TfsConnectionWrapper();
        wrapper.Connect("http://invalidurl");
    });

As you can see any new test method would just simply initialize any testable mole class needed and then of you go. I made a small class called MolesFactory that simply creates an instance of the supplied type in the SetupMole just because I believe it makes my code more descriptive and readable. The complete solution with code and binaries can be downloaded from here.

This is the first time I reveal my inner thoughts and code approaches so I really hope you got a clear understanding and some inspiration. Really looking forward to get feedback from the Moles community regarding the approaches described in this post.

Until next time,

Hugo

The other day I had one of the teams at my current customer report a strange build error in TFS build. They could tell that it had something to do with Moles but they couldn’t solve it.

The solution they were trying to build was pretty simple and consisted of on Class Library project and two Test projects, one for unit testing and the second for integration testing. It looked something like the picture below:

Challenge

I noticed right away that both test projects had moles references to the library which doesn’t have to be a bad thing. But then I also noticed that one of the test projects had a reference to the other test project as well. Could this result in a conflict resolving the correct Moles assembly?

Well if you DO NOT change the assembly version of the library project then you WILL NOT have a problem. But if you’re like us and like to sync your AssemblyVersion and AssemblyFileVersion with the build in TFS then you will run into this trouble. You’ll probably get an error message like:

The type or namespace name ‘Moles’ does not exist in the namespace (are you missing an assembly reference?)

Mind you that this error message is a common compile error in Moles but does also appear in this case. I’ve attached a small solution that mimics this behavior here. (you will need VS2010 and Moles installed to build the zipped solution)

Solution

You get this error because when you add a Moles reference in your test project it adds a reference to a specific version of the Moled assembly (this is of course the default behavior you want in most cases) but when two assemblies have the same Mole reference and they reference each other we get a copy conflict.

To solve this I’ve come up with these solutions:

1. First of all you should probably break the project reference between the two test projects and then your problems will automatically go away.
2. When you add a Moles Reference from within Visual Studio you’ll get a reference to a specific version like so:
   <Reference Include=“Type.Moles, Version=1.0.0.0, Culture=neutral
   , processorArchitecture=MSIL“ />
   If you change the property Specific Version on the Moles reference to False then that will solve this issue as well.
   

I wish that the command “Upgrade .Moles files..” on the solution level would automatically update the project references with the new versions of the Mole References. But I believe I have to file that request to Microsoft.

Enjoy,

Hugo

I’ll be leaving my current client soon after been there for more then a year. As a final test the person at the customer that shadowed me during all this time had to install a complete TFS environment including build server without my help.

And he did it, which I personally take as the best compliment as a coach and consultant leaving the assignment. Anyway my job in this final test was to verify that everything was working as expected.

Challenge

When I reached the verification part in my tests where I finally tried to connect to SSRS from my client machine I got an Login Dialog every time except when I used the IP-address of the SSRS machine.

As a seasoned installer of TFS and SSRS I thought I had seen all the silly errors you can get configuring SSRS so instantly I got the feeling that something was rotten outside the SSRS box. And there was some issues with the DNS that were outside the control of the SSRS box. After almost 1½ days (I kid you not) I stumbled upon the solution…

Solution

Someone had added a <RSWindowsNegotiate/> tag to the authentication types section in the rsreportserver.config file (located in your SSRS installation path). As we’re not using kerberos in this installation a quick delete of the <RSWindowsNegotiate/> tag fixed our issue. This is how our authentication types section looked like after the change.

<AuthenticationTypes>
  <RSWindowsNTLM/>
</AuthenticationTypes>

Now this configuration was probably done by the IT-ops that delivered the machine in the first place but investigation will continue to exclude my fellow shadower from blame.

Cheers,

Hugo

At my current customer we’ve upgraded all our builds from TFS 2008 MSBuild tasks to TFS 2010 WorkFlow Activities. I must say that we’ve gone from several common target-files and per-build specific rsp-files to ONE build process template! That says enough about the power of the new build process in TFS 2010.

Following Microsoft’s recommendation here we’re using one Build Controller for our Default Collection and we’ve centralized our custom activities to one Team Project; lets call it Central.

In the Team Project Central the custom activities we’re using a stored at $/Central/BuildComponents and our Build Controller points out this location as the picture shows below:

In our Custom Activities we have some simple serializble objects that we use as part of our process to store some settings that we need in our build process. An of that would be an XCopyFileWrapper that we use to store 3 string properties:

We then use this wrapper in our Meta Data property in our DefaultTemplate.xaml file like the picture shown below:

Then we added the ParamWrapper as an array of XCopyFileWrapper and add it as an argument to DefaultTemplate.xaml like so:

This way we can have the same DefaultTemplate XCopy files depending on the input we add for each unique build definition in this rather nice centralized GUI for your build definitions:

And then in our DefaultTemplate.xaml we have an foreach loop that loops over our array of XCopyFileWrappers and invokes XCopy! This makes our build definitions really sweet, dynamic and expandable right!

The challenge

So the next Team Project comes along we can call it Project B and they want to use our Build Process. So they branch our build process template into their project and they create a new build definition and then KAPOW!

What happen here! Well my initial thoughts was another lesson I learned previously and blogged about here but specifying the assembly in the DefaultTepmplate.xaml didn’t solve this issue.

The solution

The very simple solution to this problem is that you need to give users READ permissions to your BuildComponents folder in our case the $/Central/BuildComponents folder (another way is to solve this is to give other users READ permissions to the Central Team Project).

That’s it!

Reflection

• So if I want to centralize my custom build components then I have to give all users that will use these custom build components READ permission to the folder where the components are stored.
• Or you could have some sort of deployment mechanism that deploys the build components to every Team Project in the Team Project Collection but then you’ll have to have one Build Controller per Team Project.

Cheers,

Hugo

Have you downloaded and created your own Windows 8 image yet? If not you should really do that, trust me you will love it especially if have a touch enabled laptop. You can easily do this in about 30-60 minutes if you follow my post here.

So last week was the big launch week during the Build event and Brian Harry announced a lot of great previews such as the Azure hosted TFS 11. You can read more about it in Brian’s post here.

As I’m a frequent reader of Brian’s blog I received the post immediately in my RSS reader and luckily for me I was quick enough create my own hosted instance of TFS 11 in Azure using Brian’s activation code.

The irony here is that I created my first hosted TFS 11 in Azure from my Android smartphone, talk about cloud power!

Metro style makes an entrance

The very first thing that stroke me was the sense of familiarity in the GUI and then of course it struck me, TFS 11 is Metro styled!

The Team Project overview with a nice Metro look and feel:

A work item overview with a nice Metro look and feel:

The Team concept makes an entrance

There is this long sought concept of a team in TFS 11 that I just started to play around with and it basically means that you can distribute work per team as the team have their “own” schedule, work items, backlog and homepage (landing page). You’ve Always been able to do this your self by manipulating Areas and Iterations but now it’s a first class citizen.

Create a team dialog:

Assignment of areas to a specific team:

Assignment of iterations to a specific team:

Iterations with dates enters

As you can see above my first iteration (Sprint1) has a Start Date and an End Date which is also a really nice feature that I’ve been missing for ever. Thank you Microsoft for providing this in the box!

Then I found this Current Sprint folder in the Shared Queries section of Work Items and my guess is that there will be a job that automatically adjusts the Work Item Queries according to your dates. I haven’t been able to prove this yet, but I will update this section with my findings.

Showing Work Items section in the new Team Explorer:

Search Work Items in Visual Studio makes an entrance

If you read my last post about finding stuff in TFS here you can see that I wanted a nice search for Work Items functionality directly in the IDE and now I have it. Great job! The nice thing about it is if you enter a Work Item ID that you know about Visual Studio will open it for you.

Entering a Work Item ID in the search field will get you that Work Item:

Another great feature is that you can turn your searches directly to a Query with the Open as Query option as shown below.

Open as Query enables you to store your searches as queries:

This is how far my explorations have taken me so far and will create more posts as I go along discovering more features.

Cheers,

Hugo

This post provides the fastest way to get your Windows 8 Developer Preview booting off a VHD. If you’re interested in more details read my previous posts here, here and here.

1. First of all download Windows 8 Developer Preview here.
2. Download my script here.
3. Select Properties on the zip-package and click on the Unblock button.
4. Extract the zip-package to a folder of your choice.
5. Mount Windows 8 Developer Preview with your favorite mounting tool, my favorite tool is Virtual Clone Drive you can find it here.
6. Look for the file “install.wim” in your installation media and remember the path, in my case F:\sources\install.wim.
7. Open a PowerShell command prompt with the run as Administrator option. You need to run the attached bat-file from a PowerShell console as an Administrator and not from the usual command prompt.
8. Change directory to the directory where you extracted the zip-package.
9. Before I show you how to use the CreateBootableVHD.bat file there is 2 important concepts that you need to know:
   • The third parameter in CreateBootableVHD.bat expects you to enter the type of VHD that you want to create. If you choose EXPANDABLE you will need to make sure that you have the specified amount of GB left for the VHD even though the VHD will be small at first.
   • CreateBootableVHD.bat will assign your bootable VHD a drive letter, it’s very important to use a FREE drive letter.
   • When you enter a drive letter make sure you don’t enter a colon after the letter i.e. X and never X:.
10. Now you’re ready to use the CreateBootableVHD.bat-file like this:
    CreateBootableVHD_v2.bat
    <path where you like to store the VHD, doesn’t work on external drives>
    <size in MB>
    <type FIXED|EXPANDABLE>
    <drive letter assigned to the VHD>
    <path to the wim-file, see number 6 above>
    
    Ex: .\CreateBootableVHD_v2.bat C:\VHD\Win8.vhd 80000 FIXED X F:\sources\install.wim.

Sit back and enjoy as the complete automated process of getting your copy of Windows 8 Developer Preview bootable.

Hope you enjoy it!

Hugo

When you’re building BizTalk applications with TFS Build and then doing some deployment you pretty much end up with the situation where you DO NOT want to create BizTalk applications manually or automatically from some text-file. There is actually a place where this information is stored and it’s called a Bindings File.

A Binding File contains information specific for a BizTalk application and it’s in XML. If you really are into details I encourage you to read this article on MSDN. In short you should use Binding Files and only Binding Files as a part of your automatic deployment process. Thanks to Johan Hedberg and Mikael Håkansson for pointing this out.

Hey this has nothing to do with Moles! Be patient and start by installing Moles here are the free download links from the Visual Studio Code Gallery:

• x64 version of Moles http://visualstudiogallery.msdn.microsoft.com/22c07bda-ffc9-479a-9766-bfd6ccacabd4/
• x86 version of Moles http://visualstudiogallery.msdn.microsoft.com/b3b41648-1c21-471f-a2b0-f76d8fb932ee/

Moles

Moles is a lightweight framework for test stubs and detours in .NET that is based on delegates. Moles may be used to detour any .NET method, including non-virtual/static methods in sealed types. Moles is freely available on Visual Studio Gallery or bundled with Pex.

That’s what Microsoft Research introduces Moles as so now back to my real life scenario.

Writing extensions to the BindingInfo class with Moles

So there is actually a class in the assembly Microsoft.Biztalk.Deployment.dll that wraps the structure of a Binding File into a .Net class. So my thought was to write some helpful extensions methods that could help me in retrieving the name of the BizTalk application configured in the Binding File.

Are you still with me?

If we take a closer look at the BindingInfo class:

The BindingInfo has a default constructor that takes no parameters and then there is a LoadXml method that takes a string to the path of the Binding File. So now I have several options:

• I could create my own implementation of BindingInfo and create a subclass that I could mock
• I could use any other Mocking framework, like moq
• I could use strictly integration tests (tests that use external resources) to test my extension methods

In this case I decided to use Moles because I like to try out new stuff. (Mind you this is not the most common scenario on when to use Moles but just bare with me)

Have you installed it yet? Good lets move on.

Adding a reference to a Moled assembly

Right click any referenced assembly and choose Add Moles Assembly like so:

Rebuild your test project and you’ll find two new items added to your project.

The first new item is a reference to an assembly that is the Moles representation of (in this case) Microsoft.BizTalk.Deployment.Moles.

And the second new item is a .moles file is a simple XML file telling Moles which Moles representation should be created at build time. This is how my Microsoft.BizTalk.Deployment.moles looks like:

This can have implications on build performance that I will try to write another post about soon.

Now you have everything in place to start writing your tests right? Let’s goooo! First of all you’ll need to decorate all your test methods where you’re going to use Moled objects with the HostType attribute. I use my own code snippet for this (based on the TestMethod code snippet already in Visual Studio).

And then start writing test cases. But how do you find your Moled objects? Well I usually find my Molable object using the complete namespace to the stuff you want to Mole + Moles + M + intellisense. Look at the example below:

If you use complete namespace to the stuff you want to Mole + Moles + S + intellisense then you’ll get the stubbable instances instead like so:

In my scenario I wanted to make sure that when the LoadXml method is called on any BindingInfo object in my tests it doesn’t read stuff from my disk but it just returns or initializes any properties I’m interested in. This is how I would write this:

A quick recap:

• MBidingInfo was found using the complete namespace to the stuff you want to Mole + Moles + M + intellisense method mentioned above.
• AllInstances means that for all instances I want to replace some method with my own delegate.
• LoadXmlString is the method I want to Mole. After a while using Moles you’ll see that methods have there original name followed by the Type of the input parameters if any.
• Then I’ve written my delegate declaration and body that takes in two parameters called instance and path.

To make this even more interesting you can add Asserts in the delegate (I say you can, I’m not sure this is a good practice) like the following picture:

Now I can continue writing my test as if my BindingInfo objects had loaded the xml from file. But how can I verify that some Moled method has been called? Well Moles doesn’t intend to provide you with Mocking framework abilities that you might be used to. Instead you’ll have to do this yourself. Here is a simple example how to test if a method is called.

So this was a real short introduction to Moles that I hope helps you come up to speed quickly. The final point that I would like to make is that you can use this on any .Net object even static or sealed objects like DirectoryInfo for instance (try using the code below without Moles):

Big thanks to my colleague Marcus Hammarberg for challenging me to write this post!

Enjoy,

Hugo

The other day I was coaching a colleague and I got the excellent question about how to find stuff in TFS 2010. So I explained to my colleague about some of the different ways you can find stuff and realized that this would be an excellent and hopefully informative post for me and others.

Scenario 1: you know the Id of the Work Item you’re looking for

If you’ve ever worked with TFS for a while you’ll (hopefully) start to memorize (unconsciously) the unique Id’s for the tasks, bugs, user stories, test cases e.t.c. that you work with. If this is your case then you have 3 very fast ways of accessing these Work Items fast.

Inside Visual Studio

1. Right-click the Work Items node and choose Go to Work Item
2. …enter an Id
   
3. and wooops there it is.
   

Or if mouse clicking isn’t your way of life add a keyboard shortcut that does the same thing as shown below:

Inside the Team Portal and Team Web Access

On your Team Project Portal you should have a textbox that will do the same as the Go to Work Item above inside Visual Studio. It will look something like this:

The exact same textbox is present in Team Web Access and look like this:

Scenario 2: you don’t know the Id of the Work Item you’re looking for

Let’s pretend that you don’t remember your Id’s or perhaps you’re a new team member on an ongoing Team Project, what do you do then?

Well you could go through all of the work items and search for the ones you’re really interested in or you could search for Work Items. This is in my experience a somewhat unknown functionality that I would really love to have inside Visual Studio but if you go your Team Web Access you can actually search for words in title or description fields as shown below:

Scenario 3: you need to filter out an massive amount of Work Items

The best way to find, filter and structure you Work Items is to create good Team Queries, and I will not go into details how you accomplish this but I will give you a great tip.

1. Take an existing Work Item Query and choose Edit Query
2. Change it the way you want it
3. Save it as your own Work Item Query or as a new Team Query (use folders to create even better structure)

Another great tip is to open your Work Item query in Excel and then use the power of Excel to filter stuff.

Scenario 4: use the power of search in SharePoint

The best way to find information in SharePoint items and in documents on your Team Portal is to use the awesome powers of SharePoint Search. Here is a sheet explaining some of the cool features in the box.

Enjoy,

Hugo