将自定义Asp.net应用程序部署到与Sharepoint相同的IIS站点

我终于解决了这个问题。我认为部分问题是通过尝试人们提出的不同建议而解决的,但最终解决问题的方法是在web.config中添加“<trust level=“Full”originUrl=”“/>”。对于任何不知道它的人,应该在system.web部分下。我还需要添加几个dll。将dll添加到GAC有助于解决所有问题,但并没有解决所有问题。

在SharePoint中使用IIS网站(称为SharePoint中的web应用程序)后,ASP.NET应用程序将不再只是ASP.NET应用程序。它是一个SharePoint应用程序(当然,SharePoint在ASP.NET上运行)。也就是说,除非您在web.config中翻找,以撤消SharePoint为特定虚拟目录设置的许多http处理程序。

但是,将ASP.NET应用程序移动到SharePoint中运行本身并没有什么问题。将您的程序集/关联放入GAC是一个可能有所帮助的步骤,但对您来说似乎失败了。您的程序集是否可以引用不在GAC中的其他程序集?那可能是你的问题。

如果程序集不在GAC中,则可以将其用于SharePoint中的ASP.NET页面和web部件(但不包括工作流、事件处理程序、自定义字段、功能接收器等)。但是,这有点痛苦,因为您可能需要设置代码访问安全性(CAS),这不是一个简单的过程。我不确定SPContext.Current.Web.CurrentUser.LoginName是否需要CAS策略,我倾向于仅将其用于Web部件,而不是ASP.NET页面。通过SharePoint快速搜索CAS,我发现: http://blog.thekid.me.uk/archive/2007/02/17/code-access-security-cas-and-sharepoint.aspx 如果你真的想深入研究CAS,这看起来是个好的开始。

是的,caspol.exe是你在这里获得幸福的钥匙。看见 Configuring Security Policy Using the Code Access Security Policy Tool .

将排除托管路径添加到SharePoint中,使其不会试图“干扰”您的自定义web应用程序。

它涉及到.NET安全性。有两种方法可以解决这个问题,它们都涉及到向SharePoint站点添加“完全信任”。原因是SharePoint和您的应用程序无法访问彼此的资源。

1. 手动方式 在IIS网站文件夹(通常为“wwwroot”)的根目录下的machine.config或web.config文件上添加完全信任。这可能不是一个好主意,因为它会让您与SharePoint并行运行的每个ASP.NET应用程序都完全信任。这是一个短期的、严厉的修复,类似于通过使用管理员访问解决所有代码安全问题。

2. 自动化方式 : 对应用程序DLL运行caspol(代码访问安全策略工具)。这有点棘手,因为它要求您对多个文件夹和DLL执行相同的操作。但这是完成你想做的事情最安全的方法。