deploying global.asax to sharepoint 2010 in an enterprise environment to enable unity DI container

Working on a SharePoint project I'm trying to use Unity as a dependency injection container.

My first idea to get this container running is using the global.asax as described in the best practices by P&P:

http://webclientguidance.codeplex.com/releases/view/17134#DownloadId=43305

In these best practices they tell you to manually edit the global.asax file to make it inherit SPUnityHttpApplication.

<%@ Application Language="C#" Inherits="Unity.SharePoint.SPUnityHttpApplication" %>

Manually editing this file is not an option in enterprise environments since we have multiple environments (DTAP) and all of them have multiple frontend servers that would need manual steps.

I can't find any way to deploy a global.asax file by using a feature or wsp or anything because the global.asax is located in the web application root and sharepoint deploys other files to the /14 hive folder so you can't acces the web application root directory.

Alternati开发者_JAVA技巧ves i've looked into is the SharePointServiceLocator. this build in functionality does almost what i want. but it can only resolve classes that have a default constructor. this way i can't chain resolve all my implementations by using constructor injection. I found a post how to change the service locator to make use of unity but this doesn't seem to work properly if you read the comments.

My problem can be fixed by fixing 1 of these 2 main problems:

• Don't arrange unity in the global.asax, but then where and how?
• Deploy the global.asax in sharepoint? possible?

The global.asax doesn't seem to be the best solution to do this because of the deployment issues described in the question.

A viable solution is implementing this in a httpmodule

The init method can be used to wire everything up since this is called when the sharepoint application starts.

the httpmodule can be added in the web.config by a feature receiver

This way there is no need to do tricks with the global.asax that is located in a directory you can't deploy to with a feature and you have all the functionality and correct time to instantiate the DI container.

It may not be ideal, but you could look at using a feature receiver and write code to edit the existing files directly.