如何确定 SharePoint 网站的正确(区分大小写)URL
问题:使用 SharePoint API(对象模型)创建网站栏,如果 SPSite 或 SPWeb 对象的 URL 大小写不正确,则在尝试对其进行编辑时将导致新栏引发异常通过网站栏库。
SharePoint 通常非常容忍以不区分大小写的方式接受 URL,但在少数情况下它会完全崩溃。例如,当创建网站栏时,它会以某种方式存储并使用创建时的 URL,而当尝试通过网站栏库(布局中的 fldedit.aspx 页面)编辑字段定义时,最终会抛出以下错误。
Value does not fall within the expected range.
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName, Boolean bThrowException)
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName)
at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
如何可靠地获取站点/网站的正确 URL? SPSite.Url 和 SPWeb.Url 属性似乎会返回它们实例化时的大小写。
换句话说,网站集是使用以下 URL 设置的: http://server/Path/Site
然后,如果我使用 SharePoint 对象模型创建一个新的网站列并且碰巧使用 http://server/path/site 实例化 SPSite 和 SPWeb 对象时,站点栏将可用,但当尝试通过图库访问它时,会生成上述错误。如果我更正地址栏中的 URL,我仍然可以查看/修改相关 SPField 的定义,但生成的默认 URL 是伪造的。
清澈如泥?
示例代码:(由于区分大小写问题,这是一个不好的示例)
// note: site should be partially caps: http://server/Path/Site
using (SPSite site = new SPSite("http://server/path/site")) {
using (SPWeb web = site.OpenWeb()) {
web.Fields.AddFieldAsXml("..."); // correct XML really here
}
}
Problem: Creating a site column using the SharePoint API (Object Model) with incorrect case in the URL for the SPSite or SPWeb object will cause the new column to throw an exception if an attempt to edit it is made through the Site Columns Gallery.
SharePoint is generally very tolerant of accepting a URL in a case-insensitive fashion, however there are a few cases where it completely breaks down. For example, when creating a site column it somehow stores and uses the URL when it was created, and when trying to edit the field definition through the Site Column Gallery (fldedit.aspx page in the LAYOUTS) you end up throwing the error below.
Value does not fall within the expected range.
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName, Boolean bThrowException)
at Microsoft.SharePoint.SPFieldCollection.GetFieldByInternalName(String strName)
at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
How can I reliably get the correct URL for a site/web? The SPSite.Url and SPWeb.Url properties seem to return back whatever case they are instantiated with.
In other words, the site collection is provisioned using the following URL: http://server/Path/Site
Then, if I create a new Site Column using the SharePoint object model and happen to use http://server/path/site when instantiating the SPSite and SPWeb objects, the site column will be made available but when trying to access it through the gallery the error above is generated. If I correct the URL in the address bar, I can still view/modify the definition for the SPField in question, but the default URL that is generated is bogus.
Clear as mud?
Example code: (this is a bad example because of the case sensitivity issue)
// note: site should be partially caps: http://server/Path/Site
using (SPSite site = new SPSite("http://server/path/site")) {
using (SPWeb web = site.OpenWeb()) {
web.Fields.AddFieldAsXml("..."); // correct XML really here
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不确定这是否会影响您,但 SharePoint url 中存在一个关于区分大小写的已知错误。
http://blogs.msdn.com/enterprisesearch/archive/2008/01/25/crawling-case-sensitive-web-content-in-sharepoint-server-2007-and- search-server-2008.aspx
由于您是在三月份发布此内容,因此您可能已经安装了安装了修补程序的服务包。但是,您可能缺少注册表设置。
Not sure if this is affecting you, but there is a known bug with respect to case sensitivity in SharePoint urls.
http://blogs.msdn.com/enterprisesearch/archive/2008/01/25/crawling-case-sensitive-web-content-in-sharepoint-server-2007-and-search-server-2008.aspx
Since you are posting this in March, you probably have a service pack with the hotfix installed. You may however be missing the registry setting.