Ok, this is more of a hack than a true conversion, but I haven’t noticed the difference… yet.

Remember to back up what you’re not willing to lose!

1. Remove your MVC project from your solution. Don’t delete, just remove. Then save all (Shift-Ctrl-S)
2. Edit your MVC project *.csproj file and change the ProjectTypeGuids to:
   <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
3. Add your project back into your solution and save everything

asp mvc, conversion

Whatever I think of Godaddy, they haven’t caused me too much pain yet, just minor inconvenience. This time it’s my precious StructureMap.

StructureMap, I like it and alot of people do, but it just won’t work under Medium Trust! So it’s either time to change Hosts, or change IoC container. Pretty obvious which one is the easier choice here.

So what choice do you have? Well not much. So the answer is:

Unity from Microsoft Patterns & Practices*

Here’s a nice manual to go with it.

And what’s not able to be run in medium / partial trust:

Windsor Castle
Spring.Net
StructureMap

There was someone who was explaining how to download and build Spring.Net to allow it to run under Medium Trust, but that seems pretty likely to cause issues when you hack code (try to ignore my NHibernate post when I say that).

It may be the same for the other 2, but off the bat, Unity wins.

*Caveat: Unity is restricted in what it can do when run without ReflectionPermission (which is what Medium Trust disallows), but typically this won’t affect much from the normal IoC behaviour.  The restrictions are explained on this MSDN doc, but it’s to do with internal and private constructors and properties. If it’s public you should be sweet.

godaddy, IoC, unity

Ok, so Log4Net is not that bad. It is a very good logging system, etc…

So how do you perform IoC with the NHibernate logger? Well, you can’t. Unless you are ready to HACK CODE.

That’s the brilliant thing about open source. Take it and modify until its the shade of green that suits you.

The First Warning

If you modify the DLL for NHibernate, then all associated DLL’s break.
For me this means FluentNHibernate wont like you. So you will have to rebuild that too for the new NHibernate DLL.

According to the bug report for exactly this issue, in the future log4net will be removed as a dependency (yay). For the logger interface Commons.Logging has been “sort-of” chosen. Meaning: you should  use the ILog interface from Commons.Logging for your Log interface! Make’s it a bit more future proof.

What I did to have IoC : 2nd Warning  – This is not a concise walkthrough

1. Download the source code of
1. NHibernate – Under the Browse Files you will find a SRC version.
2. FluentNHibernate – Download from GitHub
3. Commons.Logging 
2. Create a new Interface called ILog that is inside the NHibernate project. This is because it will be used as an adapter for the Commons.Logging. It’s probably best to put under a smart namespace like NHibernate.Logging.ILog
3. Create a LogManager class that does the same thing as the log4net LogManger, but using the Commons.Logging assembly. I know this is vague, but my implementation wasn’t very good. The idea is that when NHibernate is called, the LogManager is setup using the Commons.Logging.ILog object that was returned by my  IoC object  factory.
4. Remove the References of log4net from the projects
5. Replace all namespaces of log4net with the namespace of your new Interface and LogManager (say NHibernate.Logging).
6. Remove all Log4Net residue, like Cfg calls and XML setup arguments.
7. Build and everything should be happy.

FluentNHibernate, Logging, NHibernate