Deploying custom Asp.net applications to same IIS

问题:

I am attempting to setup an Asp.net application on the same site as Sharepoint. So where http://sharepointurl is the url for sharepoint, to access the application the url would be http://sharepointurl/MyCustomWebApp/. I have setup an IIS application at this level but attempting to run the application with a custom dll in the bin results in the error

" Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed."

I attempted to sign the dll and register it with the sharepoint servers GAC but then I received:

"System.Security.SecurityException: That assembly does not allow partially trusted callers."

If I remove the DLL from the applications bin directory the page loads but I lose functionality I need within it.

Edit: The error happens only if the Dll is in the bin, it does not depend on any one line of code in the Dll.

IIS Version 6 Sharepoint: WSS 3.0 Windows Server 2003

Update: I ran "caspol -machine -addfulltrust (path to dll)" and it succeeded but I still receive the same error.

回答1:

I finally got this resolved. I think part of it was solved by a mix of trying different things people have suggested, but ultimately what fixed it was adding "<trust level="Full" originUrl=""/>" into the web.config. For anyone that doesn't know it should go under the system.web section. I also needed to add several of the dll's. Adding the dll's to the GAC helped but did not solve all of the issues.

回答2:

Once you are using the IIS web site within SharePoint (called a web application within SharePoint), then your ASP.NET application is no longer just an ASP.NET application. It is a SharePoint application (SharePoint runs on ASP.NET, of course). That is, unless you dig around in your web.config to undo a lot of the http handlers that SharePoint puts into place for your particular virtual directory.

There is nothing inherently wrong with moving an ASP.NET application to run within SharePoint, however. Putting your assembly/asssemblies in the GAC is a step that could help, but it looks like that failed for you. Could your assembly be referencing other assemblies that are not in the GAC? That could be your issue.

If your assembly is not in the GAC, then you can use it witihn ASP.NET pages and web parts within SharePoint (but not workflows, event handlers, custom fields, feature receivers, etc.). But, it's a little more painful as you may need to set up Code Access Security (CAS) which is not a simple process. I'm not certain that a CAS policy is needed for SPContext.Current.Web.CurrentUser.LoginName and I tend to only use it for web parts and not ASP.NET pages. A quick search on CAS with SharePoint led me here: http://blog.thekid.me.uk/archive/2007/02/17/code-access-security-cas-and-sharepoint.aspx which looks like a good start if you really want to dig in on CAS.

回答3:

Yep, caspol.exe is your key to happiness here. See Configuring Security Policy Using the Code Access Security Policy Tool.

回答4:

Add an exclude managed path into SharePoint so it does not try to "interfere" with your custom web application.

回答5:

It involves .NET security. There are two ways to solve this and both involve adding "Full Trust" to your SharePoint site. The reason is that SharePoint and your application do not have access to each others resources.

1. The manual way: Add “Full Trust” on the machine.config or the web.config file in the root of your IIS website folder (usually "wwwroot"). This can be a bad idea because it will give Full Trust to every ASP.NET application you run side-by-side with SharePoint. It is a short term, heavy-handed fix similar to solving all code security problems by using Admin access.

2. The automated way: Run the caspol (Code Access Security Policy Tool) against your applications DLL. This is a little more tricky because it requires you to do the same for several folders and DLLs. But it is the safest way to accomplish what you're trying to do.