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 …