Daniel Cazzulino's Blog

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.

A practical example on how to mock static classes without TypeMock

WCF is the second biggest framework after ASP.NET that sooner or later forces you to use a static "context" property to do anything beyond the trivial stuff. ASP.NET has the HttpContext.Current, whereas WCF has the WebOperationContext.Current for example.

My friend Pablo Cibraro proves how you can quite easily make your implementations that depend on such static contexts testable without resorting to black-magic voodoo TypeMock kind of stuff. Any .NET developer can trivially introduce an indirection to make their classes testable, even if they depend on static classes.

So, don't buy a product just because you're lazy and want to avoid creating a few wrapper classes and interfaces. Most of them can be copied directly from Reflector's API rendering. And once you have the interfaces, you can just use MoQ or Rhino (or whichever mock framework you like) to mock them any way you want.

Always use the simplest thing that could possibly work.

Update: added a reference to other mock frameworks that can be used to the same effect. Apparently some people get picky if you have a preference and it happens to be the one you built :)

Update II: For those that didn't follow the discussion over at Roy's blog, I'll repeat an analogy that better explains what my point was with my previous post on mocking statics:

If you are not careful enough and can shoot yourself in the foot, the less shotguns you have around the house, the better.
That said, you may have a big, ugly, old contender where you really need the biggest shotgun you can get. But you'll be giving it to your very best guys, not to the newbie soldier.
Better to teach the newbies how to shoot smaller objectives with a regular pistol first (the whole point of Pablo's post on mocking WCF static context).
Some may say this sounds somewhat paternalist. I think that's pragmatism.

I'd rather show developers how to work around statics imposed by some "legacy" framework they happen to use (i.e. WCF and ASP.NET static contexts) by using typical OO techniques such as the one explained by Pablo, than giving them a bazooka and spending endless hours explaining how to NOT overuse it.

For the record, the technique is *exactly* the same used the ASP.NET MVC team, I don't hear anyone calling HttpContextBase and friends "utterly useless wrappers". I find it hard to think about a case where such a technique could not be applied to make new code written to interact/integrate with a legacy system testable. Would love to find a counter example.

Sometimes it's just that the solution ends up being much simpler than you initially thought. How hard do you think it is to do the ASP.NET MVC trick for the ASP.NET HttpContext? Go get the sources, find class MvcHandler and see for yourself.

Also, Pablo clarified that his original post was how to mock the WCF context, regardless of its static nature (as you could still pass it to your implementation's constructor), when it's neither an interface, nor a class with any virtuals that enable easy mocking.

More to the case against statics and singletons at Scott's blog.

Live Mesh FeedSync: an overview of the protocol under the hood

I already mentioned why I think Live Mesh is cool and that I think the most important part of it, FeedSync, is being largely ignored by reviewers. Fortunately, there's an extensive interview with the team that goes quite deep in FeedSync and how it works. Go watch it, it's good info.

At the most basic level, FeedSync is a mechanism to associate versioning "headers" to arbitrary objects (items), and an algorithm to merge and detect conflicts based on that header information. Replace "header" with "extension element" and "arbitrary object" with "RSS/Atom Item" and you have the XML feed version of it:

				<
				item 
				xmlns:sx
				='http://feedsync.org/2007/feedsync'>
 <title>Buy groceries</title>
 <sx:sync id='0a7903db47fb0fff' updates='1'>
  <sx:history sequence='1' by='kzu'/>
 </sx:sync>
</item>

The sx:sync element is the versioning header. Every time the item is updated (say, by another user/device), a new sx:history element is added and the updates attribute is incremented:

				<
				item
				>
 <
				title
				>Buy groceries</title>
 <sx:sync id='0a7903db47fb0fff' updates='2'>
   <sx:history sequence='2' by='vga'/>
   <sx:history sequence='1' by='kzu'/>
 </sx:sync>
</item>

If v1 of the item was updated simultaneously by two users and you try to merge them, you'd end up with something like the following:

				<
				item
				>
 <
				title
				>Buy groceries</title>
 <sx:sync id='0a7903db47fb0fff' updates='2'>
   <sx:history sequence='2' by='kzu'/>
   <sx:history sequence='1' by='kzu'/>
   <sx:conflicts>
     <item>
       <title>Buy icecream</title>
       <customer id='1' />
       <sx:sync id='0a7903db47fb0fff' updates='2'>
         <sx:history sequence='2' by='vga'/>
         <sx:history sequence='1' by='kzu'/>
       </sx:sync>
     </item>
   </sx:conflicts>
 </sx:sync>
</item>

Notice the added sx:conflicts element, which contains the conflicting item in its entirety. The algorithm provides a consistent selection of a default "winner" from the merge (in this case my v2 item, rather than Victor's). This gives you a consistent state across the mesh. But note that the merge operation with conflict does NOT resolve the conflict. It just surfaces it in a predictable way.

Needless to say, the default winner might not be what the end user wants, so at that point the application can surface the conflict (i.e. a different icon for the item) and allow him to resolve it in a different way (i.e. doing a full content diff and picking the new state). Alternatively, a specific implementation of an item store/adapter (i.e. the feedsync-enabled store for files) can provide automatic resolution if it so wishes to, such as doing an auto-merge of the file contents.

Pablo has more info on how it works and the way the Microsoft Sync Framework exposes this.

It seems really simple at first glance, doesn't it? The devil is in the details, as usual. It's obviously a RESTful approach to synchronization, where the item payload is the actual representation of the state. This means that upon conflict, all you have is the state. Implementing automatic conflict resolution can be quite tricky as a consequence.

Automatic Conflict Resolution?

As part of our Mesh4x implementation with InSTEDD, we're thinking about ways to increase the chances of automatic conflict resolution, as it's generally desirable and you don't want to be bothering your users for every apparently conflicting change. Think about a very simple example: tags. Say both user A and B add a tag at the same time, and then they synchronize:

Initial state of both A and B (say, created by yet another user, C):

				<
				item
				>
  <
				title
				>Buy groceries</title>
  <sx:sync id='0a7903db47fb0fff' updates='1'>
    <sx:history sequence='1' by='C'/>
  </sx:sync>
</item>

User A changes item by adding a category "to-do" (again, notice the new sx:history):

				<
				item
				>
  <
				title
				>Buy groceries</title>
  <category>to-do</category>
  <sx:sync id='0a7903db47fb0fff' updates='2'>
    <sx:history sequence='2' by='A'/>
    <sx:history sequence='1' by='C'/>
  </sx:sync>
</item>

Whereas user B changes it by adding a different category "supermarket":

				<
				item
				>
  <
				title
				>Buy groceries</title>
  <category>supermarket</category>
  <sx:sync id='0a7903db47fb0fff' updates='2'>
    <sx:history sequence='2' by='B'/>
    <sx:history sequence='1' by='C'/>
  </sx:sync>
</item>

When they sync, the algorithm will detect a conflict, as we have the same sequence number but with different "by". It will pick a default winner (say, A's change). But clearly this is a case where we could apply auto-merge semantics if we knew the operation each user performed.

You might be tempted to say: just do a content merge and that's it! But the semantics of a merge of state cannot be applied generically (i.e. a Company element gets an IsBankrupt='true' value from one user, and a new Invoice element from another: at the business logic level, the two changes cannot be merged. If the company went bankrup, you can no longer receive invoices from it), and it's even quite tricky with XML elements that can be moved around, renamed, deleted and re-inserted across multiple versions, etc.

So one approach we're thinking is to add command-pattern like hints that an adapter/store can use as hints for automatic conflict resolution and state reconstruction for merging. In the case above, maybe the XML adapter expresses user A operation as a combination of the item payload, the sync versioning header, and diff information about what was changed (added an element inmediately after the first child element of the root, in terms of XPath):

				<
				item
				>
  <
				title
				>Buy groceries</title>
  <category>to-do</category>
  <sx:sync id='0a7903db47fb0fff' updates='2'>
    <sx:history sequence='2' by='A'/>
    <sx:history sequence='1' by='C'/>
  </sx:sync>
  <diff xmlns=".../xmldiff">
    <add match="/*[1]">
      <category>to-do</category>
    </add>
  </diff>
</item>

The new diff element would be very similar in spirit to the XML Diff and Patch tool from Microsoft and would make it easier for the XML adapter to determine if a given change is compatible for auto-merge (i.e. it's not a change in a node that was removed, etc.).

I think different adapters might benefit from surfacing different conflict resolution hints. A database may include schema manipulation statements to perform upgrades, for example.

This is exploratory field as we try to make for the best user experience possible. We don't want to end up in the Groove approach where your choices are: save your changes as a different item, or discard your changes :S.

What do you think?

Live Mesh Everywhere: open source and cross-platform

You have probably read or listened all the (maybe a bit vague) information about the Mesh Operating Environment (MOE): a platform that will allow multiple applications and devices to participate in the Live Mesh.

Let's get to the more technical details now, and leave the end-user marketing to someone else ;).

At the core of Live Mesh is FeedSync, a public spec by Microsoft, evolved from the "old" days of SSE. It didn't get its deserved attention IMO back in the day, even though you could put together the pieces from Ray's announcement and later adoption by other products and figure out Live Mesh was coming sooner or later. Ed Jezierski got me interested in it WAY back, and as a result, I created the first open source implementation of the spec.

To understand its importance you need to first understand what FeedSync is. The most succinct definition I could come up with is:

FeedSync is a definition of a versioning header (or metadata) and its associated creation, update and deletion behavior as well as a generic conflict detection algorithm based on it, which can be attached to an arbitrary piece of data.

The interesting part of it, as you are probably realizing already, is NOT the XML microformat itself, or its representation in an RSS/Atom feed, but rather the behavior and semantics associated with it, which you can rely on to be present at compliant endpoints.

The specification defines the behavior for merging (arguably the most important one) data between two "feeds" (think of these as "streams of data with associated versioning header/metadata") in a consistent manner. It's two-way sync for the masses.

Of course, specs without implementations are seldom of any use. Microsoft is providing their own with the Microsoft Synchronization Framework (which does other things in addition to supporting FeedSync), and now Live Mesh. But nothing forbids the community from building compliant cross-platform open source alternative implementations.

Being an open source fan myself, and being lucky enough to work for an organization whose goal is to produce open source software to help in the humanitarian space, I'm glad to announce that we have already been working actively in this space, and we just released early versions of our ongoing projects at Google Code.

Mesh for X

Or Mesh4x for "short", is an umbrella project by InSTEDD under which we're producing Mesh4j and Mesh4n (Java and .NET respectively) versions of a unified implementation and library design/API for FeedSync synchronization between arbitrary repositories of data (i.e. databases, files, spreadsheets, etc.). We may very well come up with Mesh4py (Phyton), Mesh4r (Ruby) or whatever we or the community need to satisfy data synchronization scenarios.

The Mesh4n version is coming straight from its old place in CodePlex, but you expect it to evolve together with the Mesh4j version. Our goal is to keep feature-parity on both. This version of FeedSync for .NET is being used by Microsoft Humanitarian Systems (MHS) in Afganistan to synchronize disparate data sources in extreme and low connectivity conditions as mentioned by Ted Okada (i.e. to achieve two-way synchronization of disconnected Access databases, Excel files and plain RSS files on a pendrive, between any of them!).

At this time, both libraries provide the basic synchronization algorithm and Sync (metadata) data model, as well as the core interfaces to create your own repository adapters to expose data from arbitrary sources for FeedSync synchronization. We'll be building concrete repository adapters during the next few weeks. The most interesting one for me is the Mobile repository, which should allow you to sync two repositories over cellphones, without cellphone internet connection or even a data plan (which needless to say is not very frequent in the under-developed or even developing world).

We'll also be looking for refactoring opportunities to simplify certain scenarios and accomodate the future roadmap for FeedSync.

Some people have argued this is just another consumer-oriented Microsoft-thinghy that will hardly make a difference in anything. I believe that's a mistake, as it's ignoring the underpinning technology, the fact that it's a public specification, and that it can be applied to really free the data once and for all, regardless of platform, application, format, language, etc. This is the very reason I'm not excited at all by all the Atom Publishing Protocol fuss that's happening these days. Web 2.0/AJAX + APP is SO client-server... but that's for another post, another day.

Stay tunned as I'll be posting more detailed (and practical) information about Mesh4x in the coming weeks, as well as the cool stuff we're doing with InSTEDD as part of its goal of helping in the humanitarian space by applying technology.

MoQ now uses xUnit for its unit tests

After talking to a few guys during the MVP summit and the proceedings of the ALT.NET conference, I decided to give xUnit a serious try.

I'm quite pleased with it. Using .NET idioms rather than excessive attributes (i.e. [SetUp] vs class constructor, [TearDown] vs IDisposable, etc.) is a good thing.

"Upgrading" was quite easy: for the most part, it was a search & replace of:

[Test] => [Fact]
[SetUp] => ""
[TearDown] => ""
Assert.That => Assert.True
Assert.Fail => Assert.True(false,
Assert.Isxxx => Assert.xxx
Assert.Arexxx => Assert.xxx

The only tricky one which took the most time was replacing all the [ExpectedException] attributes with Assert.Throws. I like xUnit approach better, but it was annoying anyways. The good thing is that I deleted some code that was not used as the exceptions were being thrown before, and I didn't realize 'cause I was using [ExpectedException].

Renaming [Test] to [Fact] also has IMO a very good consequence: it forces you to think about your test method names as fact statements that make sense as an english sentence. I've argued with my team about the value of that, and we had a convention for [Test] that the method names must start with "Should". This also has the same effect, but being kind of enforced by the framework is better. The following test will now bother you when you read it:

[Fact]
public void InvokeWithTwoArgs()

you can no longer say that the method name expresses a fact. It's a subconscious thing, nothing to be too passionate about, but it helps, believe me.

One minor issue is that in order to use TDD.NET to run the tests, you need to run the xUnit installer tool (included in MoQ trunk at Lib\xUnit\xunit.installer.exe) to explicitly enable the runner. Unfortunately, once you do that, you can no longer use TDD.NET to run NUnit tests (or any of its supported test frameworks): you need to re-run the tool and disable TDD.NET support explicitly. But I'm confident it's just a matter of time before it's supported out of the box in TDD.NET.

So far, I think xUnit brings a fresh perspective to unit test frameworks. Challenging the status quo generally results in interesting new ideas IMO :)

Improving MoQ to allow arrange-act-assert testing style

Today, the MoQ API lets you setup expectations and later verify them, like so:

[Fact]
public void FillingRemovesInventoryIfInStock()
{
    //arrange/setup
    var order = new Order(TALISKER, 50);
    var mock = new Mock<IWarehouse>();

    //setup - expectations
    mock.Expect(x => x.HasInventory(TALISKER, 50)).Returns(true);
//act
    order.Fill(mock.Object);

    //assert
    Assert.True(order.IsFilled);
    //verify interaction
    mock.VerifyAll();
}

A very good feedback I got during the past MVP Summit was that the current approach moves all the semantic relevance for mocks up to the setup phase of the test. In order words, it doesn't fit well in the Arrange-Act-Assert pattern, as effectively the "asserts" (expectations that must be met) are now in the "arrange" (or setup) phase of the test.

The Verify/VerifyAll call which is down at the assertion phase contains no semantic whatsoever about what it is you are expecting to happen.

In order to be accomodate this requirement, I'm gonna be adding a overload to Verify that takes the expression you want to verify:

				//assert
mock.Verify(x => x.HasInventory(TALISKER, 50));

This would bring back the assertion phase to the place it belongs, if that's what you need. And because the default behavior on MoQ mocks is that they never throw on unexpected invocations, you can use the Expect only to setup return values when you need them (I'm hesitant to rename Expect to Setup, as for people using strict mocks that prefer the VerifyAll approach, it won't make much sense).

What do you think?

Locating the active item in the solution explorer

Say you are working with a code file. At some point, you "Go To Definition" of another type, and now you have its code file opened. Or maybe you just run the solution to debug a weird issue that's happening, turn on "break when exception is thrown" option, and just when the exception is thrown, Visual Studio gets activated, and you get the relevant code file opened at the appropriate location.

Now, say you have a typical solution, which contains solution folders and many projects. Can you quickly locate the project/folder where the file is?

I've found that MOST developers simply go fishing for the file, or look at the file path and pray the solution folders actually match physical folders so they can manually traverse it, etc. Turns out there's a much better alternative, which is to turn on "Track Active Item in Solution Explorer" under Tools > Options > Projects and Solutions:

Now after clicking OK, the solution explorer is automatically expanded and the proper node selected:

Much better, right?

Well, turns out that I'm pretty darn sure this option was ON by default in VS2002 and maybe even 2003. I reported this back in 2005 with a suggestion to turn it on by default again. It was resolved "By Design":

...due to a significant amount of customer feedback we've received. The concern that people were raising about having this option enabled by default was that there were certain scenarios where there was a performance hit.

Well, I tried it with the certainly big Enterprise Library 3.1 solution (no unit tests), which contains 38 projects with 1867 files in 1136 folders and haven't noticed any significant issue associated with enabling that option.

If you think the usability improvements from having this option on surpass the remote chance that in certain scenarios there may be a performance hit (?), please go and vote to get it fixed. Believe me, we CAN make it change. I'm going to reopen the bug if there are significantly new voters.