Unable to deploy my custom DLL to Sharepoint site

Question

I created my custom assembly that has a simple HttpModule in it that I'd like to use in my Sharepojnt 2010 site.

I added my module to sharepoint site's web.config/system.webServer/modules section.

I then also copied my DLL directly to bin folder since that's how suual asp.net applications work. I got an exception about failed AspNetHostingPermission.

I copied the same DLL to _app_bin folder and it worked. My module did get initialized and was running.

I then added two permissions to my module class:

[AspNetHostingPermission(SecurityAction.InheritanceDemand, Level = AspNetHostingPermissionLevel.Minimal)] [AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal)]

and also added these two to assembly

[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
[assembly: AllowPartiallyTrustedCallers]

and strongly signed my assembly with a key I created.

Then I copied the DLL back to bin but it still didn't work. Copying it to _app_bin worked.

What do I have to do, to deploy my DLL directly to bin folder?

Answer 1

Hi Robert

The problem you're running into is that SharePoint is using Code Access Security (CAS) to make it possible for really well educated Admins to make sure that they don't put their environment to unnecisary risk when adding functionallity to it.

The problem is then that even though CAS has been in .Net since the beginning nearly nobody has used it before SharePoint, so most developers don't know how to deal with it.

Everything in _app_bin is running with full trust, which explains why your dll works there.

Everything in bin is running with a lot less trust depending on the trust level specified in web.config (in fact this is also the one that specifies _app_bin has full trust, but thats common in all of the out of box trust levels).

In order to get your dll to work from bin (without changing trust level to full which is bad) you need to modify the policy file which the trust level is pointing to with the right xml for the right your dll need.

Adding the attributes don't help you directly, initially they in fact just makes the problem worse, because now your dll demands the rights even though it might not call anything which requires them.

Where the attributes help you is if you use WSPBuilder to build your WSP package for deploying to SharePoint (You're using a WSP right), then it'll look for security attributes and make the corresponding entries in manifest.xml which then get SharePoint to add the corresponding entries to the policy file on deployment.

In order for you attributes to work with WSPBuilder I think they have to be changed to SecurityAction.Demand though.