Opgenorth.NET

I’m currently working on a project where there are some functional tests that require a SQL Server database. Before in the past I’ve always handled this by using Redgate’s excellent SQL Server tools to create a monolithic script that would deploy the DB Schema, and then another set of scripts to set up the data.  Then it’s pretty trivial to use OSQL.EXE to run the scripts and setup the database.

However, in this case, I’m constrained to use the VS2010 database project and TFS Build.  So, the trick for me became how to use TFS 2010 Team Build to deploy a fresh copy of the database before the functional tests are run.  After a bit of jiggery-pokery, here is what I ended up doing.  I’m sure that at some point in my future, I will have to do this again, and nothing helps my failing memory like writing it down.

First a rough overview:

1. Declare some variables to hold the physical path of my .dbproj and the default data path for SQL Server.
2. Convert the source code control path of my .dbproj to the physical path on disk.
3. To help with debugging and diagnostics, write a build message with the location of the physical path of the .dbproj
4. Add an MSBuild task to my workflow that would deploy the .dbproj.

Without further adieu, here is more details breakdown of the steps involved.

Declare Variables

So, first things first – declare the two variables I need to hold the physical path to the .dbproj file, and the directory for my SQL Server databases.  This should be pretty simple and straight forward (assuming that the POS that is the “Workflow Designer” isn’t crashing VS2010 constantly).

Once that is out of the way I scrolled down the pretty, crashy, workflow designer until I came across the Compile and Test sequence.  At the very start of it I added a sequence that I called Deploy Database.  Inside this sequence I added the following Team Foundation Build Activities:

ConvertWorkspaceItem

The point to this BuildActivity is to figure where the hell on the file system TFS put one of the files.  Pretty straight forward:

WriteBuildMessage

Always nice to have a message in your log file to help with troubleshooting.  Here’s what my WriteBuildMessage activity looks like.  Notice that the message makes use of the “DbProjectPath” variable that we set above in the ConvertWorkspaceItemActivity.

MSBuild

This the working part of the the sequence.  In here we use MSBuild to call the .dbproj and deploy a fresh copy of the database to SQL Server. Key properties to set:

• CommandLineArguments : this contains the properties to pass on the command line when deploying.  You’ll want to provide these properties
  • /p:TargetDatabase=YOUR_DATABASE_NAME
  • /p:”DefaultDataPath=DIRECTORY_OF_DATABASE_FILES”
  • /p:”TargetConnectionString=YOUR_CONNECTION_STRING_FOR_THE_TARGET_DATABASE”
  • /p:DeployToDatabase=True
• Configuration : just specify which configuration in the solution to use.
• DisplayName : what ever you want, this is how the MSBuild activity will be displayed in your sequence
• LogFile : the name of the log file for the deploy
• OutDir : the output directory
• Project : Notice that this is the value of DbProjectPath, which we set above in our ConvertWorkItem
• RunCodeAnalysis : Set this to CodeAnalysisOption.Never.  Doesn’t make much sense to do code analysis on a database project.
• Targets :

Here is what the properties look like for this particuar Build Activity:

Now all of this has to live somewhere.  You might want to have this live somewhere else depending on when or how you want the database to deploy.  In my case, as I wanted to deploy the database BEFORE my tests ran, I hunted through the workflow and found the sequence called Run Tests.  I modified one side of the If condition to include a new sequence call Deploy DB and Run Tests:

Here is an overview of what my Deploy DB and Run Tests sequence looks like

After Thoughts

To be honest, I found the whole process annoying and awkward.  Sure, I didn’t have to edit a bunch of XML by hand, but the Workflow Designer in Visual Studio 2010 wasn’t exactly a joy to work with either.  I don’t know exactly what the problem was, but it kept crashing while I was trying to edit this Build Process Template. It was always the same error, an Out of Memory Exception.  On a Dell Latitude E6510 with 4GB of memory, this shouldn’t be happening.  As well, the whole editing process for the work flow was awkward at best.

As much as I dislike XML based build tools, at least text editors don’t get all crashy and such.  As well, I found the overall experience of trying to create and piece together the workflow for Team Build to be sluggish and tedious.  It’s great to have a GUI editor to hide the crummy XML, but honestly, I think the way FinalBuilder works is far superior to how VS2010 in terms of easy of use and readability(application crashes aside).

Next is to setup my Release build definition, and to tackle the issue of updated the version number in AssemblyInfo.cs and creating a zip file of all the deployment artifacts.  But first I’ve got to go and buy a bottle or two of Talisker to help numb the pain that will follow as I go done down that path.

I’ve spent a bit of my spare time in the past week looking at Windows Phone 7 from a developer’s point of view.  I’d have started sooner, but honestly, I didn’t see the point until there were actually devices that I could hold and use.  I know that in the U.S., some guys got developer phones from Microsoft, but I don’t think that anybody up here in Canada was that lucky.

So, over the past year or so I’ve been dabbling with Android and I actually like programming for Android.  The biggest issues I’ve run into with Android are my lack of Java skills – I keep doing things the C# way (you really don’t realize how handy Linq is until you don’t have it) and the fact that Android doesn’t have a decent UI designer.  But otherwise, I like Android.

So, I was curious what the developer experience was for WP7.  In a nutshell – it’s not bad, and in some ways better than that of Android.

Things I like about WP7 development:

• Being a C# guy, it was pretty easy and fast for me to get going with WP7.  Of course, Novell now has MonoDroid which in theory should lessen the learning curve for a C# guy to create Android applications.
• It’s nice to have good tooling to help with creating my UI’s.  Blend and Cider are pretty decent. Android does have DroidDraw, but I’ve never really found that tool to be good to work with.  Eclipse has some sort of an GUI designer thingy, but again, I’ve found it to be kind of lack-lustre at best.  That, and I don’t use Eclipse – I prefer IntelliJ.
• The Emulator seems to start up faster to me that the Android emulator – but that could just be me.
• The MVVM pattern.  I know the theory, and am now learning the more practical side of it.  Was worried that WP7 was going to decent into the path of darkness and pain that was/is Web Forms.
• I think that the debugger integrates better with the WP7 emulator.  Not that, generally speaking, I spend a lot of time in the debugger, but when you need it, it does seem to be more natural to me.  Again, this could just be because by day I do a lot of C# development so I’m more used to the Microsoft tooling to begin with.

Some things I didn’t like about WP7 development:

• You have to have Vista or Windows 7.  Yes, I know, XP is almost 10 years old, time to move on.  Call me an O/S curmudgeon.  I don’t mind Windows 7, but Vista sucks/sucked.
• It seems like to build your apps, you have to use Visual Studio 2010.  Not a problem for a developer, but I’m old school when it comes to compiling applications, and your build server shouldn’t be tainted by your IDE.
• I’m use to the relatively easy going Google marketplace and the fact I have numerous avenues available to me to distribute Android applications.  No such joy with WP7 apps.
• Editing XAML by hand.  But, I suppose it’s no worse that the XML resource files that Android uses.
• Not seeing a lot of projects whose code I can read.  Granted it’s still early, so hopefully that will change.  Or not.  .NET doesn’t seem to have the same OSS community spirit that Java does.

Microsoft has always tried to be pretty good to developers (sometimes to their own detriment), but I think Windows Phone 7 does have some things going for it, from a developer’s point of view anyway.  Here’s to hoping that strategy pays off – that cool apps will get written for WP7, and that it will be commercially viable.  Competition is good – it will keep Apple and Google on their toes. 

I guess I forgot to mention this:  On April 1, 2010, I received an e-mail from Microsoft that my MVP in C# was renewed for the third year.  This makes me a happy, because with Resharper 5 (and therefore Visual Studio 2010) and Windows Mobile 7, I’m hoping that this will be an exciting year for the .NET crowd. 

Well, okay, perhaps I didn’t forget.  Given that it was April 1st when I got the e-mail, I like to give things a few days to settle down.  I am acquainted with some mischievous pranksters who would think it was a funny April Fools joke.

Just sitting here at Legoland in Carlsbad, CA waiting for my kids to get off Coastersaurus. Just thought I’d make a mention about my presentation on SOLID to the Inland Empire .NET User Group. This is my third year in a row as their March speaker. I’m glad to say that for the third year in a row they haven’t chased me away with pitch-forks and torches. Largely based on that reason, I’ll say the presentation went well. Well, that and the fact that the concepts did seem to be understood and there were no technical glitches.

Thanks James and his crew for agreeing to shift from the 2nd Tuesday to the 3rd Tuesday to accommodate my travel.

Here is a zip of the code and slide deck.

Yesterday I was at TechDays 2009 in Calgary for the day (well, the morning really).  I wasn’t there as an attendee, but as a speaker.  Thanks to everybody who came out to my two talks, the first one on an Introduction to ASP.NET MVC and the second one on SOLIDifying your ASP.NET MVC Application.  There were a few hiccups along the way:  as usual, I fell victim to the Technical Presentation Time Dilation Syndrome (i.e. ran out of time) on both talks.  I guess I’m just to long-winded for my own good.  As well, because I was running a EAP of Resharper 5, I had some Visual Studio 2008 issues – namely VS2008 would hang on me from time to time.  Note to self: maybe don’t use the bleeding edge tools in a talk.  And I really should break myself of wanting to type all the code – using snippets would really save me time.

Two things that suprised me:

1. That there was still that much interest in ASP.NET MVC intro talks.  I just figured that everybody knew/knows about it.  Or maybe I just spend to much time with guys who have drunk the ASP.NET MVC Flavor Aid.  Either way, I think that there were some in the crowd that will convert from WebForms to ASP.NET MVC.
2. I asked how many people wrote unit tests or developing their software using Test Driven Development was the number of people who didn’t raise their hands.  While I didn’t expect the majority of the crowd, I did expect a lot more people than I saw.  Maybe it was a quiet crowd, and people didn’t feel like saying they wrote unit tests.  Maybe I live in a bubble, and my perception of what is actually going on in the .NET world is skewed (that is to say, perhaps writing tests is the exception rather than the rule).  It did kind of make me a bit concerned, as I truly believe that TDD does help one write better software overall.

Anyway, here’s to hoping that TechDays 2010 will stop off in Edmonton.  And hopefully have a track that will focus on developer fundamentals, like TechDays had in Toronto and Vancouver.

One of the nice things about Dependency Injection is that it can really help write a more flexible, modular application.  These days, it seems that there is no shortage of choice in the .NET community when it comes to IoC frameworks:

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC.

For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain.

There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator. What is Common Service Locator?  Well, allow me to cut and paste some text from the web site:

"The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.”

Blah blah blah – so what does all that mean?  Well, in my own words, CSL is basically a wrapper around your IoC container which separates how you  initialize/configure your IoC container from how you use it.  This separation allows you to use your IoC container without knowing anything about it.

This separation is achieved by use of adapters for the particular IoC container that you want to use.  These adapters are what do the dirty work of finding the service you need, in their own special way and totally transparent from your application code.  Currently, the Common Service Locator has adapters for StructureMap, Castle Windows, Unity, Spring.NET, and autofac.

Now, allow me an example of using the Common Service Locator with StructureMap. There is no special reason as to why StructureMap – it just happens to be what I find myself using these days.

Now, say I use the the following registry to configure StructureMap:

   1: public class DefaultStructureMapRegistry: Registry

   2: {

   3:     public DefaultStructureMapRegistry()

   4:     {

   5:         ForRequestedType<IDb4oConfiguration>()

   6:             .TheDefaultIsConcreteType<SimpleDb4oConfiguration>();

   7:     }

   8: }

In a nutshell this says that every time StructureMap is asked to provided an object of type IDb4oConfiguration, it should instantiate a SimpleDb4oConfiguration object and return that.  So, to get an instance of IDb4oConfiguration with StructureMap, I would do something like this:

   1: var db4oConfig = ObjectFactory.GetInstance<IDb4oConfiguration>();

Pretty simple, but it does kind of tightly couples me to StructureMap.  If I need/feel like/am forced at gunpoint to change my IoC container to something that is Not StructureMap, you can bet that there will be much wailing and gnashing of teeth on my part as I hunt through my code to make these changes.

Now enter the Common Service Locator.  First, let’s take a peek at some interfaces for CSL.  First an interface:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public interface IServiceLocator : IServiceProvider

   4:     {

   5:         object GetInstance(Type serviceType);

   6:         object GetInstance(Type serviceType, string key);

   7:         IEnumerable<object> GetAllInstances(Type serviceType);

   8:         TService GetInstance<TService>();

   9:         TService GetInstance<TService>(string key);

  10:         IEnumerable<TService> GetAllInstances<TService>();

  11:     }

  12: }

The IServiceLocator is an interface that your application will use when it requests something from your IoC container.

Another thing that CSL provides is a static class that your application would use to use a current IServiceLocator to request services.  That static class looks something like:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public static class ServiceLocator

   4:     {

   5:         public static IServiceLocator Current { get; }

   6:         public static void SetLocatorProvider(ServiceLocatorProvider newProvider) {};

   7:     }

   8: }

So, now lets see how we would request the default implementation of the IDb4oConfiguration service using CSL.  First, we would initialize CSL:

   1: var registry = new DefaultStructureMapRegistry();

   2: var container = new global::StructureMap.Container(registry);

   3: var smServiceLocator = new StructureMapServiceLocator(container);

   4: ServiceLocator.SetLocatorProvider(() => smServiceLocator );

What is going on here? Allow me to provide a quick line by line explanation:

Line 1 we instantiate a new StructureMap registry.  We then feed that registry to a StructureMap container in line 2.  With line 3, we see that StructureMap container is then fed to the StructureMapServiceLocator, which is the SM adapter for the Common Service Locator.  Finally, with line 4 we provide a lambda that CSL will use to fulfill future requests for services.

Now when our application wants to get an instance of IDb4oConfiguration it just politely asks CSL:

   1: var db4oConfig = ServiceLocator.Current.GetService<IDb4oConfiguration>();

Pretty simple and clean, eh?  Now, when radical group the Foundation for Unity as the Dominate IoC Container sneaks into your cube and forces you at the point of a nerf gun to switch to Unity, you can do so with minimal disruption to your application. With a properly layered application, it would be as simple as coding a new UnityConfiguration layer and then using that instead of your StructureMapConfiguration layer on application startup.

Now, granted this is pretty trivialized example.  There are other ways to solve this problem, but CSL does seem to take are of the grunt work for you so that you can just get going with things.

If you using a unit testing framework such as NUnit, you’re no doubt familiar with the [Ignore] attribute.  (Note:  I haven’t used MbUnit in a while, but I’m pretty sure that all this applies there as well.) For those who aren’t, when you adorn your [Test] with this attribute, then your test runner should pay no heed to this particular [Test].  Instead of going green or red, your test turns up as yellow in your test runner. At first blush, this seems handy – rather than deleting a failing or broken test you can have it [Ignore]d, much like your typical computer geek at a high school dance before the punch get’s spiked. Now you can deal with the wayward test on your own time with the pesky failure cluttering up your CI build (you do have a CI build box set up, right?).

Please bear with me while I submit to you: This isn’t a good idea. This is a bad idea. An ugly idea. The kind of bad, ugly idea than even Belcham-esque quantities of scotch couldn’t make pretty. Why? Well, the whole point to having a unit test is to test something. If your test is failing, that means something is broken.  You should be addressing the cause of the failure and dealing with the problem now. Covering up the failure with some attribute kind of defeats the purpose of having the unit test in the first place. I mean, really, if you had open, festering lesions on your skin would you just cover them up with a band-aid and pretend nothing was wrong?  Odds are you’d go to a doctor and get that checked out.

Alternately, perhaps the test isn’t valid anymore: your application has changed/evolved and the code that you were testing isn’t around anymore. Then, get rid of the test! Delete it from your test fixtures, and don’t look back.

Granted the world we live in is not black and while.  Sometimes we’re working on things, and we only want tests to run when it is explicitly asked to run.  To handle this scenario, NUnit provides the [Explicit] attribute.  This is a kinder, more gentle kind of ignore.  This instructs NUnit to only run the test when it is told to run the test.  If you add a comment to the attribute, then it helps those going through the build log understand why the test is being run.  However it is still possible to run the test if desired.

[Explicit("This test takes a really really really long time to run so we don't want to run it in this test suite every time")]

[Test]

public void My_very_important_test()

{

    // Test valuable things here

}

I know some people are going to protest my advice. So I will offer up this one last piece.  If you are going to [Ignore] a [Test] then please take advantage of the fact that you can add a comment to the Ignore which will show up when NUnit ignores the test:

[Ignore("This test is ignored as I wish to incur the wrath of Cthulhu (or his proxy)")]

[Test]

public void My_very_important_test()

{

    // Test valuable things here.

}

Now when your CI server runs your unit tests, you will have a nice friendly message that will inform others as to why the test is not running.

One of the nice things about Dependency Injection is that it can really help write a more flexible, modular application.  These days, it seems that there is no shortage of choice in the .NET community when it comes to IoC frameworks:

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC.

For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain.

There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator. What is Common Service Locator?  Well, allow me to cut and paste some text from the web site:

“The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.”

Blah blah blah – so what does all that mean?  Well, in my own words, CSL is basically a wrapper around your IoC container which separates how you  initialize/configure your IoC container from how you use it.  This separation allows you to use your IoC container without knowing anything about it.

This separation is achieved by use of adapters for the particular IoC container that you want to use.  These adapters are what do the dirty work of finding the service you need, in their own special way and totally transparent from your application code.  Currently, the Common Service Locator has adapters for StructureMap, Castle Windows, Unity, Spring.NET, and autofac.

Now, allow me an example of using the Common Service Locator with StructureMap. There is no special reason as to why StructureMap – it just happens to be what I find myself using these days.

Now, say I use the the following registry to configure StructureMap:

   1: public class DefaultStructureMapRegistry: Registry

   2: {

   3:     public DefaultStructureMapRegistry()

   4:     {

   5:         ForRequestedType<IDb4oConfiguration>()

   6:             .TheDefaultIsConcreteType<SimpleDb4oConfiguration>();

   7:     }

   8: }

In a nutshell this says that every time StructureMap is asked to provided an object of type IDb4oConfiguration, it should instantiate a SimpleDb4oConfiguration object and return that.  So, to get an instance of IDb4oConfiguration with StructureMap, I would do something like this:

   1: var db4oConfig = ObjectFactory.GetInstance<IDb4oConfiguration>();

Pretty simple, but it does kind of tightly couples me to StructureMap.  If I need/feel like/am forced at gunpoint to change my IoC container to something that is Not StructureMap, you can bet that there will be much wailing and gnashing of teeth on my part as I hunt through my code to make these changes.

Now enter the Common Service Locator.  First, let’s take a peek at some interfaces for CSL.  First an interface:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public interface IServiceLocator : IServiceProvider

   4:     {

   5:         object GetInstance(Type serviceType);

   6:         object GetInstance(Type serviceType, string key);

   7:         IEnumerable<object> GetAllInstances(Type serviceType);

   8:         TService GetInstance<TService>();

   9:         TService GetInstance<TService>(string key);

  10:         IEnumerable<TService> GetAllInstances<TService>();

  11:     }

  12: }

The IServiceLocator is an interface that your application will use when it requests something from your IoC container.

Another thing that CSL provides is a static class that your application would use to use a current IServiceLocator to request services.  That static class looks something like:

   1: namespace Microsoft.Practices.ServiceLocation

   2: {

   3:     public static class ServiceLocator

   4:     {

   5:         public static IServiceLocator Current { get; }

   6:         public static void SetLocatorProvider(ServiceLocatorProvider newProvider) {};

   7:     }

   8: }

So, now lets see how we would request the default implementation of the IDb4oConfiguration service using CSL.  First, we would initialize CSL:

   1: var registry = new DefaultStructureMapRegistry();

   2: var container = new global::StructureMap.Container(registry);

   3: var smServiceLocator = new StructureMapServiceLocator(container);

   4: ServiceLocator.SetLocatorProvider(() => smServiceLocator );

What is going on here? Allow me to provide a quick line by line explanation:

Line 1 we instantiate a new StructureMap registry.  We then feed that registry to a StructureMap container in line 2.  With line 3, we see that StructureMap container is then fed to the StructureMapServiceLocator, which is the SM adapter for the Common Service Locator.  Finally, with line 4 we provide a lambda that CSL will use to fulfill future requests for services.

Now when our application wants to get an instance of IDb4oConfiguration it just politely asks CSL:

   1: var db4oConfig = ServiceLocator.Current.GetService<IDb4oConfiguration>();

Pretty simple and clean, eh?  Now, when radical group the Foundation for Unity as the Dominate IoC Container sneaks into your cube and forces you at the point of a nerf gun to switch to Unity, you can do so with minimal disruption to your application. With a properly layered application, it would be as simple as coding a new UnityConfiguration layer and then using that instead of your StructureMapConfiguration layer on application startup.

Now, granted this is pretty trivialized example.  There are other ways to solve this problem, but CSL does seem to take are of the grunt work for you so that you can just get going with things.

As I was driving home today, I couldn’t help notice something.  Microsoft’s ASP.NET MVC framework is still in beta, and was only announced last October.  To my knowledge, there are currently three projects in the Edmonton area based off this framework.

Castle Monorail has been around for much longer, three years or so?  It’s still listed as a release candidate on it’s website, but I’d say Monorail is suitable for production.  Currently, I am not aware of any projects in the Edmonton that are based off this framework.

I guess this is anecdotal evidence that you won’t get fired for sticking with Microsoft.

The two frameworks have quite a few similarities.  IIRC, in Austin last fall Scott Guthrie did mention that the ASP.NET MVC framework was influenced to some degree by Monorail.

Regardless, it’s good news.  Personally, I like both frameworks, and would prefer either of them to Web Forms.  YMMV.

As most Resharpies know, when you’re using Resharper you can reformat your code. A nice feature is that you can use this reformat code to also organize and layout your code files the way you like it.

For example, Kyle Baley did post on how to how to use the format code to get rid of regions. His techique is a bit unrefined – his revolutionary, dogmatic zeal he will clobber all regions and do nothing else – but still handy.   Myself, I’m a bit more compulsive / fussy when it comes to the layout of my code. Not only do I want regions gone, but I want the code to appear in a certain order. Lucky for me that Reformat Code does this for me. Here is the Type Member Layout pattern I use. If you want to use it, just paste it into the type member layout window in Resharper.

What this will do, when you ask Resharper to Reformat Your Code, is the following: Remove all regions Sort your code, with the following order:

• any COM Interop interfaces
• public delegates
• public enums
• constants (sorted alphabetically)
• fields (sorted with readonly first, and alphabetically)
• static constructors
• constructors
• properties (sorted alphabetically)
• methods (sorted alphabetically)
• anything else (sorted alphabetically)

For the sake of brevity, I’m not giving a detailed breakdown of the Type Member Layout Pattern syntax. Well, brevity and the fact that I’m not 100% certain on a lot of it and don’t want to unintentionally say something wrong. I do believe that the format is pretty straight forward, so you look at it and make your own adjustments.

However, to give you an example. Imagine for a moment that you wanted to surround any interface methods in a #region. First off, don’t tell Kyle. Might be a good idea not to mention it to David Laribee while you’re at it. Secondly, add the following snippet:

<Entry>

  <Match>

    <And Weight="100">

      <Kind Is="member"/>

        <ImplementsInterface/>

    </And>

  </Match>

  <Sort>

    <ImplementsInterface Immediate="true"/>

      <Kind Order="property method"/>

      <Readonly/>

      <Name/>

  </Sort>

  <Group>

    <ImplementsInterface Immediate="true" Region="${ImplementsInterface} Members"/>

  </Group>

</Entry>

What this will do is, for each member of your class that is part of an interface implementation (the whole part), sort it by it’s name (the part), and surround them with a #region (). If you look at my Resharper Patterns with Interfaces sample, you can see by the position with in the element that the interface #region will appear at almost the end of your *.CS file. I hope now that this will appease your inner obsessive compulsive self.