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

4条评论:

匿名 said...

如果您的工作流程包含DelayActivity,则DEPLOY QUICK本身将无法正常工作。必须重新启动SharePoint Timer Service,以使其包含DLL的旧副本的缓存得以刷新。到过那里。曾经是那个的受害者。 :-(

克里斯·奥'Brien说过...

有趣的陷阱,谢谢你的提示。

克里斯。

匿名 said...

好让人知道。

拉里·维登(Larry W.Virden)说过...

早上好!我正在与今天早上讨论此问题的开发人员合作。在他上载表单模板的某几天,该模板大约需要3分钟才能进入中央管理员。今天早上,整个过程耗时超过30分钟。

我们使用MOSS SP 2007 Service Pack 3作为平台,而他使用InfoPath 2007兼容模式下的InfoPath 2010作为开发工具。

是否有人对加快模板上传到中央管理员的过程有其他想法?