问题标签 [sharepoint-2007]

将我的 InfoPath 2007 表单从设计器部署到我们开发环境的 SharePoint 服务器中是一件非常痛苦的事情。我们所有的表单都需要“完全信任”，因为它们包含用 C# 编写的业务逻辑。以下是手动步骤：

1) 在 InfoPath 中运行“发布表单”向导，指定要发布到的目标站点和保存 xsn 文件的位置。

2) 从网站集功能中停用现有版本的表单（如果存在旧版本）。

3) 在开发服务器上登录 Central Admin。导航到应用程序管理 -> 管理表单模板并上传 xsn 文件。

4) 将表单激活为网站集功能。

有谁知道如何实现自动化？也许通过stsadm？

我正在尝试在 SharePoint 网站上设置一些友好的 URL。我知道我可以使用 RewritePath 执行 ASP.Net 2.0 友好 URL，但我想知道是否可以使用 ASP.NET 3.5 SP1 附带的 System.Web.Routing。

我想我已经想出了如何加载我的路由表，但我不清楚使用什么方法来让正确的 IHttpHandler 传递出去。

谢谢！

我想知道在开发功能时是否有一种很好的方法可以连接到 SharePoint 2007 网站的 Application_Start？我知道我可以直接在站点根目录中编辑 Global.asax 文件，但是有没有办法做到这一点，以便使用该功能进行部署？

谢谢！

我想在我的 Sharepoint Web 部件中记录内容，但我希望它进入 ULS。我发现的大多数示例都记录到事件日志或其他文件中，但我还没有真正找到用于登录 ULS 的示例。

令人讨厌的是，Microsoft.SharePoint.Diagnostics 类都标记为内部。我确实找到了一个如何通过反射来使用它们的示例，但这看起来非常冒险且不稳定，因为微软可能会使用他们想要的任何修补程序来更改该类。

Sharepoint 文档也没有真正的帮助 - 关于 ULS 是什么以及如何配置它的大量管理员信息，但我还没有找到支持代码的示例来实际记录我自己的事件。

任何提示或提示？

编辑：正如您从这个问题的年龄所看到的那样，这是针对 SharePoint 2007 的。在 SharePoint 2010 中，您可以使用 SPDiagnosticsService.Local ，然后使用WriteTrace。请参阅下面 Jürgen 的答案。

我正在开发一个我想在其中公开 AJAX 功能的 WebPart（它将在 SharePoint 环境中使用，尽管它不使用对象模型）。由于环境的性质，将脚本管理器直接添加到页面是不是一个选项，因此必须以编程方式添加。我试图将 ScriptManager 控件添加到我的 webpart 代码中的页面。

但是，执行此代码时，我收到以下错误消息：

“在 DataBind、Init、Load、PreRender 或 Unload 阶段不能修改控件集合。”

是否有另一种方法可以将 ScriptManager 从 WebPart 添加到页面，或者我是否必须将 ScriptManager 添加到将使用 WebPart 的每个页面（或母版页）？

这可能看起来有点微不足道，但我一直无法弄清楚。我正在打开一个 SPSite，然后尝试在该 SPSite 下打开一个 SPWeb。这在具有相同站点集合/站点层次结构的 VPC 上运行良好，但在生产中，当我尝试 SPSite.OpenWeb(webUrl); 时，我收到一个异常，告诉我 URL 无效。我已经验证了 URL 是正确的。

编码：

注意：
branchScheduleURL 实际上是包含 Web 的 URL 的整个 URL。

输出+异常：

网站集 URL：https
://ourSite.com/mocc System.ArgumentException：无效的 URL：/internal/scheduletool。在 Microsoft.SharePoint.SPSite.OpenWeb(String strUrl, Boolean requireExactUrl) 在 Microsoft.SharePoint.SPSite.OpenWeb(String strUrl) 在 MOCCBranchScheduleListWeb.MOCCBranchScheduleListV3.GetConflictListItem(String branchScheduleURL, String testID)System.NullReferenceException: 对象引用未设置为对象的实例。在 MOCCBranchScheduleListWeb.MOCCBranchScheduleListV3.CheckForConflicts（字符串 [] cfcFlags1，日期时间开始时间，日期时间结束时间，字符串 [] cfcFlags2）

注意：
https : //ourSite.com/mocc/internal/scheduletool 是我要打开的 SPWeb。

我错过了一些明显的东西吗？任何帮助将不胜感激。

谢谢。

编辑：修改标题并添加更新。

更新： 我们不再认为这是 64 位与 32 位的问题。我们发现，唯一看到这一点的人，是那些在农场政策中设定为“完全控制”的人。（不作为系统帐户）一旦我们测试了普通用户，我们发现没有一个有问题。从场策略中删除“问题”用户并将其添加回来，修复了除一个用户之外的所有用户（一位开发人员:)）。

我们用 2 个 32 位 WFE 和一个 32 位应用程序服务器开始了我们的农场。我们决定在我们的农场中添加 64 位前端，并且在大多数情况下，几乎一切都运行良好。访问用户配置文件数据库的自定义 Web 部件例外。在 32 位前端工作正常，但在 64 位前端我们得到以下错误：

找不到用户：无法从数据库加载配置文件数据。

说明：执行当前 Web 请求期间发生未处理的异常。请查看堆栈跟踪以获取有关错误及其源自代码的位置的更多信息。

异常详细信息：Microsoft.Office.Server.UserProfiles.UserNotFoundException：找不到用户：无法从数据库加载配置文件数据。

源错误：

在执行当前 Web 请求期间生成了未处理的异常。可以使用下面的异常堆栈跟踪来识别有关异常起源和位置的信息。

堆栈跟踪：

[UserNotFoundException：找不到用户：无法从数据库加载配置文件数据。]
Microsoft.Office.Server.UserProfiles.UserProfile.Load(SqlDataReader myReader, Boolean bFirstRead, Boolean bWssId) +930
Microsoft.Office.Server.UserProfiles.UserProfile。负载（SqlDataReader myReader）+64
Microsoft.Office.Server.UserProfiles.UserProfile.RetrieveUser（字符串 strAcct，Guid gAcct，Byte[] bSid，Nullable`1 recordId，布尔值 doNotResolveToMasterAccount）+1507
Microsoft.Office.Server.UserProfiles.UserProfile。 .ctor(UserProfileManager objManager, String strAcct, Boolean doNotResolveToMasterAccount, Boolean forceUserIsSelf) +584
Microsoft.Office.Server.UserProfiles.UserProfile..ctor(UserProfileManager objManager, String strAcct) +80
Microsoft.Office.Server.UserProfiles.UserProfileManager.GetUserProfile(String strAccountName) +205

由于 WFE 位于同一个场中，因此它应该查看同一个数据库。

让我知道是否需要更多信息。

任何想法，将不胜感激！

谢谢。

我有一个行为奇怪的发布网站的页面布局。

想象一个发布站点 (site) 有一个子站点 (subsite1)，它具有以下页面 (page1 [默认]、page2 和 page3)

对于第 2 页和第 3 页，面包屑正确呈现：

但是对于默认页面，面包屑仅呈现为

知道如何强制它也显示默认页面的标题吗？

从 Word 2007 保存到我们的 SharePoint 2007 (MOSS) 文档库时，我们遇到了一个奇怪的间歇性问题，它提供了一个永远不会消失的对话框 - 它的标题是“内容类型”和消息“正在获取可用内容类型的列表... " 带有一个持续滚动的绿色进度条。它在我们的训练服务器（具有独立 SQL Server 的自包含虚拟机）上发生了很多，但更令人担忧的是在我们的实时生产服务器上发生SQL 服务器）。场中的所有服务器都是 64 位的。

这是奇怪的随机 - 用户必须杀死 Word 2007，然后他们恢复他们的文档并尝试保存到同一个文档库，它保存没有问题。

它发生在训练服务器上比实时服务器上更多。实时 Web 应用程序服务器很少超过 20% 的 CPU（通常为 5% 左右），内存峰值为可用 4Gb 的 2Gb（通常为 1.5Gb），所以我认为这不是资源问题。

使用解决方案中的功能自定义和部署文档库。其中唯一的内容类型是标准的 Documents 内容类型。

更新我们将此作为支持问题与 Microsoft 一起打开，这是一个已知问题，目标是在 2009 年 2 月的 SharePoint 累积更新修补程序包中解决。

编辑将上述回复复制到一个答案，以便可以将此问题标记为已回答。

我已经尝试过，但由于某种原因，工作流程没有被触发。