技术开发 频道

用于构建SharePoint解决方案的10个非常好的实践

  【IT168 技术文档】面对 Windows SharePoint Services 3.0 (WSS) 和 Microsoft Office SharePoint Server 2007 (MOSS) 所使用的人员的挑战是为深度和宽度为 SharePoint 平台本身。 如果您熟悉此平台做法本文中的研究,我们将引导您正确的方向。 如果您是经验丰富的 SharePoint 开发人员,可这些提示应帮助强化您、 鼓励讨论,和最终会导致生成性能优异的 SharePoint 应用程序。 此外,我们提供了许多联机参考,您可以了解详细信息我们讨论的主题。

  1.SharePoint的系统交互

  早在 SharePoint 开发项目发生的一个问题是如何最好地与其他系统进行交互。 因为 SharePoint 是一个复合应用程序平台,这个问题是您可能必须经常回答。 查看 SharePoint 体系结构,从 Web 应用程序级别是着手它在最简单方法。 SharePoint 的实例包含多个 Web 应用程序。 如果您不熟悉 SharePoint 应用程序体系结构,您应该检查" Office SharePoint Server 2007 的结构概述 ." 
 
  图 1 显示了用于与 Web 的应用程序之间在 Web 应用程序中的 SharePoint 和外部系统进行交互的典型方法。 我们将介绍这些交互本节的其余部分的每个。 



图 1 SharePoint 系统交互模型

  使用 SharePoint 对象模型 编写 ASP.NET 窗体源代码的 Web 部件或 Web 控件特定的 Web 应用程序的上下文中运行时 (请参见图 1 )。 SharePoint 对象模型提供一个丰富的一组通过它与 SharePoint 进行交互的类。 在 Windows SharePoint Services 3.0 和 Microsoft Office SharePoint 服务器 SDK 提供这些类的好覆盖率。

  处理 SharePoint 网站 (SPWeb) 或网站 (SPSite) 处置时,上下文是一个重要考虑因素。

  从 SharePoint 对象模型的角度来看,SharePoint Web 应用程序是一个重要的安全边界。 通常,不应为 SharePoint Web 应用程序之间的交互使用 SharePoint 对象模型。 请参阅" SharePoint 2007 中的安全编程 "有关其他重要的 SharePoint 安全性主题的信息。

  在调用时 SharePoint Web 应用程序之间和 SharePoint 和等 Office 客户端应用程序的外部应用程序之间使用 SharePoint Web 服务集成层。 尝试在 Visual Studio 中的外服务器开发任务时,这是一个很好的方法。

  与其他的系统进行交互 在外部 Web 服务调用是,最常见的方法但它不是始终最好的方法。 一些替代方法可能更容易实现,而它们也可能有的要快很多好处是例如在 LDAP 调用存储通过 Microsoft 目录服务编程框架,或使对通过 Project Server 报告的 ADO.NET 的 Project Server 数据库而非通过 Project Server Interface (PSI) Web 服务层。 当数据源是一个 Web 服务或数据库时, 请考虑使用业务数据目录 (BDC)。

  Microsoft 是非常清楚 其文档应该不进行直接调用 SharePoint 内容和配置数据库。 即使如此,某些应用程序正在使用这种方法。 性能是此访问方法或只需了解 SharePoint 框架缺少该参数,有更安全的方法。

  底线是 Microsoft 可以更改这些的数据库了基础架构而可以有多个内容 data­Base,每个 Web 应用程序。 因此,似乎是良性的直接查询操作导致 brittle 的解决方案。 相反,利用本文列出了其他方法,或者开发避免了会危害您的 SharePoint 实施的完整性的 suboptimal 解决方案的不同策略。

  2.采用本机SharePoint功能的Advantage

  两种情况下可能会导致从利用完整本机功能在 SharePoint 中的开发团队。

  第一次,由于 SharePoint 是这样一个大量的平台,您可能会发现它更便于构建自定义解决方案,而不是花费时间了解 SharePoint 提供不自定义编码。

  第二,业务所有者倾向于创建详细的要求、 wireframes 和应用程序行为,使用现有的 (OOB) 功能时使小的灵活性。

  但即使生成的可交付结果稍有显著从原始的要求使用 SharePoint 平台通常所提供支付股利。 关键获得这种优势是为开发团队进行全面了解该技术并,更是重要清楚地通信值和业务所有者的特定实现的折衷方案。

  获取深入了解优势和 SharePoint 的缺点就变得更容易称为比完成。 同时 WSS 和 MOSS 包括 SDK 包含技术文档、 演练、 代码示例和 SharePoint 中的编程解决方案的非常好的做法。 此外,难找到信息时可以使用.NET Reflector 查找某些核心 SharePoint 程序集内。

  图 2 显示了 Microsoft.SharePoint 程序集包括 IssueQuery 方法中的 PeopleQueryControl 类的成员。 PeopleEditor 控件 (aka 人员选取器) 委托用于查询 PeopleQueryControl SharePoint 的身份存储的责任,并允许重写 IssueQuery 方法以修改默认实现。 可以看到在图,.NET Reflector 可以内部查看组件的交互方式。 



图 2 显示在 PeopleQueryControl 的 IssueQuery 方法的.NET Reflector

  配备了解平台的功能,需要 articulate 给下划线其技术投资的值的利益相关者的特定实现的好处。 与平台 SharePoint 不获取挂断早期有关的实现详细信息而帮助了解是可能通过早释放,并通常迭代客户端的大小非常重要的。 应确保您的客户端通过将一种有效的反馈机制,保留它们占用整个软件开发生命周期 (SDLC) 放在位置是熟悉该产品的功能。

  有关假设讨论 显示给用户的大量列表的实体。 可以与 ASP.NET DropDownList 控件、 GridView 控件、 自定义的控件或第三方控件,如实现此功能多种方式。 SharePoint 本身还提供了在 PeopleEditor 或其基类 EntityEditorWithPicker 控件,您可以使用此该控件中的一个大型的列表选择控件。 这些 Web 控件附带用于将您自己的自定义逻辑的许多挂钩和使用它们利用丰富的、 直观的用户界面在 SharePoint 中创建一致的用户体验。

  显示在 SharePoint 内的业务线 (LOB) 数据是另一个常见的请求。 通常,您首先识别 Gold 源数据的和确定如何最好的数据提取到 SharePoint。 创建 Web 服务代理或建立到数据库的 ADO.NET 连接是旧帽子为许多开发人员。 但是,BDC 可能是一个更好的选择。 此 SharePoint 功能,可以从外部数据源读取数据,并将在 SharePoint 上显示。

  BDC 支持多种身份验证机制,允许您创建数据实体之间的关联,并紧密与 SharePoint 搜索和列表基础结构。

  此外,SharePoint 包含一套用于展示通过 BDC 的 LOB 数据的 Web 部件。 而该 BDC 目前不支持创建、 更新,和删除操作直接,可以创建自定义应用程序执行这些操作,并将它们与通过 BDC 操作界面 BDC 相关联。

  3.知道重要 SPDev 任务和信息

  本节旨在 elucidate 每个 SharePoint 开发人员可能需要完成软件开发过程中的常见任务。 这不在工具检查,也不它旨在通过另一个提升一个工具。 相反,我们提供的用于完成常见的 SharePoint 开发任务的工具的建议。

  构建 SharePoint 解决方案 是您要执行的一个方法。 Ted Pattison 累加它上很好地他 Office 空间列中" 使用 SharePoint 2007 的解决方案部署 "当他写时,"打包设置,以及部署使用解决方案包在 WSS 开发过程 is 非常好的做法是 and 知道如何执行此操作应考虑的基本技能"。 使用 Windows SharePoint Services 3.0 工具的 Visual Studio 项目的有许多种方法打包您 SharePoint 解决方案中手动创建 manifest.xml 和菱形指令文件 (DDFs),: Visual Studio 2005 / 2008 扩展 (VSeWSS)。

  使用 VSeWSS 项目是比手动创建 DDFs 得更容易。 但是,一些替代方法可尤其是用于商业或企业部署,包括 WSPBuilder、 STSDev、 SPDeploy 和 DDFGenerator。 评估各种工具来找到一个最适合您的需要。 关键是手动创建解决方案包部署,而不是部署代码组件。

  调试客户端行为 可以是棘手,并工具 (如 Internet Explorer 开发人员工具栏 (Internet Explorer 8 中的开发人员工具),将使该工作得更加容易。 Internet Explorer 开发人员工具栏与 Firefox 的附件,例如 FireBug 相似。 在 Internet Explorer 中运行的另一个工具是 Web 开发帮助器。 这些工具都用于调试客户端 JavaScript、 检查样式,和遍历该 DOM。

  如果您需要检查与 IIS 交互,IIS 6.0 资源工具包包含的有用的工具的多种。 例如,WFetch 提供便利功能用于检查页输出信息,如自定义 HTTP 处理程序的输出或身份验证标头信息来验证您使用,如 图 3 所示何种身份验证协议。 


图 3 WFetch 显示的 NTLM 身份验证头

  因为错误将被遮盖, 服务器端代码问题疑难解答 很特别难在 SharePoint 中隐藏中等友好 (尽管不很有帮助) 网页或日志以下 Web 服务调用。 最重要的 takeaways 要知道数据 SharePoint 记录,以及何时将使用一个调试器的和熟悉工具,可帮助您解决您的 SharePoint 应用程序。

  试图确定导致一个应用程序的问题时要启动的一个位置是 Windows 事件日志。 在某些情况下,可用于选项增加事件日志。 是例如如果您正在使用 Kerberos 身份验证所依赖的应用程序,可以增加 Kerberos 日志记录到系统事件日志。 有许多极好的联机资源,说明 Kerberos 身份验证。

  SharePoint 和 IIS 日志至关重要疑难解答 SharePoint 应用程序错误。

  IIS 日志上的 <%SystemRoot%> \System32\LogFiles 通常位于。 查看 IIS 以验证日志的根位置的属性。 由于每个 IIS Web 应用程序具有一个唯一的 ID,则将只匹配 SharePoint Web 应用程序日志文件目录下的文件夹名称列出在 IIS 中的 IIS 应用程序 ID。

  自定义应用程序日志,请考虑 Enterprise Library 集成。 通过合并企业库日志记录和异常处理代码中的应用程序块,记录目标,通常是数据库,可以包含对疑难解答您的自定义应用程序的日志记录信息和异常详细。

  用于调试自定义应用程序的问题,最有用工具是 Visual Studio 调试器。 如果您安装在 SharePoint 服务器上安装的 Visual Studio,您将必须 F 5 调试功能。 理想情况下,您不应在生产或模型 Office 系统上安装 Visual Studio。 此外,您可以开发在本地工作站上的软件并远程调试解决方案。 远程调试完全支持在 SharePoint 中连接到承载自定义应用程序在 IIS 中的将 w3wp 进程。

  要确定哪个实例 w3wp 的运行应用程序,打开命令提示符,并在 Windows Server 以标识进程 ID (PID) 运行 SharePoint Web 应用程序中运行 IISApp.vbs。 然后,在 Visual Studio,选择使用匹配的 PID 的 w3wp 的实例。

  另一个非常有用的工具是 异常显示 . 在您的场中启用此工具时, 会替换友好 SharePoint 错误页消息异常显示类型。 有关如何安装和使用此工具的详细信息,单击"异常显示"查看上面列出的链接。
如果已部署的 Web 部件导致页加载失败,来打开 Web 部件维护页附加? 内容 = 1 to 页 URL 的末尾。 在维护页上可以关闭,或从页面中删除有问题的 Web 部件。

  最后,您可以启用 Web 应用程序的 Web.config 文件中的应用程序级跟踪。 请参阅中的讨论" 启用应用程序级跟踪 ."

  不断延长到框架。 SharePoint 都多个能够集成各种方式自定义解决方案。 由于 SharePoint 生成的 ASP.NET 顶部,它将继承此平台的可扩展性。 WSS 3.0 / MOSS SP 1 版本,Microsoft 现在支持 ASP.NET AJAX 框架意味着您可以利用 ASP.NET AJAX Extensions 和 AJAX Control Toolkit。

  您可以轻松安装和配置过程通过在 ajaxify MOSS 自定义 Stsadm 扩展名 以编程方式添加,或通过使用 SPWebConfigModification 类删除 AJAX 相关 Web.config 条目。

  使用就地 Framework,可以使用 AJAX 控件套件,并通过实现客户端回调提高页面的响应。 外部 Web 服务调用自定义 Web 部件中时,则这一特别重要。 请参阅" AJAX Extensions 客户端 Web 服务调用 ."

  jQuery 是注意的另一个客户端框架,出现了大量尤其是注意的对于最新通知 Microsoft 将支持在 Visual Studio 中。 因为 jQuery 核心库一个.js 文件中包含,集成 SharePoint 很简单。 请参阅" jQuery 脚本管理器 "对于 jQuery 脚本嵌入 ASP.NET 网页的方法。

  4.开发解决方案关闭的服务器

  尽可能,您应构建没有依赖项的解决方案的 SharePoint 开发通常实施。 通过使用 Visual Studio Development Server、 ASP.NET Web 部件框架支持、 SharePoint Web 服务和第三方工具,您可以完成大部分开发于标准的工作站而运行 SharePoint 的计算机上。

  因为 SharePoint 运行之上 IIS 和 ASP.NET,随 Visual Studio Web 开发服务器是您的 SharePoint 开发大量的极好起始点。 是例如您可以开发 Web 部件、 HTTP 处理程序和 Web 控件,在此,相对来说轻量的环境。

  一些初始工作参与设置环境来承载您的组件。 是例如来有效地开发一个 ASP.NET Web 组件中,,您应创建承载您的 Web 部件在 Visual Studio Web 应用程序项目一个类项目,并选择一个单元测试项目。 我们已在 Visual Studio SPTips 解决方案 (包含相应的示例代码中) 中包含此设置的示例可以用于非服务器 Web 部件开发的。

  在 Web 部件项目中默认构造函数包含设置 Web 部件的 ExportMode 属性的行: 

public WebPartOffServerExample()
{
    
this.ExportMode = WebPartExportMode.All;
}

  这行可以生成基于的属性中所示为 Web 部件配置.webpart 部署文件 图 4 . 


图 4 </a0>-Web 部件导出菜单选项

  您可以再将 Web 部件导入 SharePoint 通过此部署文件 ( 图 5 )。 不应使用 SharePoint 2003 向后兼容的导入文件类型.dwp。 一个.dwp 基础的 XML 架构不为格式,并要求您将引用先前在 SDLC Microsoft.SharePoint 程序集。 


图 5 导入到 Share-Point </a0>-Web 部件 


  请注意您可以确保创建的.webpart 部署文件通过从 System.Web.UI.WebControls.WebParts 命名空间而不是在 Microsoft.SharePoint.WebPartPages 命名空间的 WebPart 类继承。

  Microsoft 提供 SharePoint 对象模型通过 Web 服务的重要子集。 使用 SharePoint Web 服务访问对象模型允许您开发不直接访问 SharePoint 程序集的依赖的解决方案。 SharePoint 承载 Web 服务,每个 Web 前端 (WFE) 服务器上的 _ vti _ bin 虚拟目录中。
在 Visual Studio,添加 SharePoint Web 服务向解决方案以相同方式像所有 Web 服务引用。 SharePoint Web 服务 URL 具有以下格式:

http://<SharePointServer>:port/[sites/][SubSite/]_vti_bin/WebService.asmx

  其中 <sharepointserver> 是与 Web 应用程序相关联的 URL。 例如:
 
http://www.contoso.com:35000/_vti_bin/Lists.asmx

  将 Web 服务引用进行添加 Visual Studio 将创建服务和服务使用的数据类型的代理类。

  实现一个三层体系结构 furthers 隔离代码,并删除依赖于 SharePoint 和其他外部源的目标。 这种方法可以提高抽象业务、 数据访问和使您能够错误代码分为可管理的部分,并减少它们之间的依赖关系互相的用户界面逻辑开发关闭服务器的能力。 此方法也会产生更多的可测试代码,"测试代码和管理依赖项"一节中对此详细。

  其他工具 可以使用。 在整个基本代码中删除 SharePoint 的依赖是不切实际的。 通常开发 SharePoint 关闭服务器要求通常在 SDLC 早期虚拟机中进行承载 SharePoint 实例的使用。

  与 SharePoint 开发的增长,已处理该重要的依赖项创建几个工具。 一个类工具是竹子解决方案的 SharePoint 在 Vista 安装帮助。 该工具使 WSS 3.0 SP 1 或 Windows Vista,让您能够开发 SharePoint 相关解决方案,而无需 Windows Server 上的 MOSS 2007 SP 1 的安装。

  Microsoft 不支持在这种方式运行 SharePoint。 但是,此方法具有 resonated SharePoint 开发社区中因为它有助于减少在占用此依存关系在 SharePoint 上的创建的。 有关详细信息请参阅" 如何在 Vista x 64 / x 86 安装 Windows SharePoint Services 3.0 SP 1 ."

  5.测试代码,并管理依赖项

  单元测试框架和相关的测试工具的广泛采用到 SharePoint 开发自然了它的方法。 单元测试和集成测试是两个主要的测试类别的。 这两种测试类型表现出不同的特性,,需要使用不同的工具和技术。

  时编写单位 或非服务器测试时,它的视为最好模拟与替换如存根或模拟的外部相关性。 通过模仿外部相关性的对象中的传入,测试成为更快、 更关注您要测试此问题。 要有效,此方法需要您按照可测试的、 面向对象的设计的原则,或为了隔离紧密结合的组件,您的解决方案中使用一个专用的框架。

  确定的行为和独立的基础结构并确保您具有用于在隔离测试这些策略的业务规则。 找出与 SharePoint、 一个的数据库或 Web 服务交互操作,可以引入该存储库模式中抽象出后端系统的详细信息。 通过取反值的控件 (IoC) 和相关性注入 (DI) 原则,可以将这些存储库对象传递到更高级别的组件。

  单元测试处理用 SharePoint 对象模型时,其他主要挑战的 SharePoint 开发人员图标。 简单地说,在隔离测试这些组件是一项重要的任务。 它是有限的数量的接口和抽象以及大量的密封类的直接结果,使用内部的依赖项或不公共构造函数的类。

  配置为处理这些缺点的一个产品是 TypeMock Isolator,用于 mocking 密封、 具体、 静态,或内部构造的类的一个商业 mocking 框架。 对于为适用其他 mocking 框架,必须遵守模式和我们已经有 eluded 到的原则。

  TypeMock Isolator 或其新的 SharePoint 特定于版本的 SharePoint,Isolator 的将解决这些限制,并不依赖于 SharePoint 的运行实例允许更高代码覆盖率。 模式和实践 (P&P) 团队还使用 TypeMock Isolator 在其 SharePoint 指南参考体系结构 .

  有些时候 您将不得不编写依赖于 SharePoint 对象模型的集成测试。 好的做法来管理服务器独立于的单元测试是与服务器相关的。

  可以在 Visual Studio 中使用测试管理器中的测试列表编辑器来分隔您的单位和集成测试。 对于是实例可以创建两个列表的测试: 服务器依赖于和服务器独立于 (参见 图 6 )。 此方法允许您选择的集测试根据上是在服务器上运行。 


图 6 </a0>-测试列表编辑器显示分类的测试列表

  在 Visual Studio 安装在服务器的情况下,可以运行和调试在 IDE 中的测试或运行服务器依赖于测试使用 MSTest.exe 命令行工具。 遗憾的是,MSTest 不运行除非在服务器上安装了 Visual Studio。 我们希望是 MSTest 的未来版本将不包含此大量的依存关系。

  MSTest.exe 可以指定您要通过命令行参数运行的测试。 您在运行 MSTest.exe 则必须指定该 /testcontainer 或 /testmetadata 选项。 通过 /testmetadata 选项可以指定哪些测试将运行。 是例如要运行所有的服务器的相关测试,请键入:

MSTest /testmetadata:SPTips.vsmdi /testlist:ServerDependentTests

 

  若要运行服务器依赖于测试中的特定测试,键入:

MSTest /testmetadata:SPTips.vsmdi /test:GetTasks_ShouldReturnTasks

  6.连续集成和自动的生成

  保存代码在源代码管理中、 依赖于连续集成,和自动执行生成过程是有效版本的高质量代码资产的基本步骤。 SharePoint 使此环境质询,设置至少。 对于此提示,最重要的起始点是在" 团队开发概述 "主题。

  更高版本在概述,将看到 SharePoint 指南主题"如何: 创建与 Team Foundation Server 生成的自动的生成和部署解决方案" 本主题重点讲述如何创建构建和部署解决方案的生成目标。 虽然此方法具有现场,它不使用在 TFS 生成和 SharePoint 服务器不驻留在同一的环境中时通常是在企业。 构建使用目标在解决方案包会限制用于自动的生成环境的包的使用,并因此不鼓励早期开发和测试的开发人员的程序包。

  此替代方法是使用 Visual Studio 中的生成后事件。 可以执行相同的打包步骤,作为 MSBuild 目标,并允许开发人员能够构建程序包部署到其自己的沙箱环境设置生成后事件。 此方法还使用第三方工具 (如 WSPBuilder 和 STSDEV。

  部署到企业时, 可能还需要考虑版本控制解决方案包。 将当前的内部版本在解决方案版本是一个的方法。 这通过使用 AfterBuild MSBuild 事件中或生成后事件运行的自定义应用程序代码简化。 此外应考虑的解决方案 ID 自动的生成并是否生成新的 ID 与每个版本。 此决定会影响您在以后升级解决方案的能力。 作为一般的规则程序集版本更改生成新的解决方案 ID。 否则,保持解决方案 ID 相同的版本 ID 是静态之间生成。

  而不是您可以从获取的重复信息, SharePoint Server 开发人员中心 我们将关注如何进一步简化自动的生成过程的补充此提示。 SharePoint 指南主题中"如何: 使用 Team Foundation Server Team Build,创建自动的生成和部署解决方案"P&P 团队假定您正在使用 VSeWSS / 扩展。

  SharePoint 开发人员工具包如 WSPView 面板,允许您在的动态配置您的解决方案的功能的好除了 VSeWSS 时我们已经发现不适合较大的实现或敏捷开发方法的团队的媒体。

  P&P SharePoint 指南团队文档指出 VSeWSS 提供一键式部署和 F 5 调试。 单击部署功能当然 VSeWSS 的一部分,但 F 5 调试功能有更多处理到您的 SharePoint 的实例必须运行本地的 Visual Studio 的事实。 这是安装 VSeWSS 的要求。 虽然使用并使用获取安装在工作站上的 VSeWSS 注册表黑客时在工作站上安装扩展的好处的大多数会丢失。

  文档还指出很多工具 (如 WSPBuilder 和 STSDEV 要求开发人员能够维护 feature.xml 和 Web 解决方案包中的 SharePoint 解决方案打包的 manifest.xml 文件。 实际上,这些工具不断发展。 例如,WSPBuilder 现在包括允许 feature.xml 和 Visual Studio 2005 和 2008 中的 manifest.xml 易于维护的扩展名。

  在确定如何构造 SharePoint 项目 VSeWSS 后会非常有用。 是例如,可以使用 VSeWSS 项目类型确定 Web 部件或 SharePoint 工作流项目的结构。 一旦您知道如何,考虑该信息并将其移动到无处不项目类型。 VSeWSS 用于大型项目的媒体,主要问题如下所示:

  扩展名被为了在 SharePoint 服务器上运行的 Visual Studio 的实例安装。 因此,它们 WSS 上有一个硬依赖项。

  尚未安装 VSeWSS 开发人员不具有特殊的项目类型 VSeWSS 创建的并且将无法打开依赖于它们的项目。

  重新生成解决方案进行更复杂的 VSeWSS。

  指南文档建议将其他的方法是手动创建 SharePoint 解决方案文件每个 Visual Studio 解决方案、 以及使用部署清单 manifest.xml。 但是,工具 (如 WSPBuilder 允许自动完成您的版本中的此步骤。

  成功的自动生成密钥以是:

  使用标准的 Visual Studio 项目类型 (即,类项目的 Web 部件),,这样所有开发人员可以轻松打开一个项目。

  结构代码项目,以便解决方案打包已集成到在的项目中,如 图 7 所示。 就不需要创建一个单独的部署项目。

  设置生成后事件运行 WSPBuilder 或另一个自动解决方案构建工具来创建 SharePoint 解决方案文件。 此方法适用同时进行本地部署解决方案和自动的生成过程。

  使用宏条件控制被调用,具体取决于正在生成您生成后事件的部分。

  一个自动的生成进一步复杂的 InfoPath 项目中。


图 7 到 Web 部件项目代码集成的解决方案打包结构下载

  不部署 到全局程序集缓存 (GAC) 直到您将移到集成环境上。 程序集保持 BIN 文件夹使调试自定义 SharePoint 应用程序得更容易。 有不适合 (如与 SharePoint 事件处理程序和 SharePoint 功能的此模型的特定项目类型。 通过 BIN 文件夹中放置兼容的程序集,共享的开发环境中的开发人员不必每个部署后 endure 频繁 IIS 重置。

  从该 BIN 运行 SharePoint 的程序集的某些指针是:

  修饰 [assembly:System.Security.AllowPartiallyTrustedCallers] 属性的程序集。

  配置自定义代码访问安全性 (CAS) 策略或将 Web.config 设置为完全信任中,如下所示:

<system.web>
  
<trust level="Full" />
</system.web>

 

  (注意将信任级别设置为完全。 只适用于本地或内部开发的代码的资产将最终部署到 GAC 中) 登录到 GAC 中的最终部署程序集。

  7.具有SharePoint 管理自定义配置设置

  如任何应用程序,SharePoint 解决方案依赖于正常运行的配置设置。 自定义应用程序使用仅几个配置设置可能很容易手动管理。 相反,开发企业或 SharePoint 中的商业应用程序时, 配置设置的该号码可以是相当大。

  为结果了解不同的设置类型以及如何管理这些是开发、 部署,和管理应用程序的重要的。 最好的方法是增加 SharePoint 管理的设置,并减少手动管理。

  了解设置的类型帮助确定这些设置所属。 SharePoint 配置设置通常分为三类: 核心,自定义和 SharePoint 设置。

  在 SharePoint Web 应用程序使用核心设置。 Enterprise Library 应用程序块和外部 Web 服务配置是典型的核心设置的示例。

  自定义的设置是为自定义生成组件。 这些设置用于提供自定义组件的配置设置,并不共享该组件之外。 是例如自定义设置可用于提供的 LDAP 查找的目录服务器设置。

  SharePoint 设置所需使工作在 SharePoint 解决方案。 此类别中的设置包括 SafeControls 项、 SessionState 自定义,或注册 HttpModules。

  分类您的设置后,可以将其部署到右的位置对其进行管理。 目标是减少手动管理。 让 SharePoint 处理设置减少部署应用程序时可能发生的错误数。

  核心设置最在源代码管理中管理。 这允许同时设置提供一个源事实的维护设置历史记录。 此外,这种方法用于维护的开发、 测试和生产环境的配置文件的独立版本。

  可以通过使用 SharePoint 对象模型和部署工具自动执行自定义设置安装和管理。 使用 SPWebConfigModification 类、 解决方案部署和 CONFIG 目录 SharePoint 12 配置单元下以构成您的配置管理策略。

  在 SharePoint SPWebConfigModification 类允许您以编程方式注册 SharePoint Web 应用程序的 Web.config 中的设置。 使用 SPWebConfigModification,可以编写一个控制台应用程序或 Stsadm 扩展列表中,添加,或删除配置项。

  此方法用于快速、 一致的 SharePoint 配置设置的大型集修改。 此类中的 SPWebConfigModificationType 枚举包含三个值指定进行的修改的类型的值: EnsureChildNode,EnsureAttribute,和 EnsureSection。 使用 EnsureSection,因为无法轻松地删除与此枚举添加项目时一定要谨慎。

  在 SharePoint CONFIG 目录允许您以声明方式来维护此目录中的 XML 文件中注册设置。 WSS 于 XML 文件中的设置 web.config SharePoint 创建 Web 应用程序时。 此文件夹中的设置应用于所有 Web 应用程序。

  8.知道位置配置设置属于

  上一个提示说明了不同类型的 SharePoint 配置设置以及如何管理它们。 为应用程序升级到环境,如从测试为生产,对配置设置尤其是那些指向外部系统的更改将可以就像沙滩您英尺下同时移中。 了解配置设置所属可以放更可靠的基本管理环境设置。

  复合应用程序开发 已增加依赖配置设置。 在电源和方便的配置设置的使用有认为导致其过多使用。 减少常量会更改这些设置的一个方法是通过而推断等命名约定中的值应用约定通过配置模式。 演示如何将 SharePoint 解决方案打包集成到您的 Visual Studio 项目的概述在"连续集成和自动的生成"部分的约定通过配置模式的示例。 此范例一个相关的示例显示在 Web 内容提示"使用相对链接尽可能"。

  实例特定设置 都是唯一一个 Web 部件的每个实例。 是例如您可能在程序管理器页显示的项目列表,它在开发人员页上显示项目和任务的详细信息的 Web 部件。 实例特定设置最存储于一自定义工具部分,或者在一个 Web 部件杂项工具部件属性。

  由多个组件使用的 配置设置 被视为全局设置。 此类别中的设置的示例包括外部 Web 服务、 业务对象的设置和数据设置的 URL。 这些设置是非常好的保存在 Web.config 中和管理如"具有 SharePoint 管理自定义配置设置"部分所述。


  9.品牌 SharePoint 的缩放比例和维护

  品牌 SharePoint 网站为应用程序的用途的最明显的 Visual 指示用户提供。 品牌包括页面、 内容页面、 页面布局、 网站定义和 CSS 使用如主控形状的不同项目。

  资源

  Microsoft Office SharePoint Server 2007 和 Windows SharePoint Services v 3

  业务数据目录

  SharePoint 2007: BDC) </a0>-业务数据目录

  WebPart 类 (Microsoft.SharePoint.WebPartPages) 请确保应用程序的缩放和维护策略将考虑如何管理这些产品的项目。

  选择一种工具之前 的品牌,请考虑您的 SharePoint 实现的大小,您产品的工作的专业技术支持应用程序开发人员。 我们将关注两个工具: SharePoint Designer 和 Visual Studio。

  SharePoint Designer 将在 FrontPage 中具有其根,并且是用于编辑母版页和 CSS Web 设计工具。 但是,轻松使用 SharePoint Designer 中提供有代价:

  这里没有集成的源代码控件支持。

  在 SharePoint Designer 将导致修改后的内容成为 unghosted 所做的更改。

  在为 unghosted 的状态内容的副本存储在内容数据库而不是文件系统。 因此,取消重像具有以下效果:

  很难管理,因为内容可以更新只在 SharePoint 或 SharePoint Designer 中的部署

  从更新的内容部署到文件系统断开连接一个站点,导致大,活动的 SharePoint 实现上的潜在性能问题,由于这些原因,我们认为是最合适的 SharePoint Designer 中的实现和原型的小写的。

  Visual Studio 提供一致的开发环境为应用程序组件和品牌的项目,但它缺少图形编辑功能在 SharePoint Designer 中。 因此,开发人员必须编辑 HTML 和 CSS 更 proficient。 必须维护品牌项目设置一个很好的项目结构。 与 Visual Studio 集成的源代码控件支持,容易管理特定于环境的配置和品牌跨多个环境中部署的项目的包。 此外,品牌的项目保持幻像。 因此,Visual Studio 是用于大型企业和商业实现我们首选的 SharePoint 品牌工具。

  有三种方法 应用品牌: 网站模板、 自定义站点定义和 OOB 网站结合通过功能装订的自定义的定义。 创建自定义站点模板,则可能是小型的实现和原型,最快方法。 但是,从模板创建的网站不会更新在上载新模板。 自定义模板不允许您指定模板 ID 将需要对引用模板的任何设置代码。 此外,网站模板创建仅 unghosted 的内容,从而可能影响性能。

  站点定义是更为灵活和便携式比网站模板。 您可以管理站点定义文件 (onet.xml) 和源代码管理中的相关的内容和允许一个网站来它尚未自已定义的新内容更新的情况下部署幻像的内容。 站点定义可能很难创建,因为您需要编辑的 XML 的复杂程度。 此任务更加容易使用 OOB 站点定义 (位于 12\Template\SiteTemplates 作为起始点) 或导出站点定义使用 VSeWSS。

  处理大的实现的媒体组合 OOB 站点定义自定义功能时最好的方法。 功能可用于扩展站点定义,并提供了模块化的方法提供站点。 对于功能一个很好概述查看 Office Space 专栏" SharePoint 的功能 ." VSeWSS 扩展名,以及一些第三方工具提供模板创建产品的网站中使用的通用功能。

  功能装订可以向站点定义附加功能,并创建新的 Web 站点时启用它。 这是要应用您品牌 SharePoint OOB 站点定义的好方法。


  10.构建可部署的解决方案

  可以到 SharePoint Web 应用程序以多种方式来获取您的组件。 此部分集中讲述如何利用 SharePoint 提供包括 Web 解决方案包 (解决方案 / WSPs、 功能和 SharePoint 对象模型在打包和部署框架。

  决定如何包 组件依赖很大程度上部署组件。 解决方案包含将部署到服务器的文件。 功能包含将部署到内容数据库的内容。

  SharePoint 解决方案包含程序集和资源部署到 SharePoint Web 应用程序。 解决方案是压缩、 部署和取消的简单和镜像在多个服务器场中的 SharePoint 解决方案中的文件更新的 SharePoint 句柄。
  可以使用 SharePoint 解决方案,用于 Web.config 修改。图 8 列出了在常见的文件夹位置,受解决方案和它们的内容。 在"12 配置单元"引用 SharePoint 应用程序的根目录或 <%CommonProgramFiles%> \Microsoft Shared\Web 服务器 extensions\12 默认情况下。


图 8 公共文件位置访问从 WSPs 

12 配置单元中的文件夹 包含
\ISAPI\HELP\[LCID] SharePoint 帮助文件。 将您自己的.chm 文件部署到该文件夹 (或一个本地化的子文件夹)
CONFIG Web.config 自定义设置
\ISAPI SharePoint Web 服务 (以及部署自定义的 Web 服务) ; 映射到 /_vti_bin
\Resources 从自定义功能和站点定义访问的全局.resx 文件
\TEMPLATE\CONTROLTEMPLATES .ascx 用户控件 ; 映射到 /_controltemplates
\TEMPLATE\FEATURES 功能,课程的 !
\TEMPLATE\LAYOUTS 常见的网页,映射到 /_layouts
\TEMPLATE\IMAGES 公共网站图像文件 ; 映射到 / _ layouts 图像
\TEMPLATE\SiteTemplates 所有的 SharePoint 站点定义 ; 创建要部署您 onet.xml 自定义网站定义的 <subfolder> \xml
\TEMPLATE\THEMES 所有的 UI 元素在主题中 ; 克隆创建您自己的现有主题文件夹
\TEMPLATE\[LCID]\XML Webtemp.xml 文件定义可用站点定义,; 添加的 XML 文件此处您自定义网站定义
\TEMPLATE\ADMIN 使用中心管理的页,映射到 /_admin
\ADMISAPI 管理 Web 服务,映射到

  下面是记住在使用解决方案的重要规则:

  因为在配置数据库中管理 SharePoint 解决方案,可以有场中的 SharePoint 解决方案只能有一个唯一实例。 这一点如果是很重要您打算使用相同的场到同一 Web 应用程序的主机不同的版本) 是例如同时当前的维护和将来的开发环境。

  SharePoint 解决方案通过跟踪 ID 不是按名称,因此您需要维护源代码管理的解决方案 ID,如果您打算在以后升级解决方案。

  在 12 个配置单元是一个共享的 Web 应用程序空间。 如果您打算承载相同的场中的多个 Web 应用程序,您需要确保 SharePoint 解决方案不会覆盖现有的 SharePoint 文件或部署的其他解决方案在此位置中的文件。

  解决方案不能部署中列出文件夹以外的文件 图 8 包括该 Web 应用程序如 wpresources、 全局 _wpresources 或 12 配置单元以外的其他文件夹下的文件夹。

  解决方案不能部署 SharePoint Web 应用程序内的内容。 这就是 SharePoint 的功能角色。

  功能可以使 Web 部件库中可用,上载和将文件发布到文档库并执行自定义的操作,例如使用功能接收程序集设置站主题或默认母版页。 查看有关使用右侧品牌上文有关使用功能的品牌信息中的技术,信息。

  以下是用于创建功能的一些忠告:

  功能不跟踪添加的内容,因此,该功能以停用通过功能接收器时清理后本身的责任。 请考虑功能和是否内容部署功能可能需要的 Web 应用程序的其他部分中删除内容之前的整个生命周期。 是例如删除母版页停用的一项功能将会中断继承的母版页的网页。

  删除解决方案使用部署功能之前,停用从所有的 Web 应用程序功能。 如果您不,解决方案部署将失败,如果已删除功能文件夹,您需要强制功能使用 STSADM 的卸载。

  其他提示

  以下是有关开发 SharePoint 解决方案的一些其他提示。

  使用相对链接尽可能

  请考虑使用相对链接,而不是绝对链接。 包括到文档库、 数据连接和报表库的位置的相对链接从一个 SharePoint 实例之间简化部署。 报告库示例记住,如果在使用一致的 Web 位置对报告库所有您的 SharePoint 环境,您 ’ll 不再需要指针更改为报告,您的应用程序从一个环境移到下一个。 通常,通过配置的约定适用于代码配置,但此概念可以还松散应用于部署其他配置方面。

  在相关的通知单上我们希望 Microsoft 将支持在当前某些配置设置需要绝对链接在 SharePoint 平台内的相对链接。 是例如必须指定到表单库的绝对 URL L 的 InfoPath.udcx 数据连接文件) 中,,而且重 ReportViewer Web 部件需要到报告定义的绝对路径。

  创建自定义主控页

  与您的外观和体验的品牌 SharePoint 网站的一个常用方法是网站的创建自定义的母版页,使您可以在大多数控制您的布局。 可以采用现有的 SharePoint 母版页,并修改它以满足您的需要。 如果现有的母版页是接近于所需的布局,这种方法的效果非常好的。 如果外观所需的任何 OOB 母版页非常不同,可以 inclined 从零开始启动。 但是,因为 SharePoint 需要母版页中的某些功能,它 ’s 建议开头为最小的母版页,并生成从那里在外观和感觉。

  处理中的自动生成的 InfoPath 项目

  在 Microsoft InfoPath 设计器创建的项目将进一步质询您自动生成的工作。 在让的最可以真正执行 InfoPath 和 SharePoint 处理包装。

0
相关文章