Atlantic Breeze

RavenDB & NServiceBus -

noreply@blogger.com (Sean Kearon) — Thu, 28 Jul 2011 20:17:00 +0000

The upcoming version 3.0 of everyone’s favourite service bus, NServiceBus, will now use RavenDB for saga persistence. This makes it even easier to work with sagas in NSB.

Very cool! Even better than that, it looks like RavenDB will be available for NServiceBus Express users too. You can read Udi’s comment here.

Big thanks to Ayende and Udi for getting these two elegant technologies together like this.

Mocking DbContext Entity Framework 4 Code First CTP5 with NSubstitute

noreply@blogger.com (Sean Kearon) — Sun, 27 Feb 2011 21:07:00 +0000

Take an Entity Framework 4 Code First model, something like this:

   1: public class Customer

   2: {

   3:    public int Id { get; set; }

   4:    public string Name { get; set; }

   5: }

6:

   7: public class CustomerContext : DbContext, ICustomerContext

   8: {

   9:    public DbSet<Customer> Customers { get; set; }

  11: }

I now want to write some tests and I'm going to mock the DbContext using NSubstitute. I first try something like this:

   1: [Test]

   2: public void can_mock_customer_context()

   3: {

   4:    var context = Substitute.For<CustomerContext>();

   5:    context.Customers.Returns(

   6:       new DbSet<Customer>(

   7:          new[]

   8:          {

   9:             new Customer {Name = "Sean"}

  10:          })

  11:       );

  12:    Assert.AreEqual(1, context.Customers.Count());

  13: }

The problem is that the DbSet constructor is internal (as of EF4 Code First CTP5). So, let's abstract our DB access to a simple interface and replace DbSet<T> with the IQueryable<T> interface, ending up with the below:

   1: public interface ICustomerContext

   2: {

   3:    IQueryable<Customer> Customers { get; set; }

   4: }

This interface can be implemented like so:

   1: public class CustomerContext : DbContext, ICustomerContext

   2:   {

   3:      public DbSet<Customer> Customers { get; set; }

   4:      IQueryable<Customer> ICustomerContext.Customers { get { return Customers; } }

   5:   }

Now all we need to do is to use an implementation of IQueryable<T> in our mock. I'm going to use EnumerableQuery<T> which gives me the following test that now passes:

   1: [Test]

   2: public void can_mock_customer_context()

   3: {

   4:    var context = Substitute.For<ICustomerContext>();

   5:    context.Customers.Returns(

   6:       new EnumerableQuery<Customer>(

   7:          new[]

   8:          {

   9:             new Customer {Name = "Sean"}

  10:          })

  11:       );

  12:    Assert.AreEqual(1, context.Customers.Count());

  13: }

  14:    }

I'm new to NSubstitute but it seem to be the lowest friction mocking library out there. Just perfect for use with Entity Framework 4 Code First - certainly the lowest friction ORM there is today!

Note that we could have used the repository pattern to wrap the DbContext instead of a simple interface, the approach is almost identical.

Update: Ro Miller has an alternative approach using fakes that does a better job of surfacing IDbSet. Check it out here: http://romiller.com/2010/09/07/ef-ctp4-tips-tricks-testing-with-fake-dbcontext/.

Package Manager With Source Download

noreply@blogger.com (Sean Kearon) — Thu, 17 Feb 2011 20:05:00 +0000

I was skinning up some code and I used my package manager of choice to add NLog to the project. All good, very easy and away I coded.

The project required a single DLL as an output. So, I thought hey – I’ll use Paul Stovell’s Tape to save using ILMerge in the build. Good plan, but after 5 minutes browsing the NLog source on GitHub it realised I was not sure how to find the version I needed. That’s fine, ILMerge is pretty easy to use so I used the build to save the day.

On the same day (today) I read this post about ReSharper 6 features and suddenly realised how powerful it would be for package managers to be able to give me the source, not just binaries. Now that’s a killer feature and would be even better if the source came with a single file option so I didn’t even have to run Tape.

Oh, please, soon…

A Better Deal

noreply@blogger.com (Sean Kearon) — Thu, 03 Feb 2011 01:19:00 +0000

Red Gate are now going to charge for Lutz Roeder’s Reflector. This tool has been free for it's life – more years than I care to remember. Its as much part of a software developer’s toolkit as a hammer is part of a builder’s toolkit.

I have dealt with Red Gate as part of a very small company and as part of a very large company. I am sorry to say that each time I have come away feeling less than happy. Any company that sends be a maintenance bill at the end of year one that exceeds my original purchase price isn't going to make me happy to deal with them!

Reading Red Gates’ pricing strategy, written by their co-founder, Neil Davidson, I struggle to believe their other CEO, Simon Galbraith, when he says how sorry he is about charging for Reflector. I just kept thinking that they just want my cash - like the other times I’ve dealt with them.

Maybe Galbraith and Davidson should go and listen to Seth Godin’s pricing advice. Maybe then I’d want to buy stuff from them!

35USD is good value for Reflector and I may have to buy a copy. I’d really just rather buy from another company and get a better deal.

Install the Full .Net 4 Framework with Tarma Installer

noreply@blogger.com (Sean Kearon) — Sat, 23 Oct 2010 14:12:00 +0000

If you haven’t seen Tarma InstallMate before, the you need to check this little beauty out. It’s a fully featured installer that have been using it in production for just under a year now and the end-user setup installer just drops out of the end of my build process – sweet!

There’s one thing that is very different with Tarma and all the other installers out there – Tarma doesn’t charge stupid rip-off money like all the other suppliers seem to like to do. You can get their top-of-the-range product for under $90USD per developer. Couple that with totally superb support, rock solid performance and a really rich feature set, Tarma’s a total winner!

Out of the box, Tarma has support for a number of prerequisites like .Net Framework, Access runtimes and Windows Installer. However, it doesn’t differentiate between the Full and Client Profiles for .Net 4 – if the Client Profile is detected then it will not install the full framework and I need to get the full framework onto my user’s machine.

Detecting the Installed Framework Version

To detect which version of the .Net Framework 4 has been installed, you need to check the presence of the following registry keys.

HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client
HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

More details on that here.

We can set up Tarma to do that easily, like this:

Read Registry Key into a Variable

Go to Symbolic Variables and add a new variable called IsFullDotnet4. Then use Tarma’s support for symbolic expressions to read whether the registry key exists by setting the new variable’s value to this:

<$rkaccess(<HKLM>\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full)>

It should now look like this:

Adjust Prerequisites Condition

Go to the prerequisites section and adjust the condition to install the .Net 4 Runtime by setting the condition to this:

NOT IsFullDotnet4

It should look something like this:

That’s all you need – Tarma will now upgrade .Net 4 Client Profile installations to the Full version.

Replacing Strings in XPObject.SetPropertyValue with Lambdas

noreply@blogger.com (Sean Kearon) — Mon, 04 Oct 2010 18:45:00 +0000

I came across a post on Aussie Alf’s blog today about removing magic strings from the persistent property setters in the XPO ORM from DevExpress.

The Aussie Alf blog is written by Michael Proctor who is a member of the DevExpress community DXSquad, specialising in XPO. The blog is a superb resource for any XPO developers and really worth reading. Michael is also a very active member on the DevExpress forums and may well come to your help with an XPO issue there.

XPO uses a classic INotifyPropertyChanged pattern and passes a string of the changed property name into SetPropertyValue method. You can see this below:

 public class Customer : XPObject
{
   private string _number;
   public string Number
   {
      get { return _number; }
      set { SetPropertyValue("Number", ref _number, value); }
   }
}
 

The problem with this approach is that the compiler can’t determine whether the string is correct or not, leaving you open to potential runtime errors. Michael’s solution to this to generate a helper class that can be used in the property setter and he has a Visual Studio plugin that generates and refreshes the helper class for you based on your domain model.

This is a great approach to the problem and you can read more about it on the homepage for Michael’s plugin, XPO_EasyFields.

Michael’s XPO_EasyFields plugin uses the free DXCore Visual Studio plugin from DevExpress. Personally, I use Resharper and don’t have DXCore installed, so I thought I would share my approach to removing the magic strings - I use a helper class and lambdas to do this. It looks like this:

 public class Customer : XPObject
{
   private string _number;
   public string Number
   {
      get { return _number; }
      set { SetPropertyValue(Property<Customer>.Name(x => x.Number), ref _number, value); }
   }
}
 

This relies on the use of a generic Property class and a helper method that gleans the property name from a Linq Expression. The property class looks like this:

 public static class Property<T>
{
   public static string Name(Expression<Func<T, object>> expression)
   {
      if (expression == null) throw new ArgumentNullException("expression");
      if (expression.Body is MemberExpression) return ((MemberExpression)expression.Body).Member.Name;
 
      if (expression.Body is UnaryExpression && ((UnaryExpression)expression.Body).Operand is MemberExpression)
      {
         return ((MemberExpression)((UnaryExpression)expression.Body).Operand).Member.Name;
      }
 
      throw new ArgumentException(string.Format("Could not get property name from expression of type '{0}'",
                                                expression.GetType()));
   }
}
 

The magic comes from translating the little lambda expression x => x.Name to a string. If I remember right, I originally based this on some code from Jeremy Miller, but there are various implementations out there. Here’s and elegant one from Paul Stovell that’s focused purely on INotifyPropertyChanged.

As Paul mentions in the above link, it’s worth noting that there is a performance hit when using this approach. Michael’s approach of generating the code does not have any performance hit. You may need to consider the performance issue if you have very high rates of properties being set.

I did some simple performance tests that show a 10-15x overhead with my approach compared to Michael’s. However, this only becomes relevant with a very large number of property sets. For my usage scenarios the added quality benefit outweighs the performance hit, but you will need to carefully consider your scenario.

Lastly, to take this further, and get an even tighter syntax, I add this helper method to my persistent classes:

 protected void Set<T>(Expression<Func<Customer, object>> property, ref T holder, T value)
{
   SetPropertyValue(Property<Customer>.Name(property), ref holder, value);
}
 

This allows the setter to be even more compact:

 private string _number;
public string Number
{
   get { return _number; }
   set { Set(x => x.Number, ref _number, value); }
}
 

The downside is that you need the helper method in each class. Down to taste that really, but I always go for the tighter syntax wherever possible!

You can get the code from bitbucket and browse the salient parts here.

Sometimes It Just Works

noreply@blogger.com (Sean Kearon) — Thu, 21 Jan 2010 23:11:00 +0000

Some things in life that just do what they say they will do and when this happens you get blown away.

VMware Workstation says it lets you use Visual Studio to debug an application that is running on a virtual machine. I used this recently and was blown away by how easy it was to set up and by how amazingly useful it was.

The story is that I released a new build for informal testing, but it could not be installed. I installed it onto a clean XP VM (yeah, I should have done that already…) and got the error myself. However, there was no error information coming back from the application as the failure was happening before the logging layer was instantiated.

I was stuck. I could reproduce, but had no other information to help. Then I remembered that VMware Workstation had the facility to debug apps running on VMs. So, I followed the instructions (yes, I was desperate enough to read the VMware help file!!) and set up a VM for remote debugging. This was pretty swift to achieve and I then started a debugging session on the VM from Visual Studio.

Almost immediately I could see what was happening: it was my bad – I’d just forgotten to include a third-party assembly with the build. My dev box was happily loading it from the GAC and so I couldn’t see I’d missed anything.

VMware Workstation just did what it said it would do. in doing so, it got me out of a sticky situation. Also, it says it has the ability to record and replay a debugging session…maybe next time, eh?

In the meantime, and whilst loving the things that go right, here’s a shot of the error from VS debugging on the VM:

Friendly OS Name from WMI

noreply@blogger.com (Sean Kearon) — Thu, 07 Jan 2010 19:24:00 +0000

When you want to find out what operating system your application is running on, System.Environment.OSVersion is not very readable. You can get a nice friendly name using WMI like this:

  1: private static string GetOSName()
  2: {
  3:    const string query = "SELECT * FROM Win32_OperatingSystem";
  4:    var searcher = new ManagementObjectSearcher(query);
  5:    var results = from x in searcher.Get().OfType<ManagementObject>()
  6:            select x.GetPropertyValue("Caption");
  7:    return results.Any() ? results.First().ToString() : "Unknown";
  8: }

This will give you something like "Microsoft® Windows Server® 2008 Enterprise ".

Cloud Computing – SMD Services

noreply@blogger.com (Sean Kearon) — Sat, 18 Apr 2009 08:10:00 +0000

Rinat Abdullin has recently put up an interesting post about cloud computing, along with another post as a response to a comment of mine. Rinat pointed out the benefits cloud scenarios bring when there is a need for distributed computing resources, highlighting Amazon’s recent announcement along with Microsoft’s offerings in that space.

I agree with Rinat that distributed computing scenarios are clearly winners for cloud computing. However, my view is that one of the critical success factors for the success of cloud computing will be developer adoption. If you have developers using your product it will succeed (as a cloud platform), if you don’t then…well, you get it! My view is that the larger organisations who already have their own infrastructure will certainly adopt cloud resources, but it will not be these organisation that will drive the adoption of cloud technologies. It will be the small to medium enterprises (SME) for whom the effort to host themselves is a large compared to their overall effort to stay in business.

What is going to drive SME uptake – having software that delivers business advantage. How does this get to them – by developers producing it for them. Making your cloud platform accessible and usable for developers will drive wider adoption.

In Rinat’s second post he mentions a scenario where if he had had a cloud platform like Azure available, cost could have been saved. He also outlines the basis for how cloud computing will reduce the overall costs of the adoption of a the provided in the cloud – the larger data centres selling their idle CPU cycles.

He then points out that there is fast evolving market for hosted developer environments where you can easily and cheaply access version control, wiki, issue tracker services, etc. In an earlier post I mentioned one such provider, WUSH, with whom I have had a positive experience throughout the last year in the smaller scale development work I do out of normal working hours.

It is this area – developer services – that I see as the key to making cloud computing ubiquitous. If you can provide developers with full-lifecycle support from your platform they will come in their droves. By full lifecycle, I mean support for planning, production, test and live all in an integrated set of cloud services.

As mentioned, there we see some support for planning and some aspects of production already out there (search for “hosted subversion”, take a look at Scrumy or Manymoon, etc.), and you can but cost efficient test and live environments (by renting your own server). But to get other aspects running, like a build or CI environment, involves setting it up yourself on a server you have rented yourself. However, doing that would not be using SaaS beyond having a server hosted in the cloud. Unfortunately, I know of no decently priced build service that for commercial projects.

What do I want to see? In the short term, I’m missing a ~~sensibly~~ cheaply priced build services for commercial projects (see James Kovac’s recent announcement of their new Team City service for OS projects). In the longer term I want to be able to have a fully hosted CI environment that prices me by disk and CPU usage.

The ultimate goal: Microsoft to host TFS and reduce the cost of adoption for SMDs (small to medium developers :) ) to the Team System versions of Visual Studio.

In the meantime, will I be using the current set of cloud services? Absolutely, both in my production processes as an SMD and for services that my clients will use. And, I am doing this for the the reasons Rinat has outlined!

Double Click to Open Visual Studio Solutions in Vista/2008

noreply@blogger.com (Sean Kearon) — Mon, 15 Dec 2008 20:15:00 +0000

For a while I have been running Visual Studio under Vista (x32) and now I’m using Workstation 2008 (very happily too!). I have UAC on, but have a policy setting to automatically elevate without showing a prompt. (I absolutely can’t live with the dialogs…see here and here for more info).

I have also Visual Studio set to run as administrator, and that’s where the problem starts: I have not been able to open solution files by double clicking them.

I am very grateful to “Sajeev Prasad / Arun Arcot” response to this post for the solution.

Basically, set both IDE and the loader (%programfiles%\Common Files\Microsoft Shared\MSEnv\VSLauncher.exe) to run as administrator and you can then double click to open solutions.

Thanks Sajeev and Arun!

ReSharper Plugins

noreply@blogger.com (Sean Kearon) — Mon, 15 Dec 2008 01:17:00 +0000

I’ve been using ReSharper since it’s first EAP release (late 2003 or early 2004, if I am right) and quite simply would not want to code without it.

ReSharper is a platform that can be easily extended and it is worth noting that there are a number of excellent plugins available that to make your ReSharper experience even better.

I mentioned Scout in an earlier post, but there are plugins for NHibernate, Gallio, xUnit and also for stuff like helping extract resources for internationalisation.

Check here for more details.

XML Editor - Liquid XML Studio

noreply@blogger.com (Sean Kearon) — Mon, 15 Dec 2008 00:44:00 +0000

I’ve just started using a great XML editor: Liquid XML Studio. I used it when creating some XSDs the other day. It’s really easy to use, and has a great graphical interface too.

The thing I really really like is the feature to generate an instance of the schema. The only other tool I’m aware of that does this is the BizTalk schema editor – but that’s a bit more of a heavyweight tool than I usually need!

It also has Visual Studio integration (with the visual editor), XPath expression builder, documentation generation and a web service browser. It’s not cheap, but there is a free feature limited Community Edition. There’s also the high end Developer Edition that adds a load of muscle for people working with more complex schemas, such as the OASIS schemas.

Joyful Reflections - ReSharper Scout

noreply@blogger.com (Sean Kearon) — Mon, 15 Dec 2008 00:21:00 +0000

I’ve just found an excellent ReSharper plugin called Scout. This lovely little beast will open Reflector when you choose Go to Declaration. The thing I really love is that Scout also takes care of loading the appropriate assembly in Reflector. I previously had to load the assembly in Reflector before I could browse it, which took time. Scout makes this process seamless.

All you have to do is right click and select Go to Declaration:

Then you get taken to the item in Reflector and the correct assembly is loaded:

Scout will also take you to the Dotnet source code – but I haven’t got around to that yet! You can find lots of other ReSharper plugin goodness here.

Update on XPO and One-Way Associations

noreply@blogger.com (Sean Kearon) — Sat, 29 Nov 2008 07:12:00 +0000

I stated in a previous post that XPO would be supporting one-way multi associations. Unfortunately, this is now not the case. At the time I wrote the previous post, Developer Express had marked my request as accepted, but have now changed that to rejected.

The guys at Developer Express support say that having a two-way association in your object model is fundamental to XPO multiple associations and, as my request was only to simplify code, the feature is now not to be implemented. The bottom line from them was:

"To sum it up, we think that the current design of one-to-many associations in XPO is reliable and transparent. We are not going to change it, unless we have strong arguments for doing so."

Well, although it's a shame that it's not going to be implemented, you can't argue than that!

You can find the request thread here (but may need to register). If you still want to keep your XPO code clean, you can use some IL enhancement with PostSharp - details here.

Why Support One-Way Multiple Associations?

noreply@blogger.com (Sean Kearon) — Thu, 20 Nov 2008 08:09:00 +0000

This post is to answer a question from the Developer Express support team as to why I have requested that XPO support one-way multiple associations. The primary reason for my request is to reduce code noise. When you do not want a reverse association in your model, then you should not be forced to put it in. Using the example from my previous post, if all you need is a one-way association you should be able to write:

public class Customer : XPObject

{

    public XPCollection Orders { get; }

}

  public class Order : XPObject

{

}

However, as XPO currently requires you to implement a two-way association in your object model. You have to write something like this:

  public class Customer : XPObject

{

    [Association("CustomerOrders")]

    public XPCollection Orders { get; }

}

  public class Order : XPObject

{

    [Association("CustomerOrders")]

    public Customer Customer;

}

XPO has made me:

Add an attribute to my association property.
Give that attribute a unique string to identify the association.
Add a new property to my linked type.
Add an attribute to this new property.
Give this attribute the same string so as to identify it is part of the association.

I have no problem with doing that when I need the association to be two-way. Indeed, XPO does some good things for me when I do need this: it maintains the linked states of the linked instances, which is a great help! In other words, when the Association attribute is used as above, adding an order to a customer's orders will automatically set the order's customer; removing the customer from the order's customer property will remove the order from the customer's orders property. Very nice to have and certainly removes code that I would need to write.

You are probably looking at the above example and thinking that you would naturally have an association from order to customer, and I would agree. However, let's say that you have a requirement to show the recently ordered products against the customer. One way of implementing this would be:

public class Customer : XPObject

{

    public XPCollection RecentProducts { get; }

}

In this circumstance, I would not want to have to implement a reverse association:

     public class Customer : XPObject

{

          [Association("CustomerRecentProducts")]

             public XPCollection RecentProducts { get; }

}

  public class Product : XPObject

{

          [Association("CustomerRecentProducts")]

             public XPCollection Customers { get; }

}

In this case I would consider the reverse association to be worse than code noise - it is structurally worng and simply should not be there! Maybe we should be suspicious of the Customer.RecentProducts association in the first place too, but that's another story!

Another time when being forced to implement a reverse association is when the two classes are in different assemblies. I would have to move the classes to avoind a circular reference. Maybe I should ask for XPO to support persistence by interface too...

Express Persistent Objects (XPO) to Support One-Way Multiple Associations

noreply@blogger.com (Sean Kearon) — Mon, 10 Nov 2008 07:49:00 +0000

Update December 2008: this has changed and is no longer to be supported. See here for details.

I'm happy to say that Developer Express have now accepted my request to support one-way multiple associations in XPO. See here for more details.

Using PostSharp to Allow One-Way Multiple Associations in XPO

noreply@blogger.com (Sean Kearon) — Fri, 31 Oct 2008 00:04:00 +0000

The Express Persistent Objects (XPO) ORM from Developer Express does not support one way associations with multiplicity greater than one. Each collection association from a type must have a corresponding reverse association from the linked type. The reverse link can be either a unary or a collection (making either a one-many or many-many association, respectively).

I put in a request for one-way multi associations here (you may need to register to view). The response I got back was basically that implementing one-way multi associations would "break existing functionality and this approach contradicts with the XPO concepts". I think that this is a shame, but there you go.

So, given that I want this feature, I'm going to find the middle ground: let's have one-way associations, but use PostSharp to implement the extra code to keep XPO happy.

The Problem:
I want to be able to write this as valid XPO code:

   public class Customer : XPObject
   {
      public XPCollection Orders { get; }
   }

   public class Order : XPObject
   {
   }

But XPO wants me to add the other end of the link to Order and to also add associated attributes:

   public class Customer : XPObject
   {
      [Association("CustomerOrders")]
      public XPCollection Orders { get; }
   }

   public class Order : XPObject
   {
      [Association("CustomerOrders")]
      public Customer Customer;
   }

So, for my one-way association there must be another property or field on the linked class as well as marking each participting property(or field with the Association attribute. Not a huge amount of extra code and not an unreasonable amount either!

(Also, it's worth noting here that I am again using PostSharp to let me use automatic properties with XPO here - there is a little more required for normal XPO code. See my previous posts for more details on how this is done.)

A Solution:
We're going to use PostSharp to generate the reverse link for us and to add the associations that XPO requires. Basically, I am going to write code as in the first section above and get PostSharp to enhance it at compile time so that it is actually like the second section. Specifically, I'm going to use PostSharp to:

Add a public field to a class.
Add an attribute to this new field.
Add an attribute to an existing property.

Some Caveats:
If you care about the reverse link, you will want to implement it yourself as is usual in XPO. The way we are doing it here means that the generated reverse link will not be visible at design time from inside of its own assembly (but it will be from outside the assembly).

Also, the current implementation is not compatible with the Compact Framework or Silverlight. For this you will need to use the upcoming version 1.5 of PostSharp - more details here.

Approach
As you will see from the PostSharp web site, PostSharp is made up of two main sections - PostSharp.Core and PostSharp.Laos. PostSharp.Laos is a plugin on top of PostSharp.Core that simplifies a lot of the common tasks in AOP. PostSharp.Core is the main engine that enchances your code at compile time. It is both powerful and deep, and I am certainly not an expert in its use! However, despite all the power and depth, it is also fairly accesssible.

The PostSharp website uses the lovely term "Pay-As-You-Use Complexity" for PostSharp - you can acheive pretty much anything you want and the common tasks are made fairly simple (by PostSharp.Laos), while other tasks may require you to gain some more knowledge of the inner workings of PostSharp (meaning PostSharp.Core). In my previous articles about PostSharp, we used PostSharp.Laos, for this task we are going to use PostSharp.Core.

In this article, I'm going to show how to add fields and attributes to classes using PostSharp.Core. I was inspired by Ruurd Boeke's articles, which you can find here. Ruurd uses PostSharp to enchance POCO classes for the Entity Framework use and goes a lot further with PostSharp than I do here. I highly recommend reading Ruurd's articles for more detailed information.

Let's now have a look what we need to do to get PostSharp to do what we want. I'm going to break this down into three sections:

Stage 1 - Attach Aspects

Stage 2 - Create a Weaver Task

Stage 3 - Do the Weaving

Stage 1 - Attach Aspects
The first step is to create a CompoundAspect as we have done before. The job of this attribute is going to be to add other PostSharp aspects to our classes. The other aspects will then be picked up and used by PostSharp.Core. The ProvideAspects method looks like this:

1 public override void ProvideAspects(

    object element, 

    LaosReflectionAspectCollection collection)

2 {

3     var targetType = (Type) element;

4      foreach (var property in targetType.UnderlyingSystemType

         .GetProperties()

         .Where(info => info.DeclaredIn(targetType) &&

                info.IsOneWayAssociation()))

5    {

6      var fieldName = GetGeneratedFieldName(property);

7      collection.AddAspect(

         property.GetCollectionTargetType(),

         new OtherEndFieldSubAspect(

           targetType.FullName,

           fieldName,

           fieldName));

8

9      collection.AddAspect(

         targetType, 

         new AssociationAttributeSubAspect(

           property.Name, 

           fieldName));

10    }

11 }

In line 4 we use a bit of LINQ to iterate through the properties of our target type that we are interested in enchancing and then in line 6 we call a helper method to get the name of the field we want to generate. In lines 7 and 9 we add the aspects. In line 7 we add an aspect to the type at the other end of our collection and pass it the name of the type of the field we want to add, along with a field name and a string to be passed to the association attribute that we will add later. Note that we are using an extension method helper (GetCollectionTargetType) to get the type at the other end, although this is nothing more than normal reflection code. Next, in line 9, we add another aspect to the type that is declaring the collection property, passing it the name of the property that will be enchaned and a string that we will pass to the attribute that we add to the property.

So, we have used PostSharp.Laos to add aspects to our classes. These aspects contain some information that we will use later. In fact, as you can see below, the aspects that we have added contain little else other than the information we want to use later.

public class OtherEndFieldSubAspect : ILaosTypeLevelAspect

{

   public OtherEndFieldSubAspect(

     string fieldTypeName, 

     string fieldName, 

     string associationName)

   {

      FieldTypeName = fieldTypeName;

      FieldName = fieldName;

      AssociationName = associationName;

   }

   public void CompileTimeInitialize(Type type) {   }

   public bool CompileTimeValidate(Type type)

   {

      return true;

   }

   public void RuntimeInitialize(Type type) { }

   public int AspectPriority

   {

      get { return int.MinValue; }

   }

   public string AssociationName { get; set; }

   public string FieldName { get; set; }

   public string FieldTypeName { get; set; }

}

public class AssociationAttributeSubAspect : ILaosTypeLevelAspect
{
   public AssociationAttributeSubAspect(
     string propertyName, string associationName)
   {
      PropertyName = propertyName;
      AssociationName = associationName;
   }

   public void CompileTimeInitialize(Type type)    { }

   public bool CompileTimeValidate(Type type)
   {
      return true;
   }

   public void RuntimeInitialize(Type type) { }

   public int AspectPriority
   {
      get { return int.MinValue; }
   }

   public string AssociationName { get; set; }
   public string FieldName { get; set; }
   public string PropertyName { get; set; }
}

Note that these tasks implement ILaosTypeLevelAspect as we are applying the aspects to types.

Stage 2 - Create a Weaver Task

PostSharp's weaver is what we are going to use to create the new field and add the custom attributes. The public parts of PostSharp are LGPL and can therefore be freely distributed under any license you choose, whereas PostSharp.Core is licensed under the copyleft GPL, and so you cannot distribute PostSharp.Core in another GPL application. So, if we want to use this commercially, the weaver needs to be split out from the main distribution if the software is going to be used commercially. This is not a problem as the enhancements happen at compile time and the designer of PostSharp, Gael Fratieur has made this easy for us to seperate PostSharp.Core! The basis of this is to use PostSharp "tasks" to tell PostSharp.Core what to do at compile time. A task has a name and points to a weaver implementation that will handle the task. You configure the tasks in XML as below:

            Implementation="Weaver.WeaverFactory, Weaver">

The task called WeaveTwoWayAssociations is handled by the type Weaver.WeaverFactory which can be found in the assembly called Weaver. This file and the rest of the weaver code sits in a seperate project. Other projects find this by adding the weaver to the search path and adding an assembly level attribute to the project where we defined our AssociationAttributeSubAspect and OtherEndFieldSubAspect aspects. We also add the weaver project's output folder to each referencing projects search path (inside project | properties). The assembly attribute looks like this:

[assembly: PostSharp.Extensibility.ReferencingAssembliesRequirePostSharp("WeaveTwoWayAssociations", "Weaver")]

[assembly: InternalsVisibleTo("Weaver")]

Note that the task name and the assembly in which it can be found are indicated. We also have to allow the weaver to reference our internals! Also, note that PostSharp has another, more portable, mechanism to tell reference the weaver files, as described in Ruurd's article. For whatever reason, I could not get this to work and so have just added the reference path. You will need to change this path on your machine or you will get compile errors about not being able to find a plugin:

Okay, so we've now got a task setup to let PostSharp's weaver loose on our aspects. We now just need to define what the weaver needs to do.

Stage 3 - Do the Weaving
In our configuration we said that the task called WeaveTwoWayAssociations was handled by the class Weaver.WeaverFactory. WeaverFactory implements ILaosAspectWeaverFactory and looks like this:

public class WeaverFactory : Task, ILaosAspectWeaverFactory
{
public LaosAspectWeaver CreateAspectWeaver(ILaosAspect aspect)
{
     if (aspect is OtherEndFieldSubAspect)
     {
        var addField = (OtherEndFieldSubAspect)aspect;
        return new AddFieldWeaver(
addField.FieldTypeName,
          addField.FieldName,
          addField.AssociationName);
     }

     if (aspect is AssociationAttributeSubAspect)
     {
        var addAttribute = (AssociationAttributeSubAspect)aspect;
        return new PropertyAttributeWeaver(
          addAttribute.PropertyName,
          addAttribute.AssociationName);
     }
     return null;
}
}

Ttrue to its name, the factory is responsible for providing instances of types that can do some work for us. Note that the factory is looking for the aspects that we added in stage 1. When a OtherEndFieldSubAspect is encountered, an instance of AddFieldWeaver is created and returned to PostSharp. When a AssociationAttributeSubAspect is encountered, an instance of PropertyAttributeWeaver is created and returned to PostSharp.

So, as indicated above, the work of adding a field is done by the AddFieldWeaver class. You might be expecting this class to be pretty complex and have lots of IL in it. If you are, you're in for a surprise as it's actually really clean and straight forward:

public class AddFieldWeaver : TypeLevelAspectWeaver

{

   public AddFieldWeaver(

     string fieldTypeName, string fieldName, 

     string associationName)

   {

      FieldTypeName = fieldTypeName;

      FieldName = fieldName;

      AssociationName = associationName;

   }

   private ITypeSignature fieldType;

   public override void Implement()

   {

      var newField =

        new FieldDefDeclaration

          {

            Name = FieldName, 

            Attributes = FieldAttributes.Public, 

            FieldType = FieldType 

          };

      ((TypeDefDeclaration) TargetType).Fields.Add(newField);

      var attribute = Utils.CreateAssociationAttribute(

        Task.Project.Module, AssociationName);

        newField.CustomAttributes.Add(attribute);

   }

   public string AssociationName { get; set; }

   public ITypeSignature FieldType

   {

      get

      {

         if (fieldType == null)

         {

            fieldType =

              Task.Project.Module.FindType(

                FieldTypeName, 

                BindingOptions.Default);

         }

         return fieldType;

      }

   }

   public string FieldTypeName { get; set; }

   private string FieldName { get; set; }

}

The waever is an implementation of the PostSharp TypeLevelAspectWeaver and its Implement method is where the new field is created. This method simply creates a new FieldDefDeclaration that represents the new field, sets its name, defines its visibility (by setting the Attributes property) and sets it's type. The type is derived from a helper property called FieldType which uses PostSharp's built in Task.Project.Module to find the type of the name that was specified when we created the attribute in stage 1.
Then, the new field is simply added to the target type's fields collection. Next, a helper method is called to create an instance of the custom attribute we want to add and is added to teh new field's custom attributes collection. That's all there is to it!!!

PostSharp has been widely praised for having a very clean and well designed API. After doing this I can really see why it is so well thought of - we have been sheltered from all the horrid IL generation that is usually associated with this sort of task. Quite simply, PostSharp totally rocks and Gael Fraiteur has done an amazing job!

The Results
So, what do we have now? If you remeber, we started with types that looked like this:

[AllowXpoOneWayAssociations]
public class Customer : XPObject
{
public XPCollection Orders { get; }
}

[AllowXpoOneWayAssociations]
public class Order : XPObject
{
}

If we now look at the assembly in Reflector, we can see that a public field along with an custom attribute has been added to Order and an attribute has been added to Customer:

Back to XPO
So, most of the above has been about PostSharp. Specific to XPO, the custom attribute I have added is the AssociationAttribute required by XPO to link the two sides of the association. So, I started with a one-way association and have used PostSharp to magically turn that into a two-way one-many association.

If you want the code, you can get it from here. Note that I've put up the XPO version and a version that doesn't require XPO.

Update: I've edited this to show that the XPCollection were the generic XPCollection 12-Nov-2008.

Using C# Automatic Properties with XPO Objects - Part 2

noreply@blogger.com (Sean Kearon) — Mon, 27 Oct 2008 20:22:00 +0000

In part 1 we looked at how XPO implements change tracking by utilising some magic from the base XPObject class. An XPO object looked something like this:

public class Customer: XPObject

{

  private DateTime date;

  public DateTime Date

{

    get { return date; }

    set { SetPropertyValue("Date", ref date, value); }

}

[Association("CustomerOrders", typeof(Order))]
public XPCollection<Order> Orders
{
get { return GetCollection<Order>("Orders"); }
}
}

Wanting to cut down on the syntatic noise, I'd like to be able to use C# automatic properties to make my classes to look like this:

[XpoAutomaticProperties]
public class Customer: XPObject

{

  public DateTime Date { get; set; }

[Association("CustomerOrders", typeof(Order))]
public XPCollection<Order> Orders
{
get; private set;
}
}

The secret here is the XpoAutomaticProperties attribute and the work that this does. Applying this attribute to the class makes two things happen:

Changing a property value will raise the changed notification events.
Accessing a collection will instantiate and set up the collection.

XPO objects notify observers of changesto values using a changed event. Collections have similar events events are fired when the collection changes or when an item in the collection changes. Note also that the GetCollection method above sets up the collection so that it is aware of being a property of a containing object. This will also be handled by the attribute.

Along with the XpoAutomaticProperties attribute, there is one other thing that is introduced. The SetPropertyValue call is responsible for firing the changed event. I will introduce to allow me to call back to an object to instruct it to notify observers of changes (XPObject has exactly such a method). The interface looks like this:

public interface IPropertyChangedNotifier

{

  void OnChanged(

    string propertyName, 

    object oldValue, 

    object newValue);

}

Okay, if you've got this far, you must be wondering how do we actually do this? The answer is that we use the incredible PostSharp to help us add the required code we need into our objects. PostSharp is an aspect oriented programming (AOP) library and toolset that makes it easy to add code into your objects during compilation. As the changes occur at compile time, you avoid the runtime performance hits that would come from using reflection.

PostSharp makes the process of generating and adding IL code to your assemblies at compile time ridiculously easy to acheive for such a complex task. Although PostSharp allows you to drop down and weave any IL code you like into your assemblies, there is a The PostSharp website has a number of excellent examples of how to work with PostSharp, which are extremely impressive and worth checking out. It is also very well documented. PostSharp is an open source library that is free even for commercial use and, incredibly, is the work of one man: Gael Fraiteur. Everything that we do here is based on the excellent examples that Gael provides with PostSharp, so check those out when you can.

From this point on, I am going to assume that you have some knowledge of AOP and PostSharp. So, back to the XpoAutomaticProperties attribute and how this works. The attribute is a PostSharp attribute in which you override a base method to do the work. The method looks like:

public override void ProvideAspects(

  object targetElement, 

  LaosReflectionAspectCollection collection)

Inside this method you use reflection to interrogate the properties of the type and then add some code to that property like this:

1 if (property.CanWrite && property.CanRead && !property.IsCollection())

{

  var setMethod = property.GetSetMethod(true);

  if (!setMethod.IsStatic)

  {

6      var aspect = new PropertyChangedNotifierSubAspect(

                    this, property.Name);

7      collection.AddAspect(setMethod, aspect);

8   }

9 }

Remember that all this code is firing at compile time so the reflection will not affect your runtime performance! So, in line 1 we check that the property (a PropertyInfo) is read-write and is not a collection. We then use reflection to access the property's setter in line 3 and check that we are not looking at a static property in line 4. In line 6 we create a new PostSharp aspect - the PropertyChangedNotifierSubAspect - and add it to the collection that PostSharp supplies. Note that the name of the property is passed in to the aspect's constructor - this is how we avoid the use of string literals for property names. After this, PostSharp does all the work for you. Well, PostSharp does the IL weaving for you, there's still a little more for us to do.

The PropertyChangedNotifierSubAspect decends from the built in PostSharp type OnMethodBoundaryAspect. This allows you to easily acheive a number of things when a method is called in your code. We use two of these to change the property's setter: first we store the old value when the setter is entered, then when the setter method completes we determine if the value has changed and fire the changed event accordingly. PostSharp elegantly provides us methods that we can override to achieve all this - we never even have to leave C# or think about IL. This is how we store the existing value when we enter the property's setter:

1 public override void OnEntry(MethodExecutionEventArgs eventArgs)

{

  base.OnEntry(eventArgs);

  var instance = (XPBaseObject) eventArgs.Instance;

  oldValue = instance.GetMemberValue(propertyName);

}

We simply override the base class method and use the data supplied argument's to access the object whose property has changed. We cast it to be an XPBaseObject and use the GetMemberValue to access and store the value of the property on entry. Note here that the GetMemberValue is supplied by Developer Express and is performance efficient (itself using generated IL to access the property value). If you are using XPO with your own objects that do not subclass the built in XPO types then you will have to use reflection or some other means to access the entry value. Note also that this code is executes at runtime.

In a similar manner, we then override the OnSuccess method to execute code when the method successfully completes (i.e. exiting with no unhandled exceptions). At this stage, we compare the current value with the existing and fire the changed event if needed. The code looks like:

1 public override void OnSuccess(MethodExecutionEventArgs eventArgs)

2 {

3    if (!(eventArgs.Instance is IPropertyChangedNotifier)) return;

4    var newValue = eventArgs.GetReadOnlyArgumentArray()[0];

5    if (ValuesEqual(oldValue, newValue)) return;

6    var instance = (IPropertyChangedNotifier) eventArgs.Instance;

7    instance.OnChanged(propertyName, oldValue, newValue);

8 }

Again, PostSharp supplies us with event args that allow easy access to values. We also use our IPropertyChangedNotifier interface to do the notification. In line 4 we access the new property value from the event arguments supplied by PostSharp (again, no reflection needed!) then call a method to check for changes in line 5. If we have a change to the property, we instruct the object to notify the world of the change in lines 6 and 7.

Okay, so where are we now? We've used PostSharp to create a special attribute. We've applied the attribute to the classes in which we want to use automatic properties. PostSharp recognises our attribute and injects code into our assemblies at compile time. The code that is injected is defined by us in classes that we create from buit in PostSharp types. These types are called aspects and we used the one that allows us to modify a method - specifically, the property's setter method. To modify the method was pretty easy - we just override a couple of methods and use the information that PostSharp passes back to us to do what we want.

PostShapr also allows you to work with fields and add code to when the fields are accessed. The way I initialise collections use this feature of PostSharp, but I'd suggest you head for the PostSharp site to learn more of what you can do with PostSharp.

Before we leave this, there's one gotcha to be aware of: the release version of PostSharp, 1.0, does not play well in partial trust scenarios. If this is important to you then you'll be pleased to know that the next release 1.5 addresses this and version 1.5 is in CTP2 stage at time of writing.

If you want more, then you can get the code from here.

Using C# Automatic Properties with XPO Objects - Part 1

noreply@blogger.com (Sean Kearon) — Sun, 26 Oct 2008 11:50:00 +0000

In my previous post I touched on the fact that objects in Express Persistent Objects (XPO) support change tracking. One area that this is used by their Unit of Work to track the changes made to objects. Another use is when data binding objects to a UI. So, how do you enable change tracking in your object model using XPO?

XPO supports a variety of methods for achieving this, but the easiest is to inherit your domain objects from XPObject. When you do this change tracking is enabled by calling a magic setter method in your property setters and using their built-in collection type for association properties:

public class Customer: XPObject 

{

  private DateTime date;

  public DateTime Date

{

    get { return date; }

    set

    {

      SetPropertyValue("Date", ref date, value);

    }

}

  [Association("CustomerOrders", typeof(Order))]  

  public XPCollection<Order> Orders 

{

    get { return GetCollection<Order>("Orders"); } 

  }

}

Note that Association attribute on the collection property is required by XPO and indicates that the property is one end of a two-way association - either one-many or many-many. Associations are always two-way, except one-one associations which are handled differently. So, for completeness, with the example above being a one-many relationship, you will need the following to express the other end:

public class Order: XPObject 

{

  private Customer customer;

  [Association("CustomerOrders")]

  public Customer Customer

{

    get { return customer; } 

set

{

      SetPropertyValue("Customer", ref customer, value); 

}

}

}

It makes sense to use a collection type that supports change notification and the calls to SetPropertyValue are a fairly elegant way to notify change. Okay, this is all good, but I like to cut down the syntactic noise as far as possible. This basically means that I want to to use C# automatic properties (and I also don't want get into using design time code generation techniques to help me out). So, where do we go from here? We go to this:

[XpoAutomaticProperties]

public class Customer: XPObject 

{

  public DateTime Date { get; set; }

   [Association("CustomerOrders", typeof(Order))] 

  public XPCollection<Order> Orders 

{

    get; private set; 

}

}

[XpoAutomaticProperties]

public class Order: XPObject 

{

  [Association("CustomerOrders")] 

  public Customer Customer 

{

    get; private set; 

}

}

The classes above will give the same functionality - change tracking and collection creation - as the previous examples. Except, there is much less code to read, just automatic properties and an extra attribute on the class declaration. Take a look at part 2 to see how this can be done.

ORM with Developer Express Persistent Objects (XPO)

noreply@blogger.com (Sean Kearon) — Fri, 24 Oct 2008 10:33:00 +0000

I've been using ORMs for a long while now and love the speed and flexibility they can bring to the development process. For projects in work we use an ORM that we wrote ourselves. As I'm now doing some projects outside of my day job, I have been looking around at the available ORM offerings for a few months now. I'm now pretty likely to be using Express Persistent Objects (XPO) from Developer Express - a developer tool vendor with an excellent reputation and strong background.

I've been evaluating their UI controls for a while now and I have been generally very impressed with both their products and their excellent support. XPO comes from this background and has the main features that I want:

Support for the Compact Framework.
A LINQ provider.
Generation of schema from object definitions (you can also generate objects from an existing schema).
Wide support for a variety of databases (including my target database, VistaDB).
Easy data binding of objects to controls (as you'd expect from DevExpress!).

It does have a few quirks that I'm a little unsure about at the moment. The main ones for me now are:

All associations with multiplicity greater than one have to be two-way.
The automatic schema generation mechanism will not widen string fields in existing schemas.

I also get the feeling from reading their forums that XPO gets a "little less love" than some of their other products. I think that it may be seen as either largely functionally complete, or that it now plays a supporting role to their application framework, XAF.

However, these are only small niggles and the product is seems to be well constructed, uses best practices, has good support from a much respected tool vendor and is realistically priced. If you are coming to ORM from a data-driven background, then you will probably even be comfortable with having to always having to have have two sides to an association! It is worth noting that XPO takes care of the other end of the relationship for you - if I add an order to a customer, then the order's customer is automatically set...neat and sweet!

If you are looking for an easy to use commercial ORM that is reasonably priced, then I would recommend you take a look. If you are not looking for a non-commercial ORM, or want to learn about the world of object-relational mapping, then head off to NHibernate.

Edit: Just thought it worth noting that the "small niggles" about XPO are in the context of my current project, which has a relatively simple object model - one for which I would happily manually write the data access code. I would not be comfortable recommending XPO for complex object models at this stage.

Praise: Subversion Hosting at Wush.net

noreply@blogger.com (Sean Kearon) — Thu, 26 Jun 2008 19:51:00 +0000

I've recently signed up for Subversion hosting with Wush. I spent a long time looking at various online providers before deciding on Wush. I am more than happy with my choice!

I currently have a no-frills service with a gigabyte of space with unlimited users across a single Subversion repository for $20USD per quarter at time of writing. (You can add extra Subversion repositories for $5USD.)

Hey, I don't want frills, I want service and Wush have given me absolutely top class service! Their service started when I was asking initial questions and has continued through my teething problems (like not remembering how to set up other users; how to integrate with FogBugz, etc.).

There are a lot of good looking offerings out there with some very slick interfaces. However, these often took, literally, days to respond to my support requests. Sorry - not good enough!!

Wush does not have a slick interface but has a strong, consistent and solid level of support from the start.

When a job's done right, you have to say so: Wush have to be one of the best out there and I wholeheartedly recommend them!

ECO VistaDB Provider on CodePlex

noreply@blogger.com (Sean Kearon) — Mon, 23 Jun 2008 23:30:00 +0000

I've put the code for the ECO VistaDB Provider up on CodePlex. Get if from:

http://www.codeplex.com/ecovistadbprovider

I'd be very interested to hear of any experiences if you use it!

Flintstone Machine: Enterprise Integration Pattern

noreply@blogger.com (Sean Kearon) — Sun, 22 Jun 2008 09:37:00 +0000

In the Flintstones cartoon, the "modern stone age" families used used machines that were functionally equivalent to the contemporary household utility appliances, but were powered by animals inside. For example, in the recent film, their garbage collector chute leads to a pig in the cupboard that eats all the waste food.

In enterprise IT systems we find similar things: systems that hand off work to a human worker when that work could be accomplished by the system or passed to another system. The worker becomes the equivalent of the animals inside the Flintstones' machines.

The key feature is that the task the worker performs could be done, in whole or in part by software; indicating areas where greater operational efficiencies may be achieved. Of course, it does not indicate that there is a cost benefit to making the change!

This can make sense as a temporary step on the journey toward greater integration. To keep your promises, you might roll out your online ordering system to the world and start taking orders today, before you can bring the warehousing system to the party. You have a team of people working like hell to take the orders to the warehouse and update the stock levels. The warehousing integration rolls out later.

The enterprise system is like a swan, the surface is all graceful and efficient, while the legs are working like hell to move things along!

Also see: Swivel Chair Integration

UAC: Peace at Last

noreply@blogger.com (Sean Kearon) — Thu, 19 Jun 2008 20:53:00 +0000

Caveat: do not try this at home unless you understand and are willing to accept the reduced security. Read the comments in the link below for more details.

That said, I've found some valium for the soul! The howtogeek.com article shows how to automatically elevate for the admin accounts on my machine. I've set this up and have just gone to delete some bin and obj folders as I did last night. However, tonight I feel positively warm and glowing - it simply asked me to confirm the deletion and then they disappear.

Bliss!

UAC: Your Time is Marked!

noreply@blogger.com (Sean Kearon) — Wed, 18 Jun 2008 23:37:00 +0000

Before zipping the source for the last post, I went to remove the bin and obj folders. These are located in my documents folder (under the VS2008 projects folder). My login has admin rights to the machine and I'm not on any domain either - just a standalone home machine!

Life should be sweet then? Well, not if you're using Windows Vista with UAC enabled. There are seeming endless requests for permission to continue. It's a click multiplier...the more you want to do, the more you have to click!

I began by thinking that it's all worth while, it's for security reasons, etc. etc. Right now I'm at the end of my tether and am about to turn it off.

One of my favourites is that when trying to delete the bin/obj folders, I can't! I just get the following:

I created these folders, inside my user profile, on my machine, upon which I have full administrative rights. There were no files locked by other processes (merci, Cedrick!). I had only created the folders a few minutes previously. Man, this is the most tedious version of Windows I have ever used. This stuff drives me insane!

Sometimes when I get the dialog above, if I go into the folder and delete files and subfolders before I delete the main folder, I get to delete the main folder after all that. Wow, that's great, there's a workaround! Well, no - it doesn't always work, just sometimes!!

Vista UAC - your time is marked!