在页面布局中引用程序集时的注意事项

这是上周在办公室里提出的，我认为值得讨论。在我们拥有的一个项目中，页面布局使用ASP.Net Register指令引用包含我们的控件的程序集。所以我们在代码中有几个指令类似于：

<%@ Register TagPrefix="psw" Namespace="OurCompany.OurClient.SharePoint.WebControls" Assembly="Parity.SharePoint.WebControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=00000000000000" %>

这些功能旨在告知页面布局有关控件组件的信息，并确保设计人员可以向我们提供控件及其成员的Intellisense。

然后出现的问题是"当我们更新共享程序集并想要增加版本号时会发生什么？当然，我们不必更新和重新发布所有页面布局吗？"有两个答案：

• 我们 可以 在应用程序配置中使用程序集重定向以避免更改页面布局。然后，这些条目将告诉.Net每当请求版本1.0.0.0时就加载（例如）程序集的版本2.0.0.0。这会起作用，但是这意味着在后续程序集版本中添加的任何新成员/更改成员，我们都不会获得Intellisense。


• 我们也可以避免以这种方式完全引用通用程序集，而将引用集中在web.config中

因此，而不是在每个页面布局中都有一个条目，web.config的“页面”部分（在.Net 2.0及更高版本中）使我们可以在一个中央位置引用包含控件的程序集，这意味着对程序集名称的任何更改都易于实现。实行：

<pages>
  <controls>
    <add tagPrefix="psw" namespace="OurCompany.OurClient.SharePoint.WebControls"
         assembly="OurCompany.OurClient.SharePoint.WebControls, Version=1.0.0.0, Culture=neutral, PublicKeyToken=00000000000000" />
    <!-- also works with short assembly name -->
    <!--
    <add tagPrefix="psw" namespace="OurCompany.OurClient.SharePoint.WebControls"
         assembly="OurCompany.OurClient.SharePoint.WebControls" />
    -->     
  </controls>  
</pages>

[旁注]-正如我在注释中指定的那样，可以用短名称引用程序集，但是具有定义版本控制策略的商店将希望避免这种情况，因为那样就不可能具有并行版本的程序集，这是.Net引入的基本前进步骤之一。

然而，这还不是全部。 不幸的是，SPD不够灵巧，无法解析web.config中的程序集引用来提供Intellisense。 我最初以为是，但是but关闭并重新打开表明，实际上已经缓存了某些内容。 视觉工作室 具有足够的意识（如果我们处于纯.Net场景中），但没有SPD。

因此，就我所知，这是一个折衷方案-在页面布局中使用@Register指令（在其中带有版本号），或者在web.config中引用但失去Intellisense。

我想知道是否可以在@Register指令中使用简短的程序集名称，但是在web.config中提供了一个四部分的程序集名称，以便在运行时使用。不幸的是，这是行不通的，因为.Net将其视为模棱两可的注册。因此，如果您希望将程序集版本号保留在页面布局之外，而又保留Intellisense，则一种策略可能是在发布过程中删除@Register指令。

还是作为替代性的最终想法-更重要的是，开发过程中的Intellisense或在发布时将问题最小化？为了我的钱，在SPD中丢失Intellisense给控件带来的不便是一个小麻烦，因此在web.config中引用程序集是一种更好的方法。

你做的五件事't know about me

因此，在开始整整一年之后， 仍然 继续-我的伙伴 罗宾·梅尔é has tagged me 写一些你对我不了解的事情。我认为由于我还没有这样做，所以我很少写任何关于个人的东西，我会做一个例外并做到这一点-这样就可以了。我想我实际上应该写8个事实，但是5个对我来说似乎足够了:-)

1. 我是 完全地 沉迷于早餐麦片！
   
   我特别喜欢牛奶什锦早餐，在过去的10年中，每天不离开家每天至少要经过两个大碗。那些让我使用Messenger的人可能会从Chris O'Brien那里知道：ICerealizable标签（开发者的笑话：-)）奇怪的是，我的女友Suzanne是一家有机牛奶什锦早餐公司的买家，因此能够带回许多免费的东西，呜呼！几年前我们见面后不久，我记得在酒吧里我的朋友问她做这份工作-当我告诉他们时，他们不相信我;-)
   
   
2. 我曾经是一名竞技自行车手。
   
   在我十几岁的时候，我的生活主要是骑自行车。当我在18岁左右达到巅峰时，我赢得了很多比赛，并且进入GB团队也不过一步之遥。不幸的是，由于几次比赛中撞车事故以及发现女孩和酒吧的失败，我的体育事业被缩短了。猜猜我可能没有达到最高水平所需要的奉献精神。
   
   
3. 我偶然进入计算机。
   
   我学习的是商务（和法语！），而不是经典的计算机科学学位。第三年是“工业界的一年”，我谈到了进入大型蓝筹股IT部门享有声望的职位。我讨厌我不了解该技术（IBM AS / 400），每个人都说我不懂的语言。在经历了五个月的不幸之后，我突然意识到，如果我投身于它，我可能会理解它，如果我理解它，我可能会喜欢它。我每天晚上学习OS / 400，Query 400，JD Edwards等，而2或3个月后，我绝对喜欢它。我不想在今年年底重返大学，当我的雇主说我在那里总会找到工作时，我很受诱惑。
   
   
4. 我爱旅行。
   
   我的背包旅行日可能已经结束，但我很幸运能够环游南美，大洋洲和亚洲。最近的一次旅行是一年多以前的尼泊尔单人旅行，我跋涉到安纳布尔纳峰大本营，该营地用于该地区的登山探险。在更高的高度，它降至-16 °晚上是C，当然，晚上住所的简易小屋也没有热量！那些夜晚的狂风呼啸着上厕所的日子令人难忘。   
   
   
5. 我是曼彻斯特城的忠实粉丝。
   
   尽管我在伦敦生活了很多年，但我将始终支持曼彻斯特的“另一支”球队，无论好坏，这都是我父亲传下来的。如果您与曼彻斯特的许多人交谈，他们总是会告诉您真正的曼昆人支持曼城。不幸的是，这经常是一种失望的爱好，科林·辛德勒（Colin Schindler）在写自己的书《曼联毁了我的生活'。但是，我很高兴读到塞拉利昂某处显然有整个曼彻斯特市球迷村！
   

那就是我。我想标记我不认为这样做的其他一些人是：

• 文斯·罗斯威尔
• 本罗布
• 安德鲁·伍德沃德
• 扎克·史密斯
• 米哈伊尔·迪科夫（Mikhail Dikov）

加速您的InfoPath托管代码开发

像大多数开发人员一样，我一直在寻找加快代码/测试/获取反馈周期的方法。在SharePoint开发中有很多方法可以做到这一点，我想一个典型的例子就是 应用程序池回收 而不是完整的IISResets。同样，花时间在SharePoint中进行Visual Studio / WF工作流开发的任何人都希望能够在构建脚本MS供应上发现DEPLOY QUICK参数-这将只是GAC更新的工作流程序集，而不是执行工作流的完整部署解决方案/功能。仅此一项就可以节省大量工作流程项目的时间。

使用具有托管代码的InfoPath表单时，我们需要部署为管理员批准的表单，而不是直接发布到列表或内容类型。该过程是：

• 将表单发布到文件系统
• 通过Central Admin中的“管理表单模板”上传表单

在后台，最后一步实际上将.xsn表单和关联的程序集包装在“解决方案和功能”中，并在整个服务器场中进行部署。可以理解，这是用于开发的S-L-O-W，因此我开始研究加快开发速度的方法。有趣的是，程序集没有部署到GAC或Web应用程序bin目录，而是仅驻留在Feature的文件夹中（单击图像放大）：

但是，除了发布表单，我们还可以执行以下操作：

• 编译VSTA / VSTO项目
• 在Feature文件夹中的副本上复制.dll（如果处于调试模式，则复制.pdb）
• 回收应用程序池

然后将加载更新的代码。请注意，由于我们仅将更新的代码部署到本地计算机上，因此仅会影响本地计算机上的表单会话（我假设您在开发人员中未使用负载平衡的URL）-这有一个不错的方面-将更改与服务器场中的其他开发人员隔离开来的效果，直到您准备发布它们为止。

我想知道InfoPath是如何在运行时完成从此位置加载程序集的技巧-我的web.config中没有自定义的“探测”条目（指示.Net来探测程序集的自定义位置的指令），所以我我假设它是通过反射完成的。

如果您有自己不常见的加快SharePoint开发的技巧，我很想听听...

成功使用内容部署向导的食谱

所以我的工具 的SharePoint内容部署向导 现已开放一段时间，我一直在监视反馈和人们密切关注的问题。当前版本被标记为“ beta 2”，但我对当前代码库的稳定性感到满意，因此可能会很快将其重新标记为“ release 1.0”（遵循有关beta标签心理方面的一些反馈意见：-） ）。

只有少数人提出了问题，并且所有问题几乎都与该工具使用的基础Microsoft代码有关，而不是向导本身。我对此可能应该感到高兴，但实际上，如果有人从该工具中获得错误，那实际上并不重要 为什么 它发生了。好消息是，看来Microsoft终于在其结尾处整理了Content Deployment API的一些问题。这是我的指南清单中的关键点，我会向任何遇到向导错误的人提供指导。请注意，前两个同样适用于使用Central Admin的标准内容部署的使用：

提示1-Service Pack 1和修补程序很重要

Service Pack 1解决了内容部署的许多问题。不幸的是，它还破坏了一些以前通过SP1之前的修补程序修复的问题。我花了一段时间才意识到这一点，但是确实是这样。在这方面，最常见的问题可能是“违反主键错误。有报道说，可以通过修改某些库上的版本设置来解决此问题，但是MS现在最近才发布了一个修补程序，该修补程序似乎可以很好地解决SP1环境中的问题。目前，这仅是通过特殊请求-所需的KB为KB950279。这个 论坛主题 讨论这个问题，对我们有用。有趣的是，我在SPC2008上与Tyler Butler（内容部署程序经理）进行了交谈，他表示SharePoint中的“内容部署”可能会“在未来30至60天内变得更加稳定”。我猜这个修补程序就是他指的，或者至少是其中的一部分。

提示2-始终从 一个空白的网站模板 从STSADM创建的空站点-o目标上的createsite

目前，官方指南指出，内容部署要求已经从“空白”网站模板创建了目标网站-有关详细信息，请参见 KB文章923592。但是，Stefan在下面的评论中详细介绍的一种更好的方法是创建一个 空的 使用STSADM -o createsite命令创建站点。这与从空白模板创建的网站不同，这是创建将使用Content Deployment或向导的网站的最安全方法。这意味着，即使您要基于开发中的发布站点模板创建站点，也应以这种方式创建希望将内容部署到的任何其他环境。值得注意的是，对于发布站点，也不应为首次部署启用发布功能-当第一次部署发生时，将为您解决。否则，您将收到相同的“对象已存在”错误。

提示3-注意“保留对象ID”选项

通常，这里的正确选项是选择您确实要保留对象ID，并且应该从第一次部署开始就完成-唯一的例外是将网站/列表移动到站点结构的不同部分（重新创建）。不过，请务必注意，如Stefan在他的建议的“推荐”中所述，将Content Deployment或向导与STSADM导出/导入混合使用可能会引起问题。内容部署和迁移API-避免常见问题的帖子。

“向导”中提供的选项的更全面说明可在“使用SharePoint内容部署向导'。还请注意，就工具而言，它不是- 除了项目级重定级和增量部署之类的额外功能外，我还希望重构代码，以便可以从命令行编写向导向导。

特别感谢我的同事Nigel Price处理此修补程序的情况，非常感谢:-)