为什么第一次将它添加到页面时,Web部件会在构造函数上失败?

时间:2009-03-17 22:00:52

标签: sharepoint exception sharepoint-2007 moss web-parts

这个问题有点具体(MOSS2007),我不希望得到答案,但也许运气会对我微笑。

我有一个网页部分,除了第一次它被添加到页面之外。当我尝试打开与SQL服务器的连接时,它会在构造函数中抛出异常。对SqlClientPermission权限的需求失败。当我说它有效时,我的意思是它在任何方面都得到了适当的注册,并且适用于所有其他情况,包括后续的电话。

有人说没有出路。我想知道为什么。这是设计吗?

我甚至完全信任我所能做的一切(改变了我在服务器上找到的每个 .config文件),但它没有帮助。

似乎SharePoint在第一次添加Web部件时正在进行某种远程处理,它在第一次构建时似乎以最小的信任运行(与ASP.Net的web_minimaltrust.config中定义的相同)。尝试为所有内容的所有内容授予权限并没有产生任何富有成效的结果。

我的解决方案是将数据访问代码移动到OnInit方法,但这很烦人。有没有人有任何见解?

谢谢。

来自调试器的一些额外信息。

唯一允许的权限是:

<PermissionSet class="System.Security.PermissionSet" version="1">
    <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Execution"/>
    <IPermission class="System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Level="Minimal"/>
</PermissionSet>

内部异常堆栈:

hresult = -2146233078
mscorlib
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.PermissionSet.Demand()
at System.Data.Common.DbConnectionOptions.DemandPermission()
at System.Data.SqlClient.SqlConnection.PermissionDemand()
at System.Data.SqlClient.SqlConnectionFactory.PermissionDemand(DbConnection outerConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at System.Data.Linq.SqlClient.SqlConnectionManager.UseConnection(IConnectionUser user)
at System.Data.Linq.SqlClient.SqlProvider.get_IsSqlCe()
at System.Data.Linq.SqlClient.SqlProvider.InitializeProviderMode()
at System.Data.Linq.SqlClient.SqlProvider.System.Data.Linq.Provider.IProvider.Execute(Expression query)
at System.Data.Linq.DataQuery`1.System.Linq.IQueryProvider.Execute[S](Expression expression)
at System.Linq.Queryable.Count[TSource](IQueryable`1 source)
at IManageDocumentsPart.ClientSideDocumentsWebPart.GetOfficeCode(Int32 employeeId)
at IManageDocumentsPart.ClientSideDocumentsWebPart..ctor()

完整筹码:

IManageDocumentsPart.DLL!IManageDocumentsPart.ClientSideDocumentsWebPart.ClientSideDocumentsWebPart() Line 98    C#
[Native to Managed Transition]    
[Managed to Native Transition]    
mscorlib.dll!System.RuntimeType.CreateInstanceSlow(bool publicOnly, bool fillCache = true) + 0x68 bytes    
mscorlib.dll!System.Activator.CreateInstance(System.Type type, bool nonPublic) + 0x43 bytes    
System.Web.dll!System.Web.HttpRuntime.FastCreatePublicInstance(System.Type type) + 0x56 bytes    
System.Web.dll!System.Web.UI.WebControls.WebParts.WebPartManagerInternals.CreateObjectFromType(System.Type type) + 0x7 bytes    
System.Web.dll!System.Web.UI.WebControls.WebParts.WebPartManager.ImportWebPart(System.Xml.XmlReader reader = {EndElement, Name="metaData"}, out string errorMessage = null) + 0x35d bytes    
Microsoft.SharePoint.dll!Microsoft.SharePoint.WebPartPages.SPWebPartManager.ImportWebPartBase(System.Xml.XmlReader reader = {EndElement, Name="metaData"}, string importErrorMessage = "Cannot import this Web Part.", out string errorMessage = null) + 0x25 bytes    
Microsoft.SharePoint.dll!Microsoft.SharePoint.WebPartPages.WebPartImporter.CreateWebPart(bool clearConnections = true) + 0x1b4 bytes    
Microsoft.SharePoint.dll!Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(Microsoft.SharePoint.WebPartPages.SPWebPartManager manager = {Microsoft.SharePoint.WebPartPages.SPWebPartManager}, System.Xml.XmlReader reader = {None}, bool clearConnections = true, System.Uri webPartPageUri = {http://v-sp2007/testsite/default.aspx?PageView=Shared}, Microsoft.SharePoint.SPWeb spWeb = {Microsoft.SharePoint.SPWeb}) + 0x8e bytes    
Microsoft.SharePoint.dll!Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(Microsoft.SharePoint.WebPartPages.SPWebPartManager manager = {Microsoft.SharePoint.WebPartPages.SPWebPartManager}, System.Xml.XmlReader reader = {None}, bool clearConnections = true, Microsoft.SharePoint.SPWeb spWeb = {Microsoft.SharePoint.SPWeb}) + 0xa1 bytes    
Microsoft.SharePoint.dll!Microsoft.SharePoint.WebPartPages.WebPartQuickAdd.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(string eventArgument = "http%253A%252F%252Fv%252Dsp2007%252F%255Fcatalogs%252Fwp%252FClientSideDocumentsWebPart%252Ewebpart;ClientSideDocumentsWebPart") + 0x288 bytes    
System.Web.dll!System.Web.UI.Page.RaisePostBackEvent(System.Web.UI.IPostBackEventHandler sourceControl, string eventArgument) + 0xc bytes    
System.Web.dll!System.Web.UI.Page.RaisePostBackEvent(System.Collections.Specialized.NameValueCollection postData) + 0xb2 bytes    

...堆栈的其余部分与正常打开页面时相同。

5 个答案:

答案 0 :(得分:2)

尝试设置解决方案包以部署代码访问安全设置。你肯定需要SqlClientPermission。查看我在Code Access Security for web parts上的帖子了解更多信息。

答案 1 :(得分:1)

这很奇怪。当页面处于编辑/设计模式时,也许你可以在特殊情况下将你的Web部件不进行数据库调用。这不能解决你的问题吗?

答案 2 :(得分:1)

作为一个简单的测试,您可以将包含Web部件的程序集部署到GAL中。在那里,它将以完全信任的方式运行。

就个人而言,我不建议在Web部件的构造函数中建立数据库连接,除非您有令人信服的理由这样做。

[更新3009-03-27]

调试通常是排除原因。即使您认为Web部件在Full Trust中运行,我也建议您测试GAC的情况。请记住从Bin目录中删除.dll以进行测试。这只需要5-10分钟,您将知道您所处的位置。

答案 3 :(得分:1)

  

我的解决方案是将数据访问代码移动到OnInit方法,但这很烦人。有没有人有任何见解?

当SharePoint经历并处理请求时,它将要做的第一件事是执行构造函数以创建对象的新实例。它调用的构造函数是无参数的,因此可以对它们进行序列化和反序列化以进行导入/导出。在构造函数内部,没有在新创建的对象中设置任何安全构造或关联对象。因此,您的对象可能没有关于它的生活位置或正在做的事情的任何上下文信息。

通过将代码移动到OnInit方法中,您已将执行时间转移回某些相关对象以及此点未自动绑定的对象。在ASP.net生命周期中,OnInit方法从上到下工作,OnLoad方法从下到上工作。因此,这也可能会影响您的父母或子女是否已执行相关代码。

答案 4 :(得分:1)

正如下一篇文章的参考资料,here有很多文章中的一篇是Web部件构造函数中的代码标记为大NO-NO