Daniel Cazzulino's Blog

What is all the fuzz about the new common IServiceLocator

There's been some excitement lately about the introduction of a common IServiceLocator that all major DI containers apparently will provide.

Unless you're building an "extensible framework leveraging framework consumer selectable IoC containers", don't sweat it too much, the interface was NOT created for you!

Let me reiterate: adding a dependency on IServiceLocator to your classes is NOT a good idea. When you do so, instead of an explicit and self documenting dependency on an external object, you're tunneling this locator that now hides to the class consumers which are its true dependencies. This is BAD, as it requires users to go to your class documentation (and hope it's updated) rather than its constructor to see what it needs to operate. If you've done any kind of work extending VS you know how bad this can get.

I've seen comments that this is just a "purist" view and that the real world ain't like this and you still need it.

Somehow some people seem to think that we (those who have contributed some open source framework of sorts) don't work on real projects and live in an ideal world and make frameworks for these ideal situations which don't actually translate to your real world. That we somehow just dream about the ideal conditions and spit a framework accordingly.

Oh that's so wrong ;). I wish it were that way sometimes, though, hehe.

I speak from experience in actual projects (working on two of them simultaneously these days, one of them fairly large), and let me repeat: YOU DON'T NEED A DEPENDENCY ON IServiceLocator in your business objects.

What you might need is to change your DI framework of choice if it doesn't allow you to get rid of that dependency ;).
Let me elaborate on some of the situations that supposedly require so:

Named instances: just move the named instance requirement outside the bz class and into the container configuration:
```
builder.Register<IBar>(c => new Bar(c.Resolve<IFoo>("a"))); 
```

Need all instances of X: again, move the dependency out of your bz class and into configuration!

builder.Register<IBar>(c => new Bar( /* get an IEnumerable<T> from container, or whatever */  ));

Need to create new instances of components inside your bz class (that is, you need a factory?): register a Func<T> factory for your component!
```
builder.RegisterGeneratedFactory<Func<IBar>>();

ctor Foo(Func<IBar> barFactory);

// Foo needs a new bar?
var b = barFactory();
```

If you can come up with a real world scenario (which does NOT involve authoring a framework such as ASP.NET MVC, MonoRail, etc.) where a good DI container cannot save you from having that dependency, only then I'll believe you need IServiceLocator.

I'd argue that people that should care/use such a thing is even less than 1%. That's why I wouldn't go about publicizing this thing so much, and you should hardly care about it. I can see it applied by (non-DI) framework authors to enable different DI frameworks to be plugged-in, but I hardly see how anyone doing "real world" work would benefit rather than detriment from its use.

There you have my rant too :)

Developing orientation and resolution aware Windows Mobile applications just got a TON easier

Quite some time ago I posted about how we (Clarius Consulting with Microsoft Patterns & Practices) solved the multiple resolution/orientation problem for Windows Mobile developers by introducing the Orientation Aware Control (OAC) as part of the Mobile Client Software Factory. As any 6-month project, there were a number of features that had to be left out because of time constraints. Also, being two years old also shows: that version does not support smartphone project types, neither Windows Mobile 6, nor VS2008, etc. A few bugs were also discovered after being released.

So we took the original version, and improved it substantially, adding highly requested features and keeping it up to date with the new platforms. Just take a look at the features and a comparison with the original p&p OAC.

You can now design your mobile applications that support multiple languages, resolutions and orientations in VS2008, and take advantage of the insanely cool VS integration the OAC provides:

Last weekend the OAC reached another important milestone with its 2008 RTM version! Just go and look at the screenshots and videos to see it in action. I'm quite proud of this particular project, as it involved quite a bit of spelunking with VS designer infrastructure, design-time location internals, run-time location behavior, etc.

My friend and OAC Lead Joe has blogged more about the release and why it's important to you.

Weirdest SQL Server 2005 installation on a Vista x64 machine

While attempting to install SQL Server x64 I got a number of errors, so I ended up uninstalling all components I could find in the control panel, and reinstalling x32.

Now it was time for SP2, I ended having to download BOTH x64 and x32 versions as half my components are in each platform :S. Miraculously enough, it works just fine.

Here's what I ended with:

Database Services x32
SQL Server Native Client x64
Client Components x32
Backward Compatibility x64
Microsoft SQL Server VSS Writer x64

I installed first the x64 SP2, and then x32, and everything went smooth (aside from the 2x download size).

How to get ASP.NET MVC Preview 4 to run with .NET SP1

As you probably know by now (i.e. from Phill's blog), however both Routing and Abstractions are. MVC Preview 4, however, has its own version of both assemblies.

In order to get MVC to use the new RTM bits of both assemblies (and avoid weird side-by-side errors), you just need to add the following binding redirect to the web.config file:

    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Abstractions" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="0.0.0.0" newVersion="3.5.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Routing" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="0.0.0.0" newVersion="3.5.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>

The other two redirects are added automatically by a Dynamic Data website, so I figured out it's better to put them there too :)

How to diagnose Linq to SQL easily and production-ready

Here's what we're currently doing: we add an InitializeContext method to all DataContext-derived classes, which is called from all ctors:

    private void InitializeContext()
    {
#if DEBUG
        if (Debugger.IsAttached)
        {
            this.Log = new DebuggerTextWriter();
        }
#endif
    }

Note that the logger will only be set if a debugger is attached, so that it doesn't pollute the output on a console app while you're running it.

The DebuggerTextWriter is trivial too:

#if DEBUG
    internal class DebuggerTextWriter : TextWriter
    {
        public override void Write(string value)
        {
            Debugger.Log(0, "", value);
            Console.Write(value);
        }

        public override void WriteLine(string value)
        {
            Debugger.Log(0, "", value + Environment.NewLine);
            Console.WriteLine(value);
        }

        public override Encoding Encoding
        {
            get { return System.Text.Encoding.UTF8; }
        }
    }
#endif

In both cases I'm wrapping the code in #if DEBUG so that it doesn't even go to production code. The debugger writer will write to the console output as well as the VS debugger output window.

Does CUIL search engine really work?

Query: "how to replace ipod touch boot screen"
Cuil: 1 result, completely unrelated to what I'm looking for
Google: 140k results, including the one I was looking for in the first 10
MS Live: 423k results, the actual answer nowhere to be found in the first 40 results (so, for practical purposes I guess it's the same as Cuil useless result too :))

Query: "how to locate active item in solution explorer vs"
Cuil: 0 results
Google: 2M+ results, VERY relevant to the search
MS Live: 177k results, first couple links VERY relevant, following ones somewhat related

Maybe it's because they are geeky questions, but for me, Google is still king, and all the fuss about the "the world's biggest search engine" is totally bogus.

Donut Oriented Programming

Donut Oriented Programming: DOP is a required discipline that you need to adhere to when your app will use VERY slow internet connection, such as in Cambodia and some other developing countries. Every action on the application that requires a roundrip to a server on the internet, should result in a donut being displayed to indicate that something is going on.

The need for nullable reference types to advertise optional constructor dependencies

In "traditional" OOP, you advertise your class required dependencies via constructor arguments:

public Foo(IOutput output, ILogger logger, ...)

Typically, the first few lines of code will check that these dependencies are not null.

Optional dependencies may be provided as properties, which you can leave unset (null).

Internally, in order to avoid a multitude of conditionals checking for nulls, you might have your own "null" implementations of the dependencies' interfaces (i.e. NullLogger which does nothing). This way the code is more readable, and you can always assume the dependencies are non-null and you'll never get a NullReferenceException ;)

One problem with property dependency injection is that you can't readily tell which properties are dependencies, and with constructor arguments, you cannot specify which ones are optional (can be passed null OK).

I think a much more consistent approach, and one that would integrate very well with the nullable value types functionality in .NET, is to introduce the concept of a nullable reference type:

public Foo(IOutput output, ILogger? logger, ...)

What this tells the caller, is that the first argument is a required dependency, while the second can be null. I believe the .NET framework should go one step further and give the implementer a null implementation of the interface or abstract class if the argument is null. This way, you get rid of all nulls in your apps.

You can also avoid depending on properties to advertise optional dependencies (and an associated custom attribute such as MEF in order to indicate it's a dependency and not a regular property).

Do you really care about Stub vs Mock?

I've argued in the past that this theoretical discussion is utterly useless. In my experience you need slightly different things from your test doubles at different times and depending on the scenarios and what you care about testing in a particular test.

If you're not using any mock/stub framework, you're typically creating manual test aids that morph (so that you can reuse them) as your tests evolve, and end up encompassing a mixture of a fake (i.e. you might put in an in-memory implementation), a stub (flags to tell you whether given members were called) and a mock (you might provide delegates to execute when members are executed, so that you can throw/callback/whatever). I've done this countless times before jumping to a framework/library to help me with this, and I know this is the continuum most developers live in.

Yet, we still see discussions like Rhino Mocks 3.5 Design Decisions: The role of Stub vs. Mock, were the user is asked to make a choice that he will seldom understand without reading the theoretical background. This is counter-productive IMO.

Compare the original two versions with Moq's version:

public void When_user_forgot_password_should_save_user()
{
    var userRepository = new Mock<IUserRepository>();
    var smsSender = new Mock<ISmsSender>();

    var theUser = new User { HashedPassword = "this is not hashed password" };

    userRepository.Expect(x => x.GetUserByName("ayende")).Returns(theUser);

    var controllerUnderTest = new LoginController(userRepository.Object, smsSender.Object);

    controllerUnderTest.ForgotMyPassword("ayende");

    userRepository.Verify(x => x.Save(theUser));
}

As you see, the way you use the "mock" is what makes it look more like a stub or a "true" mock (i.e. you verify all expectations, and you create it with MockBehavior.Strict). You don't have to pick a Stub vs Mock.

This simplifies the learning curve on the framework, and basically allows you to set intuitive options that don't force you entirely in one way or the other (the combination of Expect...Verifiable...Verify allows for VERY flexible usage).

I hope just like everyone's now seeing the value of NOT having an explicit record-reply model, we'll move past this rigid theoretical frame and into a more pragmatic and flexible view of mocking in general.

Mocking protected members with Moq

If you're familiar with Moq, you know that it relies on lambda expressions heavily. This is very good as you get full support from intellisense and refactoring features in Visual Studio. However, it also means you're for the most part restricted to setting expectations on things that your code has access too (public or internal members).

This is especially annoying with protected members, which are very common in template method pattern, factory methods, etc. In this case, you can't simply set an expectation with a lambda expression, as you have no access from the "outside" to the protected member. Being an important scenario, though, we wanted to add support for it.

We could have just extend the core Mock<T> API and add loosely-typed members that received strings (i.e. mock.Expect("Foo")). This would have been bad from the guidance point of view, as it would make for an easy path to "hell" for people not familiar with lambda expression ("mmm... I could use this overload with that lambda thinghy, or just use the simpler string-based overload..."). We'd much rather keep people using strong-typed, lambda-based expectations rather than jumping at the ease of strings.

So, we reached a compromise: we implemented protected expectations using strings, but it will only work for non-public members :). We also didn't want to make this functionality too easy to discover, so we expose it as an extension method that you enable by importing the Moq.Protected namespace:

using Moq.Protected;

then you use the Protected "extension point":

var mock = new Mock<CommandBase>();
mock.Protected()
     .Expect<int>("Execute")
     .Returns(5);

The Expect overload receiving a type parameter specifies the return value from the invocation. You also have ExpectGet/Set members, which expose the same functionality of the strong-typed lambda versions.

Note how rather than polluting the main API with extension overloads receiving strings, we hang all members from the IProtectedMock returned from the Protected() method call. That's an interesting use of extension methods I think, which you also get to see quite a lot in newer C# 3.5 libraries such as Autofac and Umbrella.

Another difference in the invocation style for expectations is the argument matching. Here, I couldn't find an easier way to specify then than using a separate class, ItExpr to specify them:

mock.Protected()
    .Expect<string>("Execute",
        ItExpr.IsAny<string>())
    .Returns(true);

The need for this is subtle, and lies in the fact that the Expect method is not receiving a lambda expression, unlike the strong-typed version, and the alternatives were far worse. So basically ItExpr is an expression-returning version of the It class. I still haven't figured out how you would use custom matchers in this scenario. I guess it would involve building the expression trees just like we do to reconstruct the same expression that would result from using the matcher in the lambda Expect.

If you want to play with it, just go ahead and get the latest version from Google Code.

Don't forget to give us feedback through the discussion list or issue tracker.

Enjoy!

Moq 2.5 shipped: lots of good news!

Today we shipped Moq v2.5. It's been a while since RC1 (a month or so feels so long for an open source agile project!) and we god very good feedback and suggestions for the final release. I'm pretty happy with the current drop and felt it was time for a new stable release.

The change log is quite extensive and yet there are quite a few fixes and improvements here and there that are not reflected in it. Over the next few posts I'll be showcasing the various new features. For now, here's the log:

Version 2.5

Added support for mocking protected members
Added new way of extending argument matchers which is now very straightforward
Added support for mocking events
Added support for firing events from expectations
Removed usage of MBROs which caused inconsistencies in mocking features
Added ExpectGet and ExpectSet to better support properties, and provide better intellisense.
Added verification with expressions, which better supports Arrange-Act-Assert testing model (can do Verify(m => m.Do(...)))
Added Throws<TException>
Added mock.CallBase property to specify whether the virtual members base implementation should be called
Added support for implementing, setting expectations and verifying additional interfaces in the mock, via the new mock.As<TInterface>() method (thanks Fernando Simonazzi!)
Improved argument type matching for Is/IsAny (thanks Jeremy.Skinner!)

My personal favorites: streamlined custom matchers (you can completely replace the built-in It.IsXXX matchers), mocking events and adding interfaces to a mock (I'll expand on those soon).

Go ahead and get the latest version from Google Code.

As usual, we'd love to hear your feedback at the discussion list or issue tracker, and patches are always welcome :)

Cool ajax loader image generator

Just found (via Brian) about this cool site to generate ajax-like loading donnuts like this one:

June 18-2008 can be a great day for the Web

And you can be part of it. The latest and greatest browser ever can make history and you can help!

VS2008 SP1 Beta: DON'T install without first backing up your settings!

I lost them all in the process :((((

Mesh synchronization of KML files through FeedSync

We've been working for the past few days on a mesh4x adapter that can synchronize a potentially big KML file at a very granular level (styles, placemarks, folders, etc.) so that you can collaboratively edit these large files without having to resolve spurious "conflicts".

From Ed's blog post:

This could be synchronized peer-to-peer (a KML on your disk to a KML on a USB drive or someone else's box) as well as via a 'cloud' web service. Note this is changing the data inside the KML, it is not just 'file sharing'. The adapter knows about KML and keeps track of versions of fine-grained elements (pushpins, placemarks, polygons) inside the same file. It is an example of how a data mesh could be used to synchronize fine-grained data between applications.

Update: Read more about the latest version (including single-file storage, KMZ support, etc.).

I believe this is one of the first instances of a mesh-style synchronization that really proves the point and possibilities of FeedSync and also Live Mesh. Something that Joel Spolsky clearly didn't get.

This technology is going to change the way we think about applications, data ownership and sharing. It's actually a pity that some people is focusing on the one *sample* application that Microsoft is showing (file/folder sharing) to evaluate it.