2010年3月8日,星期一

超越F5部署-我的SharePoint的Visual Studio 2010工具的五大优点

我已经使用VS 2010 Tools for SharePoint已有一段时间了,我认为应该停止并超越F5部署/调试的标题,并考虑一下 其他 这些工具的各个方面将改变开发人员的工作方式。这个帖子是 ’旨在成为工具的演练– 其他人已经做到了,还有我’假设你们中的许多人现在已经对工具的功能有所了解。相反,您可能应该将此帖子视为‘editorial discussion’。因此,除了“Visual Studio现在可以构建WSP”,这是我的一些事情’ve been pondering – I’d如果您有任何想法,请感兴趣:

  1. SharePoint开发人员具有全球一致性的可能性:

    就我个人而言’ve seen a SharePoint 2007开发项目上使用的不同方法。当您将WSPBuilder,STSDev,SPVisualDev,SharePointSUSHI,WSeWSS和MSBuild脚本视为构建Visual Studio项目和为SharePoint 2007构建WSP的流行方法时,您开始意识到到底有多少变化。大多数人都同意WSPBuilder最终是最受欢迎的,但是几乎所有这些工具都以某种方式为2007年的开发带来了好处。但是,不要’您是否曾经希望SharePoint项目之间的工作更加一致?这样,当您移至已经完成一些工作的下一个客户端/项目时,就没有VS项目构建的加速时间,因此您(以及该项目中的每个新开发人员)都可以专注于功能? 

    我认为新工具可能会提供此功能。当然,总会有一些变化(例如,带有工具的项目仍然可以采用不同的结构,有些人将继续使用WSPBuilder / a“运行时文件位置” approach), but I’d期望这将大大减少。恕我直言,那只能是一件好事。

  2. 可扩展性(例如,生产力附加组件):

    2010工具最令人印象深刻的事情之一就是它的可扩展性。我们’我们已经看到社区产生了很棒的附加组件,我们’仍然只在测试版中。伟大的事情 这些 扩展是它们补充了MS工具,因此在增强开发人员体验的同时,’re all 添加剂 –基本面没有改变,因此上一点中描述的问题不应该’申请。到目前为止,出色的附加组件是由 SharePoint社区工具包:Dev工具 (CKS:DEV)-我’我已经可以’t live without the ‘quick deploy’SPVSX的功能(在编写本文时已合并到CKS:DEV中的组件之一)。通过提供以下选项来自动复制GAC / BIN程序集以及将未编译的文件(例如.ascx,.js,.css,图像)复制到SharePoint根目录,此宝石可以极大地加速SP2010反馈循环。 保存 (如果曾经使用过,则类似于SPVisualDev)。这是 许多 速度比F5部署快,并且坦率地说,我认为它将成为SharePoint 2010开发的WSPBuilder:  

    SPVSX_QuickDeploy 

    回到一般的可扩展性,另一个喜欢的是可定制的部署步骤–因此,例如,如果您想要一个可拆除并重新配置网站集的部署配置(例如,因为您正在测试配置代码),则可以创建一个这样的步骤并将其包括在内。
     
  3. 功能构建/重构支持:

    在SharePoint 2007开发中,一些社区工具可帮助您构建功能 在某种程度上。其中一些具有项目项模板,这些模板将使用一些默认XML来帮助您入门。但是,当涉及到 重构 功能,基本上是在不支持的情况下剪切和粘贴了许多XML。我认为它’在某个时候必须在团队开发中做到这一点很常见-我’我刚刚在当前项目中进行了一次大型练习,但是通常以与重构代码相同的方式来重构功能。我对Visual Studio工具的喜欢是,当您将元素移动到不同的功能中以及将功能移动到不同的解决方案中时,很多事情都得到了解决。作为示例,在移动时无需进行XML修改即可解决以下旅行/获取问题:

    -功能接收器
    -功能资源
    -功能属性

  4. 解决方案构建/重构支持:

    所以除了 特征 考虑因素 暂时考虑一下。在SharePoint 2007开发中,如果您有10个Visual Studio项目,但没有’不想10 .wsps(为什么呢?),事情变得棘手。实际上,您需要将文件合并到1个或2个项目的SharePoint根目录(12个配置单元)中,并从那里构建一个.wsp文件。–许多团队正在使用这种技术。我首选的解决方案是 使用MSBuild在编译时复制文件,但是构建后事件也可以正常工作。无论哪种方式,设置起来总是很痛苦。我喜欢VS2010工具的一件事是,您可以以图形方式选择每个.wsp中包含的内容。–在下图中,左栏中的项目是解决方案中的资产(即 任何 VS项目),右列中的项目位于当前VS项目的.wsp中。我只是使用UI在每个项目中添加内容–因此,我可以轻松地以任何方式分解.wsps: 

    解决方案要素

  5. 解决部署冲突

    2010 SharePoint项目系统的最终好处是解决部署冲突。这是‘内置智能’用于处理部署冲突,例如在重新部署开发站点时如何处理开发站点上的现有列表。另一个示例是.webpart文件,该文件定义了Web部件’s properties –就像使用‘Module’ element, this is 默认情况下停用功能或撤消解决方案后删除。在开发中,这将导致问题,因为对此文件的更新不会反映在站点上 –使用VS2010工具,可以在部署过程中通过“部署冲突解决”来解决此问题(以及许多其他部署冲突):

    解决冲突
    一件很酷的事情是,您可以将其设置为提示您,而不是每次都使用默认行为– useful if you don’在每个部署/调试迭代中都希望有相同的东西:

    部署冲突 
    有了这个可以做一些操作 许多 更简单–更改Web部件的名称不再需要您查找和删除图库中现有的.webpart文件,例如,它’全部为您处理。甚至更好的是,整个过程是可扩展的,并且可以构建为实现某些工件的自定义分辨率。

因此,对于SharePoint开发人员而言,这些工具是一个巨大的飞跃。我当然有’我列表中提到的是,开发人员现在可以控制 任何 文件中的解决方案,而不是一些‘owned’通过该工具(如在SharePoint 2007的VSeWSS中一样),但希望您已经知道这一点。我确实觉得‘quick deploy’CKS提供的附加组件几乎是一个‘mandatory’需要快速工作的事情,但是’证明可以像这样的增强功能进行扩展的可扩展性。期望有更多这样的附加组件浮出水面(并且很有用)。

I’我期待在未来一两年内看到这对SharePoint开发格局的影响。

5条评论:

李查理说过...

克里斯,通过VS接口重构WSP内容对我来说是一个巨大的优势。以我的经验,既要在项目中设置构建后的构建/ MS Build脚本,又必须向开发团队解释安装过程,并确保他们了解构建的影响以及最终的结局是什么......好吧,就说那里节省了一些时间!

未知说过...

嗨,这些工具可以用于SharePoint 2007还是仅用于2010?

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

害怕'project system' is for SharePoint 2010 only. It would be possible to use VS2010 with SharePoint 2007 but *not* use the 项目系统 (and indeed 卡斯滕 已创建 WSPBuilder 2010 对于此类用法),但是除非您将某些功能纳入WSPBuilder中,否则您将赢得'无法利用我在此处列出的一些好处。

克里斯。

柯克·埃文斯(Kirk Evans)说过...

我开始看到SharePoint开发人员参与整个Visual Studio Ultimate产品的能力是多么巨大。体系结构图,集成的工作项和报告(用于耗损和需求),UI测试和代码分析非常庞大,并且随着社区通过可扩展性添加新功能,这些价值才变得更大。遗憾的是,在过去一年中我一直在谈论和使用SharePoint 2010和VS2010之后,这才让我感到震惊。

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

@柯克

同意,Visual Studio很大,我也在那里's a lot there I don'还没有足够的了解。那'您的清单很不错-UI测试对我来说很棒'd还添加了持续集成功能'd想花时间在一起。

真可惜's a blocker (can'别忘了将IntelliTrace与SharePoint项目结合使用的想法。

克里斯。