2008年4月29日,星期二

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

这是上周在办公室里提出的,我认为值得讨论。在我们拥有的一个项目中,页面布局使用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中引用程序集是一种更好的方法。

2008年4月20日,星期日

你做的五件事'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)在写自己的书《曼联毁了我的生活'。但是,我很高兴读到塞拉利昂某处显然有整个曼彻斯特市球迷村!

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

2008年4月14日,星期一

加速您的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开发的技巧,我很想听听...

2008年4月6日,星期日

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

所以我的工具 的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处理此修补程序的情况,非常感谢:-)