StructureMap, Code Access Security and a Bad Solution to a Problem

So I’m working on a new project and I decided to use StructureMap (version 2.5.3) as an IoC container for the application. So I hooked it up for some code, ran my unit tests and all was peachy. Then I tried to run the app on IIS (Win7 RC) and I got a code access security exception.

Before I go on I do want to say that I don’t blame this on the StructureMap folks at all. This is likely caused by the combination of a) my lack of familiarity with StructureMap and b) the fact that code access security stuff still mystifies me at times...in this case in particular. This solves my problem but there has got to be a better way to solve this. I hope one of you knows what that is. That being said, I do have a recommendation for a code change for StructureMap. Anyway...

So I proceeded to waste about an hour jacking with my web.config trying to get the trust level high enough to allow this to work. So I posted a question on Stack Overflow and mentioned something on Twitter. Joshua Flanagan on the former and @Andersonimes on the latter both pointed in the same direction, that something was probably being emitted and written to disk, thus causing the issue. This got me thinking but is not the direction I went in at first.

So I was thinking about the stack trace in the YSOD above and decided to browse the source online to see what was happening. It appeared that SM was going to disk to look for a configuration file (which was not my intention) so I looked to see if there was a way to tell it not to look for the configuration. Sure enough, it did. So I set it and ran it again.

So that didn’t work. It still tried to find the config. So I decided to stop setting properties and guessing what would happen and download the source and find out for sure. So I dug around and found the problem. Note the following bit of code from the ConfigurationParserBuilder class:

Lines 130 and 131 were ones that I added, so ignore those for a moment. Those flags, set in my configuration above, are checked by the SM code in the method called on line 134. However, my security exception was being thrown when the method on line 133 was called. Doh! Solution? Move the checks that were in shouldUseStructureMapConfigFileAt method to above the attempt to build the path. I did that and I made it past that security exception. This is my one suggestion for the StructureMap folks. If the configuration is set to ignore the config file then all of the logic of this method can be avoided. Maybe you don’t want to do it how I did but I think that makes sense. Or, I could be missing something entirely.

So I got past that. Yay! But then I got another one. Bummer... Here’s the source code after I modified it:

All I changed was that I uncommented lines 51 and 56 and commented out lines 50 and 53. I’m assuming this is the area of code that Joshua was mentioning and is the same area that Anderson was alluding to. When I changed that the security exception went away because the assembly was no longer being written to disk. And that was the end of it. Everything works fine now.

As I was writing this I switched that last code change back so I could get a screenshot of the new error. Of course this time the security exception wasn’t thrown. Funky voodoo going on here...so I changed it back and I’m leaving it for now.

So now I have StructureMap working for me. But I’m quite sure this is not the best way to solve this problem. Anyone want to hazard a guess at a solution?