Modern Dinosaurs

Today We’re Going to Bake a Plastic Airplane out of Junk Apr 21

With this post I’m beginning a series in which I use F# to build a data access layer for domain driven designs. I’m dedicating this series to my favorite Donald Duck cartoon, “The Plastics Inventor”, which begins with the immortal line, “As I promised you last week, this morning we are going to bake an airplane out of junk." (If you haven’t seen the “The Plastics Inventor” I suggest you go watch it here.)

Unlike the cartoon, this blog will not cheerfully gloss over the critical first step, which is assembling a pile of junk. No, we’re going to assemble our junk pile piece by piece, and once we’ve got enough we can start figuring out what our “airplane” will look like.

I’m going to write this project with Visual Studio 2010 RTM (Premium Edition, in case that matters), and I’m going to target .NET Framework 4.0.

I’m a TDD kind of guy, so the first thing I want in my junk pile is a unit test project in F#. A lot of F# folks seem to like the xUnit framework, so I’ll start with that. There’s already a nice post explaining how to use xUnit with F# on The Mad Economist blog. I followed his directions, but hit a snag when I tried to load my F# project into the xunit.gui.exe. It seems that xUnit 1.5 (released in September 2009) was built against .NET 3.5 and doesn’t want to load a .NET 4.0 assembly.

No problem, I can download the source code to xUnit 1.5 and recompile it in Visual Studio 2010, targeting .NET 4.0. I did so, rebuilt my test project, and restarted my 4.0 version of xunit.gui.exe. But then along came a new error: "Inheritance security rules violated while overriding member:'InitializeLifetimeService()'. Security accessibility of the overriding member must match the security accessibility of the method being overridden."

Gasp. Microsoft wants us to worry about Code Access Security again. Beginning with .NET 4.0 that bit about matching the security accessibility of overriding and overridden members takes effect. There’s a nice explanation here, but to reading it forces you to think about CAS, which I confess I hadn’t done in a while.

Luckily there’s an easy solution if you’re willing to alter the xUnit source code. Just go into the assemblyinfo.cs file of the xunit.dll project, find the line that says [assembly : AllowPartiallyTrustedCallers], and comment it out. After you  rebuild everything your test project will run in xunit.gui.exe just fine. (The aforementioned thread gives some other solutions, and I don’t know which the xUnit authors might use should they release a .NET 4.0 version of xUnit. But for now, Working is Good.)

There was one other problem: when xunit.gui.exe loaded my F# assembly it couldn’t see my unit tests! Happily The Mad Economist had the same experience and figured out the solution: the F# functions with the [<Fact>] attribute have to have parentheses after the function name, or else xUnit won’t recognize them as tests.

This resolves me, reluctantly, to surrender to the practice of always wrapping my F# function arguments in parentheses, including empty parentheses if there are no arguments. I’m reluctant because I think omitting parentheses from function signatures is really cool. But it leads to too many problems when trying to interact with other .NET applications and libraries.

So now I have the beginnings of my junk pile in place: I can write a unit test project in F#. Keep your radios tuned for the next installment …

Intro to Functional Programming in C# and F# Mar 12

My presentation to the Cleveland .NET SIG on 3/9/2010 can be downloaded here.

I Hate ORMs Mar 10

The last few weeks have been more surreal than usual. I’ve been simultaneously preparing a presentation for the Cleveland .NET SIG on “Functional Programming in C# and F#”. And, at the same time, I’ve been participating in a review of Entity Framework 4.0 and NHibernate for my current client project. Talk about worlds colliding. Functional programming is about immutable data. Ideally all objects should have fields that are read-only. The ORMs on the other hand want to everything to be read/write: every class must have a default constructor, and every property must have a setter, even its “ID”. Fans of EF and NH boast that they “fully support” domain-driven design, but neither of them comes close. I’m about ready to write my own ORM – in F#.

Trying EF One More Time Feb 26

My current project team is interested in using Entity Framework 4.0. I am going to be posting my thoughts about it in the next few days.

The First Post Feb 26

Like the first day at a new job, the first post doesn't do much work.