I will be presenting at the West Michigan .NET University on April 4th about ASP.NET with my friend Carl Furrow. The goal of the .NET University is to educate beginners about .NET. Specifically our discussion will bring you up to speed on ASP.NET, Microsoft’s Web platform. But don’t miss out on some of the other great sessions by some really great people from West Michigan.

We even get a cool badge!

Do you use StructureMap? NHibernate? Good. Have you tried using them with WCF? Yeah, me too. It didn’t go so well for me either. StructureMap, NHibernate, and WCF all worked fine. They did nothing wrong. I guess it was my journey to find out how to make them work together that felt painful. So how did I do it? I Googled it, of course. This led me to read a few varying accounts of how others made it work. Each scenario was different than mine in some significant way (of course) so they each gave me a piece of the whole picture.

First, I tackled with getting StructureMap working with WCF. This wasn’t nearly as problematic as it could have been. Thanks to Jimmy Bogard for writing up a walkthrough on how to make it work.

Jimmy’s post: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/07/29/integrating-structuremap-with-wcf.aspx

Second, I had to get NHibernate opening sessions per request, which is different than a typical request in an ASP.NET application. This is where the trouble started. I followed a second post by Jimmy discussing this very issue.

Jimmy’s Other Post: http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/09/16/integrating-structuremap-and-nhibernate-with-wcf.aspx

So this got me further but eventually I began having weird issues. As in things working and then not working out of nowhere. Eventually after some frustration I began to suspect a threading issue. Sure enough, In a discussion on the StructureMap User Group, Jimmy mentioned that the solution may have threading problems. Awesome.

So, Googling I found another post by Frank-Leonardo Quednau who described a different approach.

Frank-Leanardo’s Post: http://realfiction.net/?q=node/167

Using the OperationContext.Current.InstanceContext.Extensions collection to store the NHibernateSession because the instance context only lives once for the service request. The idea being that you can open the Session when the InstanceProvider starts and close the Session when it release the service instance.

I followed the post and nearly got it working pretty well, but my project structure didn’t work very well with how it was setup. I don’t know if it’s because of my UnitOfWork or FluentNHibernate or what, but things just didn’t line up for me.

So here is what I ended up doing. (Sorry for the images. It looked better than our style for inline code. Don’t worry though all the code will be posted at the end. And Here.)

1. In my WCF application I created my StructureMap Registry. The registry wires up all my object instances at runtime. You’ll notice that the ServiceinstanceContextBuildPolicy; this is a custom build policy (caching policy is a better term maybe) which instructs StructureMap to cache it’s objects in a  special way for WCF (per service instance). More on that later. Everything else here is pretty run of the mill. I create an NHibernate Session from my SessionSource (fluentNHibernate) which sets up my UnitOfwork and creates an instance of my Repository to do the Querying, Loading, Saving of my domain objects.

2. To setup this registry, I needed a BootStrapper. The BooStrapper is initializing StructureMap with my registries, in this case I only have one, but I could add more later.

3. To get call the BootStrapper I needed a StructureMapServiceHostFactory.

4. The StructureMapServiceHostFactory creates instances of…StructureMapServiceHosts. The StructureMap Service Host isn’t necesarily the best name for it. The Service Host is responsible to add the InstanceCreationService Bahavior, when a Service Host is opened.

5. The InstanceCreationServiceBehavior wires up two things. First it wires up the InstanceProvider which does the “heavy lifting” for our UnitOfWork. Things like Initialize, Commit, RollBack, and Dispose.

Notice that after the finally block, I check for the InstanceContext.Extensions to Remove the InstanceCreationExtension. Doing so fires the Detach Event which  calls the DisposesAndClear() method on our StructureMap Cache living inside of the InstanceCreationExtension. So where is that InstanceCreationExtension added? Well, in our InstanceCreationInitializer of course! :)

5.a. The InstanceCreationBehavior also wires up an InstanceCreationInitializer which enables the Custom Cache Policy from above, to work. The Initialize method adds a new InstanceCreationExtension which is being created with a null StructureMap InstanceCache as you see below.

6. So the InstanceCreationExtension is quite important to this whole thing working properly. Its job is to create and destroy the StructureMap InstanceCache when it is added and removed from the service instance.

7. Whew! so now that we have all that in place we still need StructureMap to use that Extensions collection to store the InstanceCache. The InstanceCache in structureMap is where it stores all of it’s Instantiated Objects. So in this case (refer to the Registry) the UnitOfWork and NHibernateUnitOfWork are being stored there but I want a new one every time a new Service Instance is started.

RED: This is where I check for an existing InstanceCreationExtension which stores our StructureMap InstanceCache. I learned the hard way that many of these things can be null so you’ll see I do a lot of checking for null instances of many things here.

YELLOW: This is where the InstanceCache which will be returned to StructureMap is being set.

GREEN: This is where I’m adding that InstanceCache back to our InstanceCreationExtension so that when StructureMap calls this Cache Policy again it will find it.

Eventually I have a Cache to return to StructureMap so it can grab the object that was being requested. For us, the requested instanceCache will have our NHibernateUnitOfwork on it.

So…Given a ServiceContract that looks like this:

I can do things like this:

My Repository will be injected by StructureMap and will have the UnitOfWork on it to execute the query against the database. The next time this Service is called a new UnitOfWork will be created and we’ll start the whole thing all over again.

If you’ve read this much I appreciate the time you’ve taken sitting through this lengthy post. So as a reward, please feel free to download the code and play around with it. I know it’s not perfect and I’m very open to the possibility that there is a better way to do this. If you have any suggestions please let me know. I appreciate any feedback. As long as it’s good feedback. :)

DOWNLOAD: GET THE CODE HERE!

BizTalk solves a lot of problems, but with it comes a whole other bag of fun new ones to solve. Oh joy. All kidding aside I have been facing some real challenges working with cXML in BizTalk due to the nature of the cXML standard. Primarily the fact that cXML does not use XSD’s to describe itself and instead uses a DTD. BizTalk does not like DTD’s, as in, if you send a document to BizTalk with a DTD using the standard XML Pipeline, it will fail.

BizTalk also doesn’t work well if you try sending it messages that don’t have an XML Namespace because BizTalk uses the Namespace and the root node of the XML document to identify the message inside the system. So I have to inject something like xmlns=”http://something” into the root node as well.

Some solutions have been documented but I ran into other issues and ended up the solution a little further. Long story short, I ended up creating a custom Pipeline Component to strip out DTD’s and add Namespaces using regular expressions. At first I created a cXML cleaner component that worked specifically for my scenario. This worked fine but eventually I noticed that I was using a regular expression to find and replace the DTD which led me to think “Why can’t I use any regex I pass in and replace anything I want to?” So I did. I even made it open source so no one ever has to feel the anguish of having to develop custom BizTalk Pipeline Components, because it sucks. Bad.

Feel free to pull it down and give it whirl. If you improve it, by all means, send me a patch and I’ll include it in the trunk.

RegexReplace on Google Code

Screenshots:

1. Use Multiple RegexReplace in a single stage to process a document multiple times.

2. Simply set the Pattern and the Replacement string.

UPDATE: Turns out it was just Gallio (v3.0.5 build 546 - x86). I also tried uninstalling TestDriven.NET and the problem persisted.

This weekend I spent some time working with the release candidate of ASP.NET MVC to familiarize myself with the new features, only to find Visual Studio crashing every time I opened a View. It was pretty frustrating, especially since this was the almost ready for prime time version, and I had been working without any problems for a while using earlier versions. Obviously I started searching the interweb for an answer.

Zero point two seconds later Google found me an answer on StackOverflow. Turns out I'm not the only one who has experienced this strange behavior. When I say strange behavior, I mean “.NET Runtime version 2.0.50727.3053 - Fatal Execution Engine Error (70DC5E00) (80131506)” strange. I had started by removing the Spark View Engine add-in I have for working with Spark and MVC (which is awesome). That didn’t fix it though. A Christian Dalagar pointed out that he experienced the same problem and it appeared to be a conflict between Gallio and TestDriven.NET. Hmmm…That’s funny. I happen to have both of those installed as well!

This was the hard decision…well not really. I can’t live without my TestDriven.NET. Sorry Gallio. Maybe we’ll meet again in another life. Don’t get me wrong I like Gallio, and MBUnit is kind of growing on me, but TestDriven.NET is the best way to run tests in Visual Studio.

PROBLEM: Opening ASP.NET MVC RC Views Crashes Visual Studio when both TestDriven.NET and Gallio are installed.

SOLUTION: Un-install Gallio.