Rich on Software

Using Windows Azure Web Sites – Hosting a blog with BlogEngine.NET

Wed, 20 Jun 2012 01:34:00 -0400

** Update: BlogEngine.NET is now included as part of Windows Azure’s Website App Gallery **

Currently the Gallery only includes version 2.5.0.6 of BlogEngine.NET, which is a couple of versions behind now. If you want to install the latest version then the steps below should still be applicable.

Windows Azure Web Sites is one of the new features in Windows Azure announced by Scott Guthrie on his blog post Meet the New Windows Azure. Azure Web Sites are akin to the shared hosting model, where many sites are hosted under one installation of IIS inside of a single VM. Azure puts a bit of a spin on this concept by allowing scale out of the Web Site to multiple VMs and the ability to reserve entire VMs just for its usage.

WindowsAzure.com describes Azure Web Sites as follows:

Build highly scalable web sites on Windows Azure

Quickly and easily deploy sites to a highly scalable cloud environment that allows you to start small and scale as traffic grows.

Use the languages and open source apps of your choice then deploy with FTP, Git and TFS. Easily integrate Windows Azure services like SQL Database, Caching, CDN and Storage.

This functionality is currently free for up to 10 websites during the technical preview. However, I can’t imagine it being all that expensive once it comes out of preview.

The biggest feature that really stands out IMO is the ability to just use Web Deploy in Visual Studio for deployments. Aside from the new publish profile it’s not necessary to change anything else about the project/solution. All of this drastically reduces the barrier to entry for anyone wanting to get started with Windows Azure.

With that said, we’re going to go through the process of deploying BlogEngine.NET to Windows Azure using the new Web Sites features and see that things are demonstrably easier than what was required in the past. Additionally, this should give us a quick run through of the new management portal for Azure (more on this below).

Here’s an overview of what we’ll need:

Windows Azure Account (you can sign up for a 90 day free trial)
Visual Studio 2010 SP1 or higher (SP1 is required for the Azure SDK)
BlogEngine.NET WAP Project source (detailed below)
Windows Azure SDK 1.7 or higher, if using VS 2010 SP1 (links provided below)

Azure Setup

If you don’t already have an Azure account, you’ll need to sign up for one before you can continue. Again they have a 90 day free trial, so there’s no hassle. Once you have your account set up, we’ll need to enable the Web Sites preview, which also enables the preview of the new management portal. This happens to be relatively painless.

After electing to use the preview portal you’ll get a quick guided tour detailing its new features. With the new portal and the Web Sites option enabled, we can finally create an Azure Web Site.

There are several other blog engines in the gallery, unfortunately BlogEngine.NET isn’t one of them. Select Quick Create since we’re going to do a basic/default installation of BlogEngine.NET. If we were backing our BlogEngine.NET install with a Sql Server we’d select Create with Database instead of Quick Create. Note the URL field can be entered as whatever you want it to be.

Once finished we should now have a running web site, just with nothing deployed to it yet

Next up we need to go to the management screen and pull down the publish profile. This tells Visual Studio how to publish to our Azure Web Site.

Azure SDK Install

If you’re using Visual Studio 2012 RC, you can skip this step. For those running VS 2010 SP1, you’re going to need to install the Azure SDK 1.7 or greater in order for VS 2010 to use the publish profile. Ultimately this just updates the publish options in VS 2010 to be like that of VS 2012’s.

You can download the SDK from here: https://www.windowsazure.com/en-us/develop/downloads/

I installed the .NET Full version, but Windows SDK only should work fine.

BlogEngine.NET Web Application Project

The default download/install of BlogEngine.NET is an “old school” web site project, which isn’t exactly compatible with Windows Azure (there’s a way, it’s just not easy). Web application projects are compatible with Windows Azure out of the box. Earlier this year the only option for BlogEngine.NET was to manually do the conversion, which wasn’t exactly straight forward. See my blog post: Converting BlogEngine.NET 2.5 to a Web Application for more info.

Luckily enough, when the BlogEngine.NET developers released 2.6 they also released a branch that is already converted to a web application. You can find more information on this post on rtur’s website (listed as coordinator for BlogEngine.NET) :

The WAP version is under a different codeplex repository located here: http://blogengineweb.codeplex.com/. As opposed to downloading the precompiled version we’re going to pull down the source since using the publish profile in Visual Studio requires a functioning build.

Download the source changeset for BlogEngine.NET 2.6 as a WAP from codeplex.

Make sure to extract this to a directory hierarchy that does not have spaces in it. The XCopy post build steps in BlogEngine.NET weren’t set up to work with a directory structure containing spaces.

Open it up in Visual Studio and make sure everything builds. Before we’re able to publish we’ll need to do a little project house cleaning. BlogEngine.NET ‘s WAP project has a handful of files that are missing yet still part of the project. We just have to remove the references to these files, otherwise the publish process will halt on them.

Delete the files from the following locations (should be easy spot with the exclamation marks) as seen below.

Now we’re ready to publish. Right click on BlogEngine.Web and select Publish.

This should bring up the publish dialog, which should look like the image below. If it looks different and it doesn’t have a spot to import the publish profile, then the Azure SDK may not have been installed or may need to be reinstalled.

Import the publish profile and all the info necessary to publish to the azure website should be prepopulated.

Hit the publish button and check the build output to see if the publish was successful.

Navigate to the site url detailed in the build output and you should be good to go.

Scaling Considerations

One thing to mention is that although we’ve deployed BlogEngine.NET to Windows Azure Web Sites, that in itself doesn’t make it inherently scalable. If we plan to scale out or have finally gotten to the point where it’s necessary to do so) we’d have to attack a few extra design considerations, which could be an entirely new blog post. I’ll just scratch the surface here of what needs to be considered.

By default BlogEngine.NET stores blog posts and their associated images in the file system. When scaling out both posts and images will need to be centralized and available across multiple hosted instances of BlogEngine.NET. In the simplest sense, this could be accomplished by switching over to Sql Azure for post and image storage, since BlogEngine.NET supports this natively.

Alternatively, you could use Azure’s Blob storage (see Azure Data management for an overview, Blob storage is described at bottom of page) to store the images individually, however this will require an additional BlogFileSystemProvider to be created so BlogEngine.NET can make use of it. Blob storage is made for this type of storage and is significantly cheaper per GB than Sql Azure.

Personally, I like to compress my post images after the fact using OptiPNG, which runs at the command line and processes a directory of png images. In which case, neither Sql Azure nor using Blob storage directly would be all that helpful for me. I might lean towards Azure Drive (also described in Azure Data management), which stores a VHD in Blob storage, but acts like a shared drive. It’s a little clunky to work with but it’s another option to consider depending on your needs.

As a side note, BlogEngine.NET doesn’t make use of session, so there are no changes necessary from that standpoint.

Conclusion

All in all, Azure Web Sites seem very easy to work with. Microsoft did a good job in making this a hassle free experience. The installation of BlogEngine.NET wasn’t that bad, however, I would of preferred for it to already be in the gallery, which would of meant we wouldn’t have had to deal with publishing from Visual Studio at all. It’ll be interesting to see how Azure Web Sites will ultimately be priced. Priced right, this could set a new bar for shared hosting standards and be a good entry point for those looking to get started with Windows Azure.

Noninvasive Unit Testing in ASP.NET MVC4 – A Microsoft Fakes Deep Dive

Wed, 02 May 2012 08:00:00 -0400

A lot of today’s unit testing technologies require significant invasive code changes in order to unit test appropriately. I’ve always been of the mindset that testing your code should be as noninvasive as possible to the system under test, regardless of how that system is designed.

The ability to test a system shouldn’t be dependent on whether or not that system was designed to be compatible with a certain set of testing tools. The design of systems should instead be driven by the needs of the problem domain, while complexity in applied patterns and concept count should only be escalated as it becomes necessary to do so.

In combining the KISS principle and YAGNI with agile architecture you get an architectural design, that at any given point in time, is the simplest to use, easiest to work with and the most maintainable as is allowable or possible in the problem domain in question.

The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided. – Wikipedia

"You ain't gonna need it" or “You aren′t gonna need it” (acronym: YAGNI) is the principle in extreme programming that programmers should not add functionality until it is necessary. – Wikipedia

Up until recently the ability to test without escalation of certain architectural patterns was not possible. Even if you wanted to practice a noninvasive testing style, the means to do so as well as community support weren’t generally available.

Conceptually, noninvasive testing tools and methodologies represent a natural progression/evolution in unit testing practices and principles. This is most visible in the evolution of major commercial testing tools, such as TypeMock’s Isolator and Telerik’s JustMock, that now have features to test/mock everything, not just interfaces and base classes. Now, with the introduction of Microsoft Fakes in Visual Studio 11 (more specifically the ability to detour via shimming), we are given all the tools necessary to accomplish noninvasive unit testing built right in to our development environment.

See my earlier blog posts on Microsoft Fakes for more background information: Using Stubs and Shims to Test with Microsoft Fakes in Visual Studio 11 and Comparing Microsoft Moles in VS2010 to Microsoft Fakes in VS11

Additionally Fakes allows us to take the “mockist” approach of behavior verification described by Martin Fowler in his article Mocks Aren’t Stubs.

But as often as not I see mock objects described poorly. In particular I see them often confused with stubs - a common helper to testing environments. I understand this confusion - I saw them as similar for a while too, but conversations with the mock developers have steadily allowed a little mock understanding to penetrate my tortoiseshell cranium.

This difference is actually two separate differences. On the one hand there is a difference in how test results are verified: a distinction between state verification and behavior verification. On the other hand is a whole different philosophy to the way testing and design play together, which I term here as the classical and mockist styles of Test Driven Development.

Later on in his article Martin provides a more concrete example as he discusses the differences.

The key difference here is how we verify that the order did the right thing in its interaction with the warehouse. With state verification we do this by asserts against the warehouse's state. Mocks use behavior verification, where we instead check to see if the order made the correct calls on the warehouse. We do this check by telling the mock what to expect during setup and asking the mock to verify itself during verification. Only the order is checked using asserts, and if the the method doesn't change the state of the order there's no asserts at all.

With that said I’ll be using Microsoft Fakes to apply noninvasive and mockist testing techniques to test the AccountController of a default MVC 4 project created using the "Internet Application” template, making absolutely no changes at all to the project. This example will use a mixture of both shimming and stubbing from Microsoft Fakes in order to get the job done.

Getting Started

Let’s take a quick look at the class definition for AccountController.

Looking through the implementations, a few of the methods are trivial enough for us to skip as part of this example.

public ActionResult ChangePassword() { return View(); }

public ActionResult ChangePasswordSuccess() { return View(); }

[AllowAnonymous]
public ActionResult Login() { return ContextDependentView(); }

[AllowAnonymous]
public ActionResult Register() { return ContextDependentView(); }

Additionally, we’re going to forego testing ContextDependentView, GetErrorsFromModelState & ErrorCodeToString in favor of the more complex methods. That’s not to say you wouldn’t test these methods for appropriate coverage, just that we’re going to exclude them to keep this post somewhat reasonable in length.

Before we get started though, we need to do some basic project setup.

Create a new ASP.NET MVC 4 Application project using the Internet Application template
Add a Unit Test Project, I renamed the default cs to AccountsControllerTests
Add references to the following items in the Unit Test project

the MVC 4 project
System.Web
System.Web.MVC

Additionally I’ll be using NUnit for assertions, so pull down NUnit from Nuget and add the following using statement to the top of the AccountsControllerTests file:

using Assert = NUnit.Framework.Assert;

After all that your solution should look something like this:

LogOff Method

We’ll start off with the LogOff method (as seen below), since this is one of the simpler methods we’re going to be looking at.

public ActionResult LogOff()
{
    FormsAuthentication.SignOut();

    return RedirectToAction("Index", "Home");
}

First off, let’s review our goals here. Since our intent with mocking is behavior verification, we want to test both that the correct RedirectToAction was returned and that FormsAuthentication.SignOut() was called. Testing that the correct RedirectToAction was returned seems easy enough, so we’ll start with that.

using System;
using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NoninvasiveMVC4Testing.Controllers;
using Assert = NUnit.Framework.Assert;

namespace NoninvasiveMVC4Testing.Tests
{
    [TestClass]
    public class AccountsControllerTests
    {
        [TestMethod]
        public void TestLogOff()
        {
            var accountController = new AccountController();
            var redirectToRouteResult = accountController.LogOff() as RedirectToRouteResult;

            Assert.NotNull(redirectToRouteResult);
            Assert.AreEqual("Index", redirectToRouteResult.RouteValues["Action"]);
            Assert.AreEqual("Home", redirectToRouteResult.RouteValues["controller"]);
        }
    }
}

We get the following results when running our new unit test:

Looking at the stack trace we can see that a NullReferenceException was thrown from FormsAuthentication.SignOut(). This makes sense as technically we’re not in the context of an actual web request and FormsAuthentication depends on a valid HttpContext to be available. This type of problem is common when testing web applications outside of the context of an actual request to a web server.

The traditional guidance on how to test something like this is as follows (see this StackOverflow post for more information):

Create a wrapping class around FormsAuthentication with a public method that runs the necessary method
Create an interface for this behavior
Use dependency injection in our controller to replace the direct call to FormsAuthentication with that of our wrapping class.

Using this formula, our controller code (not the test code mind you) would have to be changed as follows:

public interface IAuthenticationProvider
{
    void SignOut();
}

public class FormsAuthWrapper : IAuthenticationProvider
{
    public void SignOut()
    {
        FormsAuthentication.SignOut();
    }
}

public class AccountController : Controller
{
    private readonly IAuthenticationProvider _authenticationProvider;

    public AccountController(IAuthenticationProvider authenticationProvider)
    {
        _authenticationProvider = authenticationProvider;
    }

    public ActionResult LogOff()
    {
        _authenticationProvider.SignOut();
        return RedirectToAction("Index", "Home");
    }
}

As you can see this pattern is invasive to the system under test and with the purpose of this post being to apply noninvasive testing techniques, we’re going to consider a different way of testing using Microsoft Fakes. Surprisingly enough, it makes short work of these types of scenarios.

The Noninvasive Approach

Let’s start off by putting in what’s minimally necessary to get our test to pass as is. Right click on the System.Web reference in the test project and select Add Fakes Assembly. Once a Fakes assembly is added for System.Web we can use shims in Microsoft Fakes to detour the call to FormsAuthentication.SignOut() to an implementation of our choosing, hopefully one that won’t throw a NullReferenceException.

using System;
using System.Web.Mvc;
using System.Web.Security.Fakes;
using Microsoft.QualityTools.Testing.Fakes;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using NoninvasiveMVC4Testing.Controllers;
using Assert = NUnit.Framework.Assert;

namespace NoninvasiveMVC4Testing.Tests
{
    [TestClass]
    public class AccountsControllerTests
    {
        [TestMethod]
        public void TestLogOff()
        {
            var accountController = new AccountController();
            RedirectToRouteResult redirectToRouteResult;

            //Scope the detours we're creating
            using (ShimsContext.Create())
            {
                //Detours FormsAuthentication.SignOut() to an empty implementation
                ShimFormsAuthentication.SignOut = () => { };
                redirectToRouteResult = accountController.LogOff() as RedirectToRouteResult;
            }

            Assert.NotNull(redirectToRouteResult);
            Assert.AreEqual("Index", redirectToRouteResult.RouteValues["Action"]);
            Assert.AreEqual("Home", redirectToRouteResult.RouteValues["controller"]);
        }
    }
}

That’s simple enough and it does indeed pass.

We still have to test that FormsAuthentication.SignOut() was actually called. All we have to do is flip a bit inside of the detoured SignOut method (see lines 28 and 31) and assert it. Here’s the final method.

[TestMethod]
public void TestLogOff()
{
    var accountController = new AccountController();
    var formsAuthenticationSignOutCalled = false;
    RedirectToRouteResult redirectToRouteResult;

    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        //Detours FormsAuthentication.SignOut() to an empty implementation
        ShimFormsAuthentication.SignOut = () =>
        {
            //Set a boolean to identify that we actually got here
            formsAuthenticationSignOutCalled = true;
        };
        redirectToRouteResult = accountController.LogOff() as RedirectToRouteResult;
        Assert.AreEqual(true, formsAuthenticationSignOutCalled);
    }

    Assert.NotNull(redirectToRouteResult);
    Assert.AreEqual("Index", redirectToRouteResult.RouteValues["Action"]);
    Assert.AreEqual("Home", redirectToRouteResult.RouteValues["controller"]);
}

Testing that FormsAuthentication was called seems pretty trivial here, however we’ll build on this approach as we test more and more complicated methods.

JsonLogin

Moving on, JsonLogin is probably the next simplest method to test in order for us to ease our way into noninvasive testing with Fakes.

[AllowAnonymous]
[HttpPost]
public JsonResult JsonLogin(LoginModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        if (Membership.ValidateUser(model.UserName, model.Password))
        {
            FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
            return Json(new { success = true, redirect = returnUrl });
        }
        else
            ModelState.AddModelError("", "The user name or password provided is incorrect.");
    }

    // If we got this far, something failed
    return Json(new { errors = GetErrorsFromModelState() });
}

Right off the bat, it’s pretty clear that MemberShip.ValidateUser and FormsAuthentication.SetAuthCookie will need to be detoured based on our prior experience with the LogOff method. We’ll additionally test that the correct parameters were passed into each.

[TestMethod]
public void TestJsonLogin()
{
    string testUserName = "TestUserName";
    string testPassword = "TestPassword";
    bool testRememberMe = false;
    string testReturnUrl = "TestReturnUrl";

    var loginModel = new LoginModel
    {
        UserName = testUserName,
        Password = testPassword,
        RememberMe = testRememberMe
    };

    var accountController = new AccountController();
    JsonResult jsonResult;
    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        //Sets up a detour for Membership.ValidateUser to our mocked implementation
        ShimMembership.ValidateUserStringString = (userName, password) =>
        {
            Assert.AreEqual(testUserName, userName);
            Assert.AreEqual(testPassword, password);
            return true;
        };

        //Sets up a detour for FormsAuthentication.SetAuthCookie to our mocked implementation
        ShimFormsAuthentication.SetAuthCookieStringBoolean = (userName, rememberMe) =>
        {
            Assert.AreEqual(testUserName, userName);
            Assert.AreEqual(testRememberMe, rememberMe);
        };

        jsonResult = accountController.JsonLogin(loginModel, testReturnUrl);
    }
}

Now on to the tricky part, testing JsonResult. JsonResult.Data is of type Object, but is filled with an anonymous type.

return Json(new { success = true, redirect = returnUrl });

This makes it slightly more difficult to get at the properties we want to test.

Possible solutions

First off, we might try to cast JsonResult.Data out of Object into some type we could use to access the fields. This requires some runtime trickery and ends up being a bit of mess. See this StackOverflow post for more info.

private static T CastTo<T>(this Object value, T targetType) 
{ 
    // targetType above is just for compiler magic 
    // to infer the type to cast x to 
    return (T)x; 
}

Unfortunately, this only works if you’re working within the same assembly that defined the original anonymous type.

Next up, we could cleverly stuff a dynamic type with the value from JsonResult.Data and access the properties that way.

dynamic data = jsonResult.Data;
Assert.AreEqual(true, data.success);
Assert.AreEqual(testReturnUrl, data.redirect);

This fails as well, since anonymous types are declared as internal as described by the blog post: Anonymous Types are Internal, C# 4.0 Dynamic Beware!.

Even though the dynamic data variable has the success property, we don’t have access to it. We could use the assembly attribute InternalsVisibleTo in order to give our testing project access to internal types.

[assembly: InternalsVisibleTo("NoninvasiveMVC4Testing.Tests")]

I don’t consider this to be a bad technique, however since we’re trying to be completely noninvasive, I’m going to opt for a slightly different approach.

We’ll use PrivateObject (MSDN Link) to get at the properties. PrivateObject’s MSDN description:

Allows test code to call methods and properties on the code under test that would be inaccessible because they are not public.

PrivateObject ultimately just uses reflection in order to expose the values we need to test. The real value is in the fact that it abstracts the reflection code away from us. Here’s the code updated with PrivateObject:

var success = (bool)(new PrivateObject(jsonResult.Data, "success")).Target;
var redirect = (string)(new PrivateObject(jsonResult.Data, "redirect")).Target;

Assert.AreEqual(true, success);
Assert.AreEqual(testReturnUrl, redirect);

And with that we now have successful tests

Just for completeness, I’ve put together a test to validate the behavior of an invalid login.

[TestMethod]
public void TestInvalidJsonLogin()
{
    string testUserName = "TestUserName";
    string testPassword = "TestPassword";
    bool testRememberMe = false;
    string testReturnUrl = "TestReturnUrl";

    var loginModel = new LoginModel
    {
        UserName = testUserName,
        Password = testPassword,
        RememberMe = testRememberMe
    };

    var accountController = new AccountController();
    JsonResult jsonResult;
    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        //Sets up a detour for Membership.ValidateUser to our mocked implementation
        ShimMembership.ValidateUserStringString = (userName, password) => false;
        jsonResult = accountController.JsonLogin(loginModel, testReturnUrl);
    }

    var errors = (IEnumerable<string>)(new PrivateObject(jsonResult.Data, "errors")).Target;
    Assert.AreEqual("The user name or password provided is incorrect.", errors.First());
}

And there we go, easy as pie.

For the remainder of the post, I’m just going to focus on the “happy” path for brevity. Testing the other paths is relatively straight forward given what we’ve already done.

Login Method

Stepping up in complexity we move on to the Login method.

[AllowAnonymous]
[HttpPost]
public ActionResult Login(LoginModel model, string returnUrl)
{
    if (ModelState.IsValid)
    {
        if (Membership.ValidateUser(model.UserName, model.Password))
        {
            FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
            if (Url.IsLocalUrl(returnUrl))
                return Redirect(returnUrl);
            else
                return RedirectToAction("Index", "Home");
        }
        else
            ModelState.AddModelError("", "The user name or password provided is incorrect.");
    }

    // If we got this far, something failed, redisplay form
    return View(model);
}

MemberShip.ValidateUser and FormsAuthentication.SetAuthCookie are easy enough to test via Shimming. Under normal circumstances Url.IsLocalUrl would be simple to Shim as well. Unfortunately I ran into an issue when faking the System.Web.Mvc assembly containing it. Once you try to instantiate a controller (as part of your test project) after adding a Fakes assembly you get a System.Security.VerificationException: Operation could destabilize the runtime. See my Microsoft Connect submission for more info.

Fortunately enough, there’s a way to mock its implementation using the stubs portion of Microsoft Fakes as opposed to shims. This brings up an interesting dilemma, if a compatible stubbing technique is available should you use that instead of shimming?

I would say the answer is generally “yes” provided that these criteria are met:

It doesn’t significantly decrease the readability of the test
It doesn’t require excessive measures (such as reflection dumpster diving) to figure out how to do it

Stubbing Around System.Web.Mvc

The first problem we need to solve is that the Url property (of type UrlHelper) is null on our instance of AccountController. The ctor on UrlHelper requires a RequestContext. The ctor on RequestContext requires an HttpContextBase. Since HttpContextBase is an abstract class we can stub it easily and make our way back up the dependency hierarchy.

Decompiling UrlHelper with ILSpy shows us that we’ll need to stub one more item in order to avoid the dreaded NullReferenceException.

public bool IsLocalUrl(string url)
{
    return this.RequestContext.HttpContext.Request.IsUrlLocalToHost(url);
}

We need to make sure that the Request property on HttpContextBase returns a value. As luck would have it the Request property is of type HttpRequestBase and we can easily stub it as well.

[TestMethod]
public void TestLogin()
{
    string testUserName = "TestUserName";
    string testPassword = "TestPassword";
    bool testRememberMe = false;
    string returnUrl = "/foo.html";

    var loginModel = new LoginModel
    {
        UserName = testUserName,
        Password = testPassword,
        RememberMe = testRememberMe
    };

    var accountController = new AccountController();

    //Setup underpinning via stubbing such that UrlHelper 
    //can validate that our "foo.html" is local
    var stubHttpContext = new StubHttpContextBase();
    var stubHttpRequestBase = new StubHttpRequestBase();
    stubHttpContext.RequestGet = () => stubHttpRequestBase;
    var requestContext = new RequestContext(stubHttpContext, new RouteData());
    accountController.Url = new UrlHelper(requestContext);

    RedirectResult redirectResult;
    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        //Sets up a detour for Membership.ValidateUser to our mocked implementation
        ShimMembership.ValidateUserStringString = (userName, password) =>
        {
            Assert.AreEqual(testUserName, userName);
            Assert.AreEqual(testPassword, password);
            return true;
        };

        //Sets up a detour for FormsAuthentication.SetAuthCookie to our mocked implementation
        ShimFormsAuthentication.SetAuthCookieStringBoolean = (userName, rememberMe) =>
        {
            Assert.AreEqual(testUserName, userName);
            Assert.AreEqual(testRememberMe, rememberMe);
        };

        redirectResult = accountController.Login(loginModel, returnUrl) as RedirectResult;
    }

    Assert.NotNull(redirectResult);
    Assert.AreEqual(redirectResult.Url, returnUrl);
}

With that, let’s run our tests and make sure everything is working.

One thing to notice here, is that the stubbing we’re doing (starting line 20 and continuing to line 27) doesn’t exactly convey what we’re trying to accomplish. All we care about doing is getting Url.IsLocalUrl to return true. Additionally, we had to know quite a bit about the internals of a Controller, UrlHelper, HttpContextBase, HttpRequestBase just to get this behavior to work.

In this scenario it would be preferable, readability wise, just to set and detour Url.IsLocalUrl. In this case our hand was forced since Microsoft Fakes and System.Web.Mvc aren’t currently cooperating, so I’m more than happy that at least a fallback was available.

JsonRegister Method

Both JsonRegister and Register are very similar, so we’ll just hit one of them. There’s really no new concepts here, just reapplying the what we used to test earlier methods.

[AllowAnonymous]
[HttpPost]
public ActionResult JsonRegister(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        // Attempt to register the user
        MembershipCreateStatus createStatus;
        Membership.CreateUser(model.UserName, model.Password, model.Email, 
            passwordQuestion: null, passwordAnswer: null, isApproved: true, 
            providerUserKey: null, status: out createStatus);

        if (createStatus == MembershipCreateStatus.Success)
        {
            FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false);
            return Json(new { success = true });
        }
        else
            ModelState.AddModelError("", ErrorCodeToString(createStatus));
    }

    // If we got this far, something failed
    return Json(new { errors = GetErrorsFromModelState() });
}

For JsonRegister we’ll need to shim Membership.CreateUser, which is straightforward enough. We’ll need to add a reference to System.Web.Security.ApplicationServices to our testing project for to work with MembershipCreateStatus and we’re good to go.

[TestMethod]
public void TestJsonRegister()
{
    string testUserName = "TestUserName";
    string testPassword = "TestPassword";
    string testConfirmPassword = "TestPassword";
    string testEmail = "TestEmail@Test.com";

    var registerModel = new RegisterModel
    {
        UserName = testUserName,
        Password = testPassword,
        ConfirmPassword = testConfirmPassword,
        Email = testEmail
    };

    var accountController = new AccountController();
    JsonResult jsonResult;
    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        //Sets up a detour for Membership.CreateUser to our mocked implementation
        ShimMembership.CreateUserStringStringStringStringStringBooleanObjectMembershipCreateStatusOut =
            (string userName, string password, string email, string passwordQuestion, 
                string passwordAnswer, bool isApproved, object providerUserKey,
                out MembershipCreateStatus @createStatus) =>
            {
                Assert.AreEqual(testUserName, userName);
                Assert.AreEqual(testPassword, password);
                Assert.AreEqual(testEmail, email);
                Assert.Null(passwordQuestion);
                Assert.Null(passwordAnswer);
                Assert.True(isApproved);
                Assert.Null(providerUserKey);
                @createStatus = MembershipCreateStatus.Success;

                return null;
            };

        //Sets up a detour for FormsAuthentication.SetAuthCookie to our mocked implementation
        ShimFormsAuthentication.SetAuthCookieStringBoolean = (userName, rememberMe) =>
        {
            Assert.AreEqual(testUserName, userName);
            Assert.AreEqual(false, rememberMe);
        };

        var actionResult = accountController.JsonRegister(registerModel);
        Assert.IsInstanceOf(typeof(JsonResult), actionResult);
        jsonResult = actionResult as JsonResult;
    }

    Assert.NotNull(jsonResult);
    var success = (bool)(new PrivateObject(jsonResult.Data, "success")).Target;
    Assert.True(success);
}

Running our tests once again, we can see everything’s passing

ChangePassword Method

The ChangePassword method is slightly more difficult to work with, since we have additional items to fake and stub, but otherwise the concepts are pretty similar.

[HttpPost]
public ActionResult ChangePassword(ChangePasswordModel model)
{
    if (ModelState.IsValid)
    {

        // ChangePassword will throw an exception rather
        // than return false in certain failure scenarios.
        bool changePasswordSucceeded;
        try
        {
            MembershipUser currentUser = Membership.GetUser(User.Identity.Name, 
                userIsOnline: true);
            changePasswordSucceeded = currentUser.ChangePassword(model.OldPassword, 
                model.NewPassword);
        }
        catch (Exception)
        {
            changePasswordSucceeded = false;
        }

        if (changePasswordSucceeded)
            return RedirectToAction("ChangePasswordSuccess");
        else
            ModelState.AddModelError("", "The current password is incorrect or the new password is invalid.");
    }

    // If we got this far, something failed, redisplay form
    return View(model);
}

We need to make sure that User.Identity.Name returns properly. In order to do this, we’re going to have to make sure AccountController’s User property gets populated with an Identity object. Again, due to the MVC faking issue, we’re going to approach this via stubbing, which is slightly less readable and requires some framework dumpster diving, but still gets the job done.

Decompiling down into the Controller class in System.Web.Mvc to see what we need to stub show the following:

public IPrincipal User
{
    get
    {
        if (this.HttpContext != null)
        {
            return this.HttpContext.User;
        }
        return null;
    }
}

Drilling in this.HttpContext

public HttpContextBase HttpContext
{
    get
    {
        if (base.ControllerContext != null)
        {
            return base.ControllerContext.HttpContext;
        }
        return null;
    }
}

The ControllerContext property is settable, so that’s our way in and it has a public ctor taking elements we already have. Additionally, we already have a StubHttpRequestBase which we can set the User property on.

We’ll need to add a Fakes Assembly for mscorlib in order to stub an IPrincipal for the AccountController’s User property. To add a Fakes assembly for mscorlib, add one for the System reference. System.Web.ApplicationServices needs a Fakes assembly as well in order to shim the ChangePassword method on MembershipUser.

[TestMethod]
public void TestChangePassword()
{
    string testUserName = "TestUserName";
    string testOldPassword = "TestOldPassword";
    string testNewPassword = "TestNewPassword";

    var changePasswordModel = new ChangePasswordModel
    {
        OldPassword = testOldPassword,
        NewPassword = testNewPassword
    };

    var accountController = new AccountController();

    //Stub HttpContext
    var stubHttpContext = new StubHttpContextBase();
    //Setup ControllerContext so AccountController will use our stubHttpContext
    accountController.ControllerContext = new ControllerContext(stubHttpContext, 
        new RouteData(), accountController);

    //Stub IPrincipal
    var principal = new StubIPrincipal();
    principal.IdentityGet = () =>
    {
        var identity = new StubIIdentity { NameGet = () => testUserName };
        return identity;
    };
    stubHttpContext.UserGet = () => principal;

    RedirectToRouteResult redirectToRouteResult;
    //Scope the detours we're creating
    using (ShimsContext.Create())
    {
        ShimMembership.GetUserStringBoolean = (identityName, userIsOnline) =>
        {
            Assert.AreEqual(testUserName, identityName);
            Assert.AreEqual(true, userIsOnline);

            var memberShipUser = new ShimMembershipUser();
            //Sets up a detour for MemberShipUser.ChangePassword to our mocked implementation
            memberShipUser.ChangePasswordStringString = (oldPassword, newPassword) =>
            {
                Assert.AreEqual(testOldPassword, oldPassword);
                Assert.AreEqual(testNewPassword, newPassword);
                return true;
            };
            return memberShipUser;
        };

        var actionResult = accountController.ChangePassword(changePasswordModel);
        Assert.IsInstanceOf(typeof(RedirectToRouteResult), actionResult);
        redirectToRouteResult = actionResult as RedirectToRouteResult;
    }
    Assert.NotNull(redirectToRouteResult);
    Assert.AreEqual("ChangePasswordSuccess", redirectToRouteResult.RouteValues["Action"]);
}

After running tests, we see that our new unit test is passing.

Conclusions

Through the use of Microsoft Fakes and the idea of noninvasive testing, with the mockist approach, we’ve been able to test the AccountController quite thoroughly without any project modifications. I imagine we could of easily hit 100% coverage if that was our goal. The only real issues we ran into were related to beta software.

Oddly enough, I’m glad we ran into the System.Web.Mvc faking issue. This forced us to use stubbing, and ultimately exposed both negative effects on overall readability and increased complexity in terms of the amount of framework decompiling needed to figure out what stubbing was necessary. Shimming in these cases would of better conveyed our intent and abstracted us away from having to deal with the guts of the underlying framework.

With these results in mind, it’s evident that testing tools have truly reached a point where anything can be tested, regardless of design. We’re entering a time where ANY application with ANY architecture can be thoroughly unit tested without even the slightest change to code; a time when the ability to unit test a system is decoupled from the design and architecture of that system.

All of this is for good reason. Today’s testing patterns and practices have arisen from limitations in our capabilities to isolate dependencies when unit testing code. Those limitations have been addressed, it’s time to reevaluate our approaches and move on.

When you drive architecture with the goal of being structurally easier to test, the only thing you end up with is an architecture that is good at being tested. Let architecture be naturally shaped by the needs of the problem domain over time. Let complexity escalate only as needed and simplicity, maintainability and ease of use all be key goals in a system’s design.

From now on, we can definitively say that any constraints or limitations in our abilities to thoroughly test any system with any design, are entirely self imposed.

The code for this post is available on GitHub

Comparing Microsoft Moles in VS2010 to Microsoft Fakes in VS11

Fri, 20 Apr 2012 05:54:00 -0400

In my previous post: Using Stubs and Shims to Test with Microsoft Fakes in Visual Studio 11 I went over Microsoft Fakes (a mocking framework built into Visual Studio 2011) in detail. During my research I ran into Microsoft’s Moles Isolation Framework, which is the prior version of Microsoft Fakes that’s been in Microsoft Research for a few years.

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.

Just as with Microsoft Fakes, Moles provides a way to detour any .NET method as well as generally accepted basic Mocking functionality. The real interesting part about Moles is that it happens to be compatible with both Visual Studio 2010 and 2008. As I mentioned in the previous post there are only a handful of products that can detour .NET methods in VS 2010: TypeMock’s Isolator, Telerik’s JustMock and Microsoft’s Moles, costing: $799, $299 and free respectively.

I've been looking into “future proofing” some of our new testing initiatives and perhaps using Moles to bridge the gap between today’s testing and tomorrow’s tools. The Moles roadmap points out that Microsoft Fakes is the next generation of Moles and that a Moles to Fakes conversion will require a few modifications.

The Fakes Framework in Visual Studio 11 is the next generation of Moles & Stubs, and will eventually replace it. Fakes is different from Moles, however, so moving from Moles to Fakes will require some modifications to your code. A guide for this migration will be available at a later date.

That raises a few questions:

How different are the two versions?
How many modifications will be required for conversion?
Is it “safe” to use Moles in existing projects?

Under the covers things appear to have been refactored significantly for inclusion in VS 11. It’s hard to get a feel of how much movement there’s been since compare tools tend to breakdown when namespaces and class names are changed dramatically. After looking through the structures of both Moles and Fakes with ILSpy it’s pretty obviousthat the dev teams on this have been quite busy.

Luckily enough though, after a decent amount of usage it looks as though Moles is nearly identical to Microsoft Fakes in terms of general usage. With that in mind, the migration, even if it is a manual one, doesn’t look to be too bad and appears relatively straight forward. Despite the simplicity of conversion I’ll be holding out hope for an automated conversion out of the box or as a separate tool.

The main user facing changes from Moles to Fakes are:

Fakes refers to a detour as Shim, instead of as a Mole
Generated classes that were prefixed with “M” for Mole or “S” for Stub are instead prefixed with “Shim” and “Stub” respectively
The HostType attribute is no longer necessary
Some assembly attributes may no longer be necessary
.moles configuration files are now .fakes configuration files
Some configuration file options have been removed

With that said here’s a quick overview of installation, usage and comparisons detailing the similarities, reusing examples from my previous post on Microsoft Fakes.

Note: this post is a little lighter on the details of what Microsoft Fakes and Moles are and why you’d want to use it. If you find yourself wanting a little more background information and/or haven’t read my previous post on the subject, then you may want to take some time and check it out first.

Installing Moles

Moles is available through Visual Studio’s Extension Manager. This eventually leads you to the product page in the Visual Studio Gallery.

Search for Moles.

Download and start the installer. Note: not all steps are shown here; the install is rather straight forward.

Pick the typical setup type as custom doesn’t really offer anything you’d want to change anyway.

Quick, easy, done.

Now we’re ready for some “Moling” action! Hmmm… perhaps it was for the better that they renamed this in Visual Studio 11.

Moling Example & Comparison

First off we have a little bit of boilerplate code to setup. Aside from the different namespaces and 1 different class name, this is essentially the same trivial cart example as the previous post, so feel free to skip ahead if your interested in the more “juicy” bits.

In Visual Studio 2010 create a C# Class Library project called MolesExample. Rename the default class file to CartToMole and modify the code to be as follows:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace MolesExample
{
    public class CartToMole
    {
        public int CartId { get; private set; }
        public int UserId { get; private set; }
        private List<CartItem> _cartItems = new List<CartItem>();
        public ReadOnlyCollection<CartItem> CartItems { get; private set; }
        public DateTime CreateDateTime { get; private set; }

        public CartToMole(int cartId, int userId)
        {
            CartId = cartId;
            UserId = userId;
            CreateDateTime = DateTime.Now;
            CartItems = new ReadOnlyCollection<CartItem>(_cartItems);
        }
 
        public void AddCartItem(int productId)
        {
            var cartItemId = DataAccessLayer.SaveCartItem(CartId, productId);
            _cartItems.Add(new CartItem(cartItemId, productId));
        }
    }
}

Add the CartItem class.

namespace MolesExample
{
    public class CartItem
    {
        public int CartItemId { get; private set; }
        public int ProductId { get; private set; }

        public CartItem(int cartItemId, int productId)
        {
            CartItemId = cartItemId;
            ProductId = productId;
        }
    }
}

Add the DataAccessLayer class. Again, don’t worry about the connection string, we’ll never end up hitting it anyway.

using System.Data;
using System.Data.SqlClient;

namespace MolesExample
{
    public static class DataAccessLayer
    {
        public static int SaveCartItem(int cartId, int productId)
        {
            using (var conn = new SqlConnection("RandomSqlConnectionString"))
            {
                var cmd = new SqlCommand("InsCartItem", conn);
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.Parameters.AddWithValue("@CartId", cartId);
                cmd.Parameters.AddWithValue("@ProductId", productId);

                conn.Open();
                return (int)cmd.ExecuteScalar();
            }
        }
    }
}

Next add a Unit Test Project called MolesExample.Tests and rename the default unit test class file to CartToMoleTests.

In the MolesExample.Tests project add a reference to the MolesExample project. You’re solution should look as follows:

Right click on the MolesExample reference in MolesExample.Tests references and select the “Add Moles Assembly” option. Note: Screen captures of the Fakes version are positioned either to the right or bottom depending on your available screen width.

This adds a couple of new items to the project. You may need to refresh to see the new items as they didn’t come up right away for me.

The new references add the following types. Also take note of how the namespacing between Moles and Fakes has changed.

The generated .Moles/.Fakes assembly type naming has only changed slightly between versions, which is what we’ll be working with for the most part.

VS 10	VS 11
MCartItem	ShimCartItem
MCartItem.AllInstances	ShimCartItem.AllInstances
MCartToMole	ShimCartToShim
MCartToMole.AllInstances	ShimCartToShim.AllInstances
MDataAccessLayer	ShimDataAccessLayer
SCartItem	StubCartItem
SCartToMole	StubCartToShim

The .moles configuration file has been appropriately renamed to .fakes and the internals renamed accordingly. I’ll expand out the structure of the .moles file later on in the post and compare that to the expanded .fakes configuration file. For now here are the differences between them in terms of our two projects:

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
  <Assembly Name="MolesExample" />
</Moles>

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="FakingExample"/>
</Fakes>

Now, let’s create our first test method using a Mole. Just as before we’re going to unit test the AddCartItem method. AddCartItem calls SaveCartItem on DataAccessLayer, which happens to be static. We’re going to mock out that database call to isolate the logic in AddCartItem in our unit test. Add the code below to CartToMoleTests.

using Microsoft.Moles.Framework;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MolesExample.Tests
{
    [TestClass]
    public class CartToMoleTests
    {
        [TestMethod, HostType("Moles")]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            //Create a context to scope and cleanup moles
            using (MolesContext.Create())
            {
                int cartItemId = 42, cartId = 1, userId = 33, productId = 777;

                //Mole SaveCartItem rerouting it to a delegate which 
                //always returns cartItemId
                Moles.MDataAccessLayer.SaveCartItemInt32Int32 = (c, p) => cartItemId;

                var cart = new CartToMole(cartId, userId);
                cart.AddCartItem(productId);

                Assert.AreEqual(cartId, cart.CartItems.Count);
                var cartItem = cart.CartItems[0];
                Assert.AreEqual(cartItemId, cartItem.CartItemId);
                Assert.AreEqual(productId, cartItem.ProductId);
            }
        }
    }
}

Here’s the class file we used in the Microsoft Fakes example for reference. The only real differences aside from namespacing are on lines 9 (Moles HostType is no longer needed), 13 (context name change) and 19 (actual detour) and all are quite minor.

using Microsoft.QualityTools.Testing.Fakes;
using Microsoft.VisualStudio.TestTools.UnitTesting;
 
namespace FakingExample.Tests
{
    [TestClass]
    public class CartToShimTests
    {
        [TestMethod]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            //Create a context to scope and cleanup shims
            using (ShimsContext.Create())
            {
                int cartItemId = 42, cartId = 1, userId = 33, productId = 777;
 
                //Shim SaveCartItem rerouting it to a delegate which 
                //always returns cartItemId
                Fakes.ShimDataAccessLayer.SaveCartItemInt32Int32 = (c, p) => cartItemId;
 
                var cart = new CartToShim(cartId, userId);
                cart.AddCartItem(productId);
 
                Assert.AreEqual(cartId, cart.CartItems.Count);
                var cartItem = cart.CartItems[0];
                Assert.AreEqual(cartItemId, cartItem.CartItemId);
                Assert.AreEqual(productId, cartItem.ProductId);
            }
        }
    }
}

Now let’s run it in Unit Test Explorer and see it pass.

Just as before, our mole/detour completely skipped over the SaveCartItem method in DataAccessLayer avoiding the exception due to “RandomSqlConnectionString” clearly not being a valid connection string. Start to finish, Moles ends up being just as easy to setup and use as Fakes for our simple cart example.

Stubs Example and Comparison

As with the Mole example above, there’s some boilerplate we need to setup before we get to the stub test. Again, there are very few changes here, so if you’ve seen these before feel free to skip ahead.

We’ll need to create an ICartSaver interface and inject/pass it into the CartToStub object. At which point we can stub out ICartSaver and have it return 42 just as we did for our Moling example.

Add a new interface ICartSaver to the MolesExample project.

namespace MolesExample
{
    public interface ICartSaver
    {
        int SaveCartItem(int cartId, int productId);
    }
}

Next up, for completeness (although not necessary, since we’ll be stubbing around it), add a CartSaver class to the MolesExample project so we can replicate the implementation of DataAccessLayer.

using System.Data;
using System.Data.SqlClient;

namespace MolesExample
{
    public class CartSaver : ICartSaver
    {
        public int SaveCartItem(int cartId, int productId)
        {
            using (var conn = new SqlConnection("RandomSqlConnectionString"))
            {
                var cmd = new SqlCommand("InsCartItem", conn);
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.Parameters.AddWithValue("@CartId", cartId);
                cmd.Parameters.AddWithValue("@ProductId", productId);

                conn.Open();
                return (int)cmd.ExecuteScalar();
            }
        }
    }
}

Create a new CartToStub class as follows similar to CartToMole but allowing for manual dependency injection of ICartSaver in the constructor:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace MolesExample
{
    public class CartToStub
    {
        public int CartId { get; private set; }
        public int UserId { get; private set; }
        private List<CartItem> _cartItems = new List<CartItem>();
        public ReadOnlyCollection<CartItem> CartItems { get; private set; }
        public DateTime CreateDateTime { get; private set; }
        private ICartSaver _cartSaver;

        public CartToStub(int cartId, int userId, ICartSaver cartSaver)
        {
            CartId = cartId;
            UserId = userId;
            CreateDateTime = DateTime.Now;
            _cartSaver = cartSaver;
            CartItems = new ReadOnlyCollection<CartItem>(_cartItems);
        }

        public void AddCartItem(int productId)
        {
            var cartItemId = _cartSaver.SaveCartItem(CartId, productId);
            _cartItems.Add(new CartItem(cartItemId, productId));
        }
    }
}

Moving back over to the MolesExample.Tests project, add a new unit test file named CartToStubTests. Create/Modify the AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart method to take into account the new changes.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MolesExample.Tests
{
    [TestClass]
    public class CartToStubTests
    {
        [TestMethod, HostType("Moles")]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            int cartItemId = 42, cartId = 1, userId = 33, productId = 777;
 
            //Stub ICartSaver and customize the behavior via a 
            //delegate, to return cartItemId
            var cartSaver = new Moles.SICartSaver();
            cartSaver.SaveCartItemInt32Int32 = (c, p) => cartItemId;
 
            var cart = new CartToStub(cartId, userId, cartSaver);
            cart.AddCartItem(productId);
 
            Assert.AreEqual(cartId, cart.CartItems.Count);
            var cartItem = cart.CartItems[0];
            Assert.AreEqual(cartItemId, cartItem.CartItemId);
            Assert.AreEqual(productId, cartItem.ProductId);
        }
    }
}

Here’s the class file we used in the Microsoft Fakes example for reference. Differences are on lines 8 (Moles HostType) and 15 (generated Stub type name) and are quite minimal.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace FakingExample.Tests
{
    [TestClass]
    public class CartToStubTests
    {
        [TestMethod]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            int cartItemId = 42, cartId = 1, userId = 33, productId = 777;

            //Stub ICartSaver and customize the behavior via a 
            //delegate, ro return cartItemId
            var cartSaver = new Fakes.StubICartSaver();
            cartSaver.SaveCartItemInt32Int32 = (c, p) => cartItemId;

            var cart = new CartToStub(cartId, userId, cartSaver);
            cart.AddCartItem(productId);

            Assert.AreEqual(cartId, cart.CartItems.Count);
            var cartItem = cart.CartItems[0];
            Assert.AreEqual(cartItemId, cartItem.CartItemId);
            Assert.AreEqual(productId, cartItem.ProductId);
        }
    }
}

Run the unit tests once more to see that everything’s passing.

Just as with the Moling example, the code is very similar to what would be used in Microsoft Fakes.

.Moles and .Fakes Xml Configuration File Comparison

The changes in the .fakes xml configuration file may require more effort to convert depending on what features were used. Basic usage as in generated but never modified shouldn’t be a problem. However, there are a handful of attributes which could be problematic to convert, since they’ve been removed. I’ve included both files expanded out via intellisense, with a description of the removed elements.

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
  <Assembly Name="" ExportedTypes="" Location="" ReflectionOnly="" x86="" />

  <CodeStyle AssemblyAlias="" DisableUniqueAlias="" MaxIdentifierLength="">
    <Copyright></Copyright>
    <FileHeader></FileHeader>
  </CodeStyle>

  <StubGeneration Disable="" SkipVirtualIndexers="" SkipVirtualMethods="">
    <Types>
      <Clear />
      <Add AbstractClasses="" Classes="" FullName="" Interfaces="" Namespace="" TypeName=""/>
      <Remove AbstractClasses="" Classes="" FullName="" Interfaces="" Namespace="" Obsolete="" TypeName=""/>
    </Types>
    <TypeFilter /> <!-- Deprecated -->
  </StubGeneration>

  <MoleGeneration Disable="">
    <Types>
      <Clear />
      <Add FullName="" Namespace="" TypeName="" />
      <Remove FullName="" Namespace="" Obsolete="" TypeName=""/>
    </Types>
    <TypeFilter /> <!-- Deprecated -->
  </MoleGeneration>

  <Compilation AssemblyName="" Debug="" DisableCodeContracts="" KeyFile="" ProjectTemplate="">
    <COMReference Guid="" VersionMajor="" VersionMinor="" WrapperTool="" />
    <Property Condition="" Name="" />
  </Compilation>
</Moles>

Here’s the .fakes file intellisense expansion for reference.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="" Location="" Version="" x86=""/>

  <StubGeneration Disable="" SkipVirtualIndexers="" SkipVirtualMethods="">
    <Clear />
    <Add AbstractClasses="" FullName="" Interfaces="" Namespace="" TypeName=""/>
    <Remove AbstractClasses="" FullName="" Interfaces="" Namespace="" Obsolete="" TypeName=""/>
  </StubGeneration>

  <ShimGeneration Disable="">
    <Clear />
    <Add FullName="" Namespace="" TypeName=""/>
    <Remove FullName="" Namespace="" Obsolete="" TypeName=""/>
  </ShimGeneration>

  <Compilation Debug="" DisableCodeContracts="" KeyFile="" ProjectTemplate="">
    <COMReference Guid="" VersionMajor="" VersionMinor="" WrapperTool=""/>
    <Property Condition="" Name="" />
  </Compilation>
</Fakes>

Here’s an overview of the changes from Moles to Fakes:

The ExportedTypes attribute (.moles line 2) was removed from the Assembly element.

Per the schema ExportedTypes is described as “Reflect over exported (visible outside the assembly) types only”. The only examples I can find for its usage are in moling the System assembly here and here. We’ll have to wait for the migration guide to see what is a suitable replacement for this behavior.
The CodeStyle element (.moles line 4) was removed.

Per the schema CodeStyle is described as “Code generation settings”. Aside from the Copyright and FileHeader elements the child attributes generally looked like debug switches. From the docs available at Microsoft Research there isn’t a whole lot of detail on when to use these settings or what purpose they serve. Nobody’s going to miss these.
The Types elements (.moles lines 7 & 16) have been removed and everything below has shifted up one level. Sounds good to me.
The Classes attributes (.moles lines 9 & 10) were removed from the Add & Remove elements in StubGeneration.

Per the schema Classes is described as “An optional filter to filter non-abstract classes”. Why this one was removed but not the inverse (AbstractClasses) is anyone’s guess. I imagine you can achieve the desired results with the other filters, so this could require a little more effort to update if you make use of this it.
The AssemblyName attribute (.moles line 24) was removed from the Compilation element.

Per the Schema AssemblyName is described as “Specifies the assembly name of the generated assembly”. This attribute only applies when compilation is disabled”. Again, no documentation available, no examples of usage, probably not going to miss it.

Additional Considerations for System & Mscorlib

Previously in Moles when adding a Moles assembly for mscorlib or System, Moles required a little bit of jury rigging. Assembly attributes may be required in some cases. See this post at social.msdn.microsoft.com (code below quoted from post) and this one from StackOverflow for more info.

using System;
using System.Moles;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.Moles.Framework;
[assembly: MoledType(typeof(System.DateTime))]

namespace Y2kMoles
{
    [TestClass]
    public class Y2kTest
    {
        [TestMethod]
        [HostType("Moles")] // add this attribute
        public void Y2k()
        {
            MDateTime.NowGet = () => new DateTime(2000, 1, 1);

            if (DateTime.Now == new DateTime(2000, 1, 1))
                throw new Exception("y2k bug!!!!");
        }
    }
}

Even with these changes I was still getting build errors. Supposedly there are issues related to the installation of SP1. See this post on StackOverflow for more info.

I ended up modifying the mscorlib.moles file using the type filters to only include DateTime and this fixed everything up.

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
  <Assembly Name="mscorlib" />
  <StubGeneration Disable="true" />
  <MoleGeneration>
    <Types>
      <Clear />
      <Add TypeName="DateTime" />
    </Types>
  </MoleGeneration>
</Moles>

That’s a slightly suboptimal user experience for such a common case. Microsoft Fakes seems to have fixed these issues. Adding a Fakes assembly to System also adds one for mscorlib and everything works just fine out of the box, which is the expected user experience. So during conversion to Fakes there may be some “dehacking” involved.

Conclusion

It would seem that Microsoft Moles is quite capable and so similar in terms of usage to Microsoft Fakes that using it in the interim until Visual Studio 11 is released is a simple decision. The functionality gained as well as future proofing ongoing development is well worth any drawbacks related to migration or some of Moles’ current issues. There will be some conversion effort involved (as the only conversion plans mentioned so far, are a guide for manual conversion steps), but it will be relatively simple and straight forward. Learn it, use it, love it!

The code for this post is available on GitHub.

Using Stubs and Shims to Test with Microsoft Fakes in Visual Studio 11

Thu, 05 Apr 2012 23:29:00 -0400

Microsoft Fakes is a full featured mocking framework built into Visual Studio 11. Currently, the available documentation is limited and marked as “preview only”, however it does provide us with some very good descriptions.

Microsoft Fakes is an isolation framework for creating delegate-based test stubs and shims in .NET Framework applications. The Fakes framework can be used to shim any .NET method, including non-virtual and static methods in sealed types.

Additionally here is Wikipedia’s definition of Mock Object for reference

In object-oriented programming, mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts.

Shim any .NET Method

The real interesting part here is that Microsoft Fakes can shim “any .NET method, including non-virtual and static methods in sealed types”. Existing mocking frameworks work by providing “on the fly” implementations to preexisting interfaces with a bit of Dependency Injection to get them situated in the class/method under test.

Microsoft Fakes is going a level deeper by mocking objects with no preexisting interfaces and allowing statics to be mocked in the process. This type of mocking is quite complex to pull off. So much so, that there are only a handful of products out there that do this. TypeMock’s Isolator, Telerik’s JustMock and the Microsoft Research project Moles that ultimately lead to Microsoft Fakes.

TypeMock’s Isolator has been a regular so to speak in unit testing circles for a while now and I’ve actively considered it before, but the starting price of $799 has always been a little steep for my tastes. Telerik’s JustMock is the new kid on the block (past 2-3 years). JustMock has freemium edition supporting general mocking features and a pay version which has support for static, sealed & non virtual mocking with a base price of $299.

The biggest surprise is the Microsoft Research project Moles, which seems to have about the same set of features as Microsoft Fakes, has apparently been available since 11/1/2010 and is compatible with both Visual Studio 2010 & 2008 (based on the Visual Studio 2010 Moles x86 - Isolation Framework for .NET download page). Perhaps this is the internet’s best kept secret… well, maybe not. Regardless, I’ll be creating a future blog post going over using Moles in Visual Studio 2010.

Architectural Implications

Without a commercial mocking framework or Microsoft Fakes, if you’re going to do unit testing and you want to do it right as in truly isolate the code under test then you’re going to need to mock dependent objects. However, just mocking the objects isn’t enough, you also need to instruct the code under test to use the mocks as opposed to its normal implementation. Typically this requires some form of Dependency Injection.

For reference here is Wikipedia's definition of Dependency Injection:

Dependency injection (DI) is a design pattern in object-oriented computer programming whose purpose is to reduce the coupling between software components. It is similar to the factory method pattern. Frequently an object uses (depends on) work produced by another part of the system. With DI, the object does not need to know in advance about how the other part of the system works. Instead, the programmer provides (injects) the relevant system component in advance along with a contract that it will behave in a certain way.

To truly isolate code in unit tests you’re typically bound to the following practices as part of Dependency Injection:

Any object that needs to be mocked needs to be non static and have an interface
You’ll either need to have a Dependency Injection framework as part of the architecture or the right patterns in place to manually resolve and inject as needed
Constructors will have to be modified to take in interface types for the dependent objects

That’s a lot of Architectural commitment. As with any design pattern there are “trade offs” involved in usage. With Dependency Injection you get reduced coupling and the ability to unit test thoroughly, increasing complexity and reducing maintainability by some level in the process. The question with any design pattern’s usage is: are the trade offs worth it based on the functionality provided for the problem domain in question?

Microsoft Fakes changes the trade off evaluation for Dependency Injection. Currently you trade increased complexity and reduced maintainability for increased code quality brought about by unit testing.

Microsoft Fakes decouples Dependency Injection from unit testing, therefore changing the value proposition for Dependency Injection to instead be weighed on its own merits of whether or not it adds value to the problem domain in question.

Proper unit testing can now be integrated into any codebase, legacy or new, small or large, and using Dependency Injection or not. With this in mind Microsoft Fakes is a game changer. Why a game changer now, presumably years after these features have been available in the wild?

The answer is widespread availability and acceptance. Anyone running Visual Studio will be able to run this (hopefully this will be part of the bare SDK as well). Additionally examples, documentation, blogs and training will be much more readily available. Faking may very well become a recommended practice along with unit testing at which point it could become as pervasive as general unit testing in .NET solutions. It’s a lot easier to justify its usage when everyone has access to it, not just those willing to shell out $299 to $799 a seat.

Shims vs Stubs

Let’s take a look at the current MSDN definition for Shims and Stubs

Stub types Stub types make it easy to test code that consumes interfaces or non-sealed classes with overridable methods. A stub of the type T provides a default implementation of each virtual member of T, that is, any non-sealed virtual or abstract method, property, or event. The default behavior can be dynamically customized for each member by attaching a delegate to a corresponding property of the stub. A stub is realized by a distinct type which is generated by the Fakes Framework. As a result, all stubs are strongly typed.

Although stub types can be generated for interfaces and non-sealed classes with overridable methods, they cannot be used for static or non-overridable methods. To address these cases, the Fakes Framework also generates shim types.

Shim types Shim types allow detouring of hard-coded dependencies on static or non-overridable methods. A shim of type T can provide an alternative implementation for each non-abstract member of T. The Fakes Framework will redirect method calls to members of T to the alternative shim implementation. The shim types rely on runtime code rewriting that is provided by a custom profiler.

Delegates Both stub types and shim types allow you to use delegates to dynamically customize the behavior of individual stub members.

Stub types appear to be what most free and/or open source mocking frameworks already do for us today, so there’s really no surprises here. Shim types on the other hand are where the action is at allowing us to detour static or non-overridable methods.

MSDN mentions that the detouring in shims does degrade performance slightly. In the brief amount of testing I’ve done there’s about a 20ms difference between shimmed vs stubbed implementation of the same code, which isn’t a deal breaker in terms of keeping tests fast. It would make sense the cost could be additive based on the amount of detouring you end up doing. So if you have the infrastructure to do either or, then pick stubbing over shimming.

Getting Started with Shims

First off, you’ll need Visual Studio 11, fire it up and create a new C# Class Library project called FakingExample. For this example I’ve put together a very trivial cart example to play with.

Rename the default class file to CartToShim and modify the code to be as follows:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace FakingExample
{
    public class CartToShim
    {
        public int CartId { get; private set; }
        public int UserId { get; private set; }
        private List<CartItem> _cartItems = new List<CartItem>();
        public ReadOnlyCollection<CartItem> CartItems { get; private set; }
        public DateTime CreateDateTime { get; private set; }

        public CartToShim(int cartId, int userId)
        {
            CartId = cartId;
            UserId = userId;
            CreateDateTime = DateTime.Now;
            CartItems = new ReadOnlyCollection<CartItem>(_cartItems);
        }

        public void AddCartItem(int productId)
        {
            var cartItemId = DataAccessLayer.SaveCartItem(CartId, productId);
            _cartItems.Add(new CartItem(cartItemId, productId));
        }
    }
}

Add the CartItem class.

namespace FakingExample
{
    public class CartItem
    {
        public int CartItemId { get; private set; }
        public int ProductId { get; private set; }

        public CartItem(int cartItemId, int productId)
        {
            CartItemId = cartItemId;
            ProductId = productId;
        }
    }
}

Add the DataAccessLayer class. Don’t worry about the connection string, we’ll never end up hitting it anyway.

using System.Data;
using System.Data.SqlClient;

namespace FakingExample
{
    public static class DataAccessLayer
    {
        public static int SaveCartItem(int cartId, int productId)
        {
            using (var conn = new SqlConnection("RandomSqlConnectionString"))
            {
                var cmd = new SqlCommand("InsCartItem", conn);
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.Parameters.AddWithValue("@CartId", cartId);
                cmd.Parameters.AddWithValue("@ProductId", productId);

                conn.Open();
                return (int)cmd.ExecuteScalar();
            }
        }
    }
}

Next add a Unit Test Project called FakingExample.Tests and rename the default unit test class file to CartToShimTests.

In the FakingExample.Tests project add a reference to the FakingExample project. You’re solution should look as follows:

Right click on the FakingExample reference in FakingExample.Tests references and select the “Add Fakes Assembly”.

This adds a couple of new items to the project.

The new references add the following types.

The .fakes file created under the Fakes folder turns out to be an xml file. The file provides a configuration file for the generation of the fakes assembly. I’ll cover more about what can be done in this file later on in the post. For now here’s a look at the default code generated output.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="FakingExample"/>
</Fakes>

Now we’re ready to do some faking. Let’s take a look at unit testing the AddCartItem method. AddCartItem calls SaveCartItem on DataAccessLayer, which happens to be static. We’re going to mock out that database call to isolate the logic in AddCartItem in our unit test. Add the code below to CartToShimTests.

using Microsoft.QualityTools.Testing.Fakes;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace FakingExample.Tests
{
    [TestClass]
    public class CartToShimTests
    {
        [TestMethod]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            //Create a context to scope and cleanup shims
            using (ShimsContext.Create())
            {
                int cartItemId = 42, cartId = 1, userId = 33, productId = 777;

                //Shim SaveCartItem rerouting it to a delegate which 
                //always returns cartItemId
                Fakes.ShimDataAccessLayer.SaveCartItemInt32Int32 = (c, p) => cartItemId;

                var cart = new CartToShim(cartId, userId);
                cart.AddCartItem(productId);

                Assert.AreEqual(cartId, cart.CartItems.Count);
                var cartItem = cart.CartItems[0];
                Assert.AreEqual(cartItemId, cartItem.CartItemId);
                Assert.AreEqual(productId, cartItem.ProductId);
            }
        }
    }
}

Line 13 creates a ShimsContext , which limits the scope of our shimming. Line 19 defines our shim/detour for the SaveCartItem method. Notice how we set the new behavior through a property named SaveCartItemInt32Int32. The Int32Int32 on the end is the type signature of parameters accepted by SaveCartItem. Microsoft Fakes has to keep the generated property names unique and predictable for methods, since they could have overloads or be refactored to have them someday. Now let’s run it in Unit Test Explorer and see if it passes.

It does indeed pass. Notice that our shim/detour completely skipped over the SaveCartItem method in DataAccessLayer, if it hadn’t then we would’ve received a nasty exception since “RandomSqlConnectionString” is clearly not a valid connection string . Start to finish, this ends up being pretty easy to setup and use for our simple cart example.

Stubs Example

For the stubs example our code will be very similar to the shim example however we’ll need to create an ICartSaver interface and inject it into the CartToStub object. At which point we can stub out ICartSaver and have it return 42 just as we did for shimming. We’ll manually inject the dependency as opposed to pulling down a DI framework.

Add a new interface ICartSaver to the FakingExample project.

namespace FakingExample
{
    public interface ICartSaver
    {
        int SaveCartItem(int cartId, int productId);
    }
}

Next up add, for completeness (although not necessary) add a CartSaver class to the FakingExample project so we can replicate the implementation of DataAccessLayer.

using System.Data;
using System.Data.SqlClient;

namespace FakingExample
{
    public class CartSaver : ICartSaver
    {
        public int SaveCartItem(int cartId, int productId)
        {
            using (var conn = new SqlConnection("RandomSqlConnectionString"))
            {
                var cmd = new SqlCommand("InsCartItem", conn);
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.Parameters.AddWithValue("@CartId", cartId);
                cmd.Parameters.AddWithValue("@ProductId", productId);

                conn.Open();
                return (int)cmd.ExecuteScalar();
            }
        }
    }
}

Create a new CartToStub class as follows similar to CartToShim but allowing for manual dependency injection of ICartSaver in the constructor:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace FakingExample
{
    public class CartToStub
    {
        public int CartId { get; private set; }
        public int UserId { get; private set; }
        private List<CartItem> _cartItems = new List<CartItem>();
        public ReadOnlyCollection<CartItem> CartItems { get; private set; }
        public DateTime CreateDateTime { get; private set; }
        private ICartSaver _cartSaver;

        public CartToStub(int cartId, int userId, ICartSaver cartSaver)
        {
            CartId = cartId;
            UserId = userId;
            CreateDateTime = DateTime.Now;
            _cartSaver = cartSaver;
            CartItems = new ReadOnlyCollection<CartItem>(_cartItems);
        }

        public void AddCartItem(int productId)
        {
            var cartItemId = _cartSaver.SaveCartItem(CartId, productId);
            _cartItems.Add(new CartItem(cartItemId, productId));
        }
    }
}

Moving back over to the FakingExample.Tests project, add a new unit test file named CartToStubTests. Create/Modify the AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart method to take into account the new changes.

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace FakingExample.Tests
{
    [TestClass]
    public class CartToStubTests
    {
        [TestMethod]
        public void AddCartItem_GivenCartAndProduct_ThenProductShouldBeAddedToCart()
        {
            int cartItemId = 42, cartId = 1, userId = 33, productId = 777;

            //Stub ICartSaver and customize the behavior via a 
            //delegate, ro return cartItemId
            var cartSaver = new Fakes.StubICartSaver();
            cartSaver.SaveCartItemInt32Int32 = (c, p) => cartItemId;

            var cart = new CartToStub(cartId, userId, cartSaver);
            cart.AddCartItem(productId);

            Assert.AreEqual(cartId, cart.CartItems.Count);
            var cartItem = cart.CartItems[0];
            Assert.AreEqual(cartItemId, cartItem.CartItemId);
            Assert.AreEqual(productId, cartItem.ProductId);
        }
    }
}

Run the unit tests once more to see that everything’s passing.

Just as with shims, start to finish, this ends up being pretty easy overall for our simple cart example.

The Fakes Xml File

The current MSDN library documentation details the nature of the .fakes xml file as follows:

The generation of stub types is configured in an XML file that has the .fakes file extension. The Fakes framework integrates in the build process through custom MSBuild tasks and detects those files at build time. The Fakes code generator compiles the stub types into an assembly and adds the reference to the project.

The .fakes file provides fine grained control of how stub and shim generation work for a particular assembly. Luckily enough the file has intellisense and pretty good descriptions when hovering, so exploration of features is rather straight forward. Expanding out all attributes and elements using intellisense provides us with the following structures.

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="" Location="" Version="" x86=""/>

  <StubGeneration Disable="" SkipVirtualIndexers="" SkipVirtualMethods="">
    <Clear />
    <Add AbstractClasses="" FullName="" Interfaces="" Namespace="" TypeName=""/>
    <Remove AbstractClasses="" FullName="" Interfaces="" Namespace="" Obsolete="" TypeName=""/>
  </StubGeneration>

  <ShimGeneration Disable="">
    <Clear />
    <Add FullName="" Namespace="" TypeName=""/>
    <Remove FullName="" Namespace="" Obsolete="" TypeName=""/>
  </ShimGeneration>

  <Compilation Debug="" DisableCodeContracts="" KeyFile="" ProjectTemplate="">
    <COMReference Guid="" VersionMajor="" VersionMinor="" WrapperTool=""/>
    <Property Condition="" Name="" />
  </Compilation>
</Fakes>

Based on this we see the following features:

Either shimming or stubbing can be completely turned off
Shims and stubs can be filtered such that only specific items from an assembly are shimmed and/or stubbed
Strong signing can be overridden via the KeyFile attribute, based on the MSDN docs the Fakes framework will automatically sign the .Fakes assembly with the same key the source assembly was signed with unless overridden here
There’s a facility to reference/deal with a COM component with COMReference if necessary. Hopefully it won’t be…

Aside from items within the compilation element everything is along the lines of what we’d expect to be available here. I imagine in most circumstances this file won’t need to be touched, however if you’re faking a larger library like mscorlib, then it would seem almost mandatory to filter the types generated otherwise the compiler could be chewing on it for a while. The classic DateTime.Now shimming examples should probably be doing this type of filtering.

Conclusion

All in all I’m really excited about Microsoft Fakes. It has the capacity to drive change in the .NET testing landscape similarly to how adding unit testing to Visual Studio (back in the 2005 version I believe) did so. Widespread inclusion, usage and education of faking/mocking will be very beneficial for the community and will help drive innovation of testing techniques. Projects which would’ve been considered difficult if not impossible to add some level of unit testing to, without large amounts of refactoring, can now be unit tested easily. Microsoft Fakes is a definitive win in my book.

The code for this post is available on GitHub

Windows 8 Consumer Preview on Lenovo S10-3T

Fri, 30 Mar 2012 21:29:00 -0400

With the announcement of the 2nd release of Windows 8 “The Consumer preview edition” back in February I thought it would be a good time to finally crack it open and take a look. I’m interested from several different perspectives:

Is this thing even usable as a tablet and subsequently as a desktop.
How consumer and corporation friendly is it.
How polished is it in it’s current state (perhaps inferring some relative release timeframe).
Is Html5/JavaScript app development done in such a way that it’s likely to catch on the way Microsoft expects.

To start with though, I need to get Windows 8 installed somewhere and that’s what this post is all about. Luckily enough I’ve had a Lenovo S10-3T netbook for a little while now and it generally acts as a living room/kitchen browsing machine. In other words, the perfect machine to cannibalize! Windows 8 will install onto the S10-3T with a little elbow grease. To get started, let’s take a look at the installation requirements of Windows 8 and the hardware specs for the S10-3T.

S10-3T Specs:

Processor	Intel Atom 1.66GHz N450
Ram	2GB DDR2
Hard drive	320GB 6400RPM SATA
Wi-Fi	802.11b/g/n
Screen type	Multi Touch Touch Screen - Swivel and Rotatable
Screen size	10.1
Resolution	1024 × 600

Note: The Lenovo S10-3T had several flavors of hardware, so your S10-3T may not necessarily have the same specs.

Windows 8 Consumer Preview’s Minimum System Requirements

From Windows 8 Consumer Preview: Frequently asked questions

Processor	1GHz or faster 32 Bit or 64 Bit
Ram	1GB for 32 Bit and 2GB for 64 Bit
Hard disk space	16GB Available hard disk Space for 32 Bit and 20 GB Available Hard Disk Space for 64 Bit PC's
Graphics card	DirectX 9 Graphics Device with WDDM 1.0 or higher driver.
Resolution	???

Additional requirements to use certain features:

To use touch, you need a tablet or a monitor that supports multitouch.
To access the Windows Store and to download and run apps, you need an active Internet connection and a screen resolution of at least 1024 x 768.
To snap apps, you need a screen resolution of at least 1366 x 768.

Resolution Issue

Initially this looks to be a pretty grim issue. The S10-3T only has a max resolution of (1024 x 600) and the minimal resolution “To access the Windows Store and to download and run apps” is 1024 x 768. Oddly enough Windows 8 will let you install on lower resolutions (perhaps this’ll be changed by release), however I can’t imagine the experience being all that spectacular without being able to download and run apps.

Searching the internet for workarounds reveals a handful of people already having installed Windows 8 on the S10-3T (albeit the previous preview) using a registry hack to enable higher resolutions via down scaling (more specifically 1024 x 768 and 1152 x 864). See liliputing.com and lenovos103t.com/jessebandersen.com for more information. But what is down scaling actually doing?

In numerical modeling, downscaling refers to techniques that take output from the model and add information at scales smaller than the grid spacing

Quoted from: http://en.wikipedia.org/wiki/Downscaling

In other words we still only have 600 physical pixels, we’re just jamming 768/864 worth of pixel data into 600 pixels of space and hoping for the best. Display properties will show the increased resolution of 1024 x 768 and 1152 x 864, but under the covers the operating system will down scale that to 600 pixels. The other downside is that the aspect ratios are slightly different, so the display is going to look somewhat stretched horizontally. All in all this isn’t a perfect solution, however it’s the only solution. Additionally looking at some screen shots online was reassuring enough in that the horizontal stretch isn’t unreasonable. If it’s between down scaling or no apps, I’ll take the down scaling.

Note: I’ll get into the exact details of how to do this during implementation.

32 Bit or 64 Bit

With the Windows 8 Consumer Preview we have the choice of pulling down either the 32 bit version or the 64 bit version. Additionally the S10-3T’s hardware is 64 bit compatible. After a little bit research it looks like 32 bit is the clear winner in this case.

There are very few advantages to 64 bit for the S10-3T. 64 bit windows programs actually take a little extra RAM because their memory pointers are a little bit bigger. Therefore even at Idle the 64 bit system is taking more RAM memory.

RAM usage with 32 bit OS at idle: about 480MB

RAM usage with 64 bit OS at idle: about 650MB

Also you have to remember that now the OS will try to run compatibility programs and therefore more processes which will slow your CPU and take RAM space.

2GB is not a large amount of RAM and you are better of with the 32 bit os. If you have 4GB RAM in a system then 64 bit seems like a better idea.

Quoted from: http://www.lenovos103t.com/2010/03/32-bit-vs-64-bit-windows-7-on-s10-3t.html

A Good Time for a Backup

I really had nothing important on my S10-3T, however I still created a full backup in just in case something did go horribly wrong. Depending on your situation you may not need this step at all or may need to just backup a handful of files. Regardless, I have a license for Acronis True Image and just used that to do a quick backup over the network. The pricing is good and the product works, good enough in my book. Only needed 20GB of space, which transferred over the LAN at a reasonable pace.

Warning Before Installation

After installation the WIFI was in the “off” state (as if it had been turned off via the fn key) and the necessary driver for fn key functionality is Lenovo specific and not part of Windows 8 Consumer Preview. In my case I just plugged in an Ethernet cable and downloaded the necessary drivers. You may want to download the drivers to a usb key first before continuing with installation if you’re only on WIFI. See the drivers section for more information.

Web Installer or ISO

The Web Installer option is probably the easiest option to use for installation, since the S10-3T doesn’t have a DVD drive, if you used the Web Installer skip to the next section.

In my case I started out looking for the ISO and didn’t even realize there was an installer until afterwards. If you do go the ISO route, then you will need an external USB DVD drive. I happened to have one lying around collecting dust so this option worked out pretty good.

Web Installer Download:	http://windows.microsoft.com/en-US/windows-8/download
ISO Download:	http://windows.microsoft.com/en-US/windows-8/iso

Burn the ISO to DVD using “Windows Disc Image Burner”, which should be in the Context Menu in Windows 7, unless you have another ISO burning program installed in which case you need to select “Open With” and then select “Windows Disc Image Burner”.

Next up, hook up a USB DVD and boot from the DVD. For some reason the S10-3T refused to boot from the DVD even with the boot order updated correctly to have the DVD before the hard drive. I removed everything else (besides the DVD) from the bootable options and this forced it to boot from the DVD.

Once booted in to the installation DVD let it work it’s magic. If you opted for the DVD/ISO install you need this product key during installation: NF32V-Q9P3W-7DR7Y-JGWRW-JFCK8 as detailed on the Windows 8 Consumer Preview: Frequently asked questions page.

After the first reboot make sure to set your boot options back to normal in the bios.

A Couple of Reboots Later

Windows 8 Consumer Preview should be installed after a couple of reboots. Go ahead and do all of the initial configuration and log in. Notice that Windows 8 appears to be working relatively fine despite our low resolution (the true minimum resolution must be less than 1024 x 600). Note: I had already logged in and customized a few things by the time this screen shot was taken so you’re Start screen may look slightly different.

Increasing the Resolution

Now that we have Windows 8 running it’s time to tackle the resolution issue. Per the Minimum System Requirements “To access the Windows Store and to download and run apps, you need an active Internet connection and a screen resolution of at least 1024 x 768. ” and we certainly want to download and run apps otherwise running the preview wouldn’t be very interesting or useful.

Swipe from right to left towards the right edge of the screen and select the Search icon in the upper right.
Type “regedit” into the “Search Apps” box and then start regedit.
Search for “Display1_DownScalingSupported” (Ctrl-F) in the registry and change the value from 0 to 1
Repeat for additional entries of “Display1_DownScalingSupported” (F3 for Find Next) in the registry
Reboot
Go back to the Search entry as done in step 1
Select the “Settings” option and type in “display” into the search box
Select “Change display settings” and adjust the screens resolution to either 1024x768 or 1152x864.

Now we have a resolution that we can experience most of Windows 8 with. The only thing we’re missing out on is the ability to “snap” apps, which isn’t that big a deal.

Drivers

As mentioned above in the “Warning Before Installation” section, after installation there may be issues with the fn keys not working. The WIFI started in the “off” state and without the fn key combo functionality there was no way to turn it on. After plugging in an Ethernet cable and a few Google searches later I found this post from Jesse B Andersen describing the drivers required to get the fn keys and power management to work.

Sam, thanks for sharing the 64bit experience! I'm unsure if the drivers from Lenovo are meant to work with 64bit, but you are our first 64bit tester.
The brightness setting could be part of Lenovo's Energy Management. The Fn stuff is from the Intel Chipset driver if I remember right.

Go to Lenovo’s drivers download page and install the drivers from the Chipset category for Windows 7.

At this point most fn keys should be working. Since Lenovo’s drivers wire up the fn key for WIFI to Lenovo’s Energy Management suite, it needs to be installed as well.

After the installation WIFI should now be toggleable with the fn key and we’re good to go. Note that the toggle window will only show in desktop mode.

Conclusion

Although installing Windows 8 Consumer Preview on the S10-3T can be a little involved and tricky at times, the payout in terms of usability and performance are well worth it. Windows 8 has given my S10-3T a new lease on life. It’s like a brand new machine. The touch features are dead on, touch dragging, touch scrolling and pinch zooming work smoothly. After seeing the performance benefits I’d have a hard time justifying reverting to Windows 7. Now I just have to figure out how to use it and how to put together a few test apps.

If you’re interested in dual booting with Windows 7 there’s a good guide posted at lucienkblog.wordpress.com

Converting BlogEngine.NET 2.5 to a Web Application

Sun, 26 Feb 2012 11:43:00 -0400

BlogEngine.NET 2.5 is currently distributed as a Web Site Project (WSP). The project makes use of some of the WSP’s features to be more flexible for non technical end users. For more technical users, who can recompile as necessary and don’t mind getting their hands dirty, a Web Application Project (WAP) conversion can provide some utility that the WSP can not. You can find a guide of the pros and cons of each approach on MSDN: Web Application Projects versus Web Site Projects.

Aside from a general preference of WAPs over WSPs my main reasons for converting are as follows:

Deploying to Windows Azure is simpler with WAPs (I’ve been toying with the idea of putting this puppy up there, with the recent price drop)
A single compiled assembly is easier to manage during deployment
Web.config transforms can only be done on WAPs

At the time of this post there are a handful of forums posts, wiki articles and blog posts which somewhat describe the process of conversion (I’ve included links to all of these at the end of the post). None of them capture all of the steps involved in conversion and the steps that were included weren’t always well detailed as one would like.

After reviewing all of the available info and performing the conversion several times myself. Here are the steps I’ve come up with and that I followed for the conversion of this site:

Pull down the BlogEngine.NET source code and open the solution in Visual Studio.
Remove the BlogEngine.Net Website project from the solution.
Navigate to the solution directory in Windows Explorer and rename the Website project’s folder from BlogEngine.NET to BlogEngine.NETOld or something similar. Leave Windows Explorer open, we’ll be back there again.
Add an ASP.NET Web Application project called “BlogEngine.NET” to the solution.
Remove most of the default files from the new Web Application project, such that it looks like the image below.
In Windows Explorer, copy all files except Bin & Obj from the renamed BlogEngine.NETOld folder to the new created BlogEngine.NET folder.
In Visual Studio, click the “Show All Files” icon in the Solution Explorer.
Right click the newly displayed files (with the exception of the aspnet_client and obj folders) and select “Include in Project” until your Solution looks like the image below. Note: don’t forget to include the files and folders below the Account, Add_Data, Scripts & Styles folders.
Add a new folder called Custom_Code and move everything except the Helpers folder from App_Code folder to Custom_Code folder.

The app code directory is one of the major differences between WAP and WSP. Most of the files in app code need to be moved out of app code, to a non-magic-name directory. The Helpers, however, are Razor helper classes and will only work if you paste the directly into the razor views, or leave them in the App_Code directory.

One consequence of moving the Extensions folder out of App_Code and into Custom_Code is that it will no longer be possible to view or edit the source code of an extension from the browser. This is good from a security perspective.
If, however, you want that functionality, create an App_Code/Extension folder and place those extensions in there. Do not, however, put all the extensions back because some of the extensions that ship with the product have dependencies and need to be included in the main dll (like the captcha extension).

Quoted from: Converting BlogEngine.net 2.5 to Web Application Project
Create a Helpers folder under Custom_Code and move RazorHelpers.cs there from the Helpers folder in App_Code. After steps 8 & 9 your Solution should be structured like the below image.
After moving the files from App_Code to Custom_Code the build action may be incorrect on many of the class files. For each of the files in Custom_Code change the build action to Compile in the Properties window.
In the BlogEngine.NET project make sure you have the following references (use the 1.0.0.0 versions if there are multiple versions available):
Add a project reference to BlogEngine.Core.

Since we’ve technically moved the App_Code into a new assembly, we need to let the app know where it’s at. Update the Web.Config pages section as follows:

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true" 
  controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
    <controls>
    <!--WAP FIX-->
    <!--<add namespace="App_Code.Controls" tagPrefix="blog"/>-->
    <add namespace="App_Code.Controls" assembly="BlogEngine.NET" tagPrefix="blog"/>
  </controls>
</pages>

I had the async ctp installed on my pc, which makes async a reserved word and causes a handful of exceptions, so we’ll need to fix that. Rename parameter async to asyncResult in BlogEngine.NET/Custom_Code/Controls/Blogroll.ProcessResponse.

//WAP FIX
//private static void ProcessResponse(IAsyncResult async)
private static void ProcessResponse(IAsyncResult asyncResult)
{
    //WAP FIX
    //GetRequestData data = (GetRequestData)async.AsyncState;
    GetRequestData data = (GetRequestData)asyncResult.AsyncState;
    Blog.InstanceIdOverride = data.BlogInstanceId;
    var blogReq = data.BlogRequest;

    try
    {
        //WAP FIX
        //using (var response = (HttpWebResponse)blogReq.Request.EndGetResponse(async))
        using (var response = (HttpWebResponse)blogReq.Request.EndGetResponse(asyncResult))
        {
            var doc = new XmlDocument();
            var responseStream = response.GetResponseStream();

There’s a naming collision in themes between StandardSite and TitaniumX (WAP class names need to be unique). Rename BlogEngine.NET/themes/TitaniumX/site.master.cs from StandardSite to TitaniumSite class, change inherits in BlogEngine.NET/themes/TitaniumX/site.master as well.

<%@ Master Language="C#" AutoEventWireup="true" Inherits="TitaniumSite " Codebehind="site.master.cs" %>
<%@ Import Namespace="BlogEngine.Core" %>
<% //WAP FIX 
   //<%@ Master Language="C#" AutoEventWireup="true" CodeFile="site.master.cs" Inherits="StandardSite " %>

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using BlogEngine.Core;

//WAP FIX
//public partial class StandardSite : System.Web.UI.MasterPage
public partial class TitaniumSite : System.Web.UI.MasterPage
{

Update the BlogEngine.Core/Utils.CodeAssemblies method by replacing assembly names with BlogEngine.NET.

public static IEnumerable<Assembly> CodeAssemblies()
{
    var codeAssemblies = new List<Assembly>();
    CompilationSection s = null;
    //WAP FIX
    //var assemblyName = "__code";
    var assemblyName = "BlogEngine.NET";
    try
    {
        try
        {
            s = (CompilationSection)WebConfigurationManager.GetSection("system.web/compilation");
        }
        catch (SecurityException)
        {
            // No read permissions on web.config due to the trust level (must be High or Full)
        }

        if (s != null && s.CodeSubDirectories != null && s.CodeSubDirectories.Count > 0)
        {
            for (var i = 0; i < s.CodeSubDirectories.Count; i++)
            {
                assemblyName = string.Format("App_SubCode_{0}", s.CodeSubDirectories[i].DirectoryName);
                codeAssemblies.Add(Assembly.Load(assemblyName));
            }
        }
        else
        {
            //WAP FIX
            //var assemblyName = "App_Code";
            assemblyName = "BlogEngine.NET";
            codeAssemblies.Add(Assembly.Load(assemblyName));
        }

Update BlogEngine.Core/Web/Extensions/ManagedExtension.GetPathAndFilename to point to the proper filename.

public string GetPathAndFilename(bool checkExistence)
{
    string filename = string.Empty;
    var appRoot = HostingEnvironment.MapPath("~/");
    var codeAssemblies = Utils.CodeAssemblies();
    foreach (Assembly a in codeAssemblies)
    {
        var types = a.GetTypes();
        foreach (var type in types.Where(type => type.Name == Name))
        {
            var assemblyName = type.Assembly.FullName.Split(".".ToCharArray())[0];
            assemblyName = assemblyName.Replace("App_SubCode_", "App_Code\\");
            var fileExt = assemblyName.Contains("VB_Code") ? ".vb" : ".cs";
            //WAP FIX
            //filename = appRoot + Path.Combine(Path.Combine(assemblyName, "Extensions"), Name + fileExt);
            filename += Path.Combine("Custom_Code\\Extensions", Name + fileExt);
        }
    }

Although this may not be absolutely necessary, since in WAP we won’t be writing changes to cs files from the admin screens anyway, it’s a good idea to clean up loose ends just the same. Update BlogEngine.NET/admin/Extensions/Editor.cshtml.

var extensionFilename = ext.GetPathAndFilename(false);
//WAP FIX
//var canWrite = Utils.CanWrite(Href(Utils.ApplicationRelativeWebRoot + "App_Code/Extensions"));
var canWrite = Utils.CanWrite(Href(Utils.ApplicationRelativeWebRoot + "Custom_Code/Extensions"));
var fileExists = !string.IsNullOrWhiteSpace(extensionFilename) && File.Exists(extensionFilename);

Convert to Web Application.
Success!

All in all the conversion wasn’t the most straight forward process, but not excessively complex by any means. The most difficult part was nailing down the correct steps and the correct sequence. After that, the conversion could be performed in under 30 mins. If there’s enough interest, I’ll upload a converted solution to GitHub.

For more information about BlogEngine.NET http://www.dotnetblogengine.net/ or http://blogengine.codeplex.com/

References