我应该以1-1比例保持解决方案和功能吗? [英] Should I keep solutions and features in a 1-1 ratio?

查看:130
本文介绍了我应该以1-1比例保持解决方案和功能吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个复杂的sharepoint部署与多个EventReceivers和工作流。



我还对现有列表进行模式更改,添加新的元数据列和更改现有列。



我应该将单个功能,事件接收器或工作流程包装到单个解决方案中,还是应该将单个解决方案中的多个功能集成在一起?



我要求的一个主要原因是进行未来的代码升级。如果功能被分离,则代码的一部分中的升级不需要重新部署解决方案中的所有功能。这是我应该担心的还是stsadmin -o升级解决方案是否解决了升级具有许多功能的解决方案的任何问题?



让我知道这对任何SharePoint大师都是有意义的。



谢谢,

Keith



更新:
看网站 drax 引用,我发现这个参考站点: http:// msdn .microsoft.com / en-us / library / aa543659.aspx



此语句似乎对解决方案中的功能进行升级有很大的障碍:


解决方案升级只能用于
替换文件。您可以在解决方案升级中添加新文件
并删除旧的
版本的文件,但是您不能
安装功能或使用Feature事件
处理程序来运行Feature $ b的代码$ b安装和激活。
以下操作在解决方案升级中不支持




  • 删除新$中的旧功能b $ b版本的解决方案。


  • 在解决方案中添加新功能
    升级。


  • 更新或更改
    新版本的解决方案中现有功能的接收器
    程序集。


  • 添加或更改特征元素
    (Element.xml文件)在新版本
    的解决方案。


  • 添加或更改功能
    $ b解决方案的新版本$ b属性。


  • 更改旧
    的ID或范围新版本的一个
    的解决方案。


  • 在新版本的
    中删除要素元素
    (Element.xml文件)。


  • 删除新的
    版本解决方案中的功能属性。



所以...可以你做解决方案升级吗?

解决方案

我建议反对将所有内容分解成多个解决方案。维系可以很快变成噩梦。尝试构造您的项目,它应该用于创建WSP,与共享点的12个文件夹相同。然后,您可以使用 WSP构建器,最后一个稳定版本带来了大量有用的东西。



此外,我没有注意到重新部署解决方案的任何问题。根据这篇文章和我的经验部署WSP照顾版本之间的同步所以如果你添加一些新的功能,他们会出现,如果你删除/更改功能,他们将相应修改。



EDITED: p>

所以我做了一些关于MOSS更新主题的快速研究。根据MS,有两种更新方案:


  1. 就地更新

  2. 增量更新

基本上,就地更新是标准的更新方式。这意味着您依赖于中所述的内置功能(文件相同的文件)。这个解决方案的问题是它缺乏相当多的功能(版本控制,更改ID的功能,...)。



增量更新(这是MS调用它可能)不依赖内置解决方案。这意味着每个人都要自己实现:(更好的是,我没有真正找到这个方法的指导方针,我想你想要的方法是增量更新的例子(将项目分解为许多独立解决方案)。



另请注意,增量更新不是MS正式支持。



所以我真的知道我应该给你什么建议,单一的WSP比他们更加坚固,如果你只是做一些小的更改更新工作,但是如果你需要做一些更大的结构变化,问题就会开始显现。



我可能会等待,看看有更多MOSS专业知识的人是否可以说出这个话题。


I have a complex sharepoint deploy with multiple EventReceivers and Workflows.

I also have schema changes to existing lists, adding new columns of metadata and changing existing columns.

Should I package a single feature, eventreceiver or workflow, to a single solution, or should I put multiple features inside the single solution since they all work together?

One major reason I am asking is for future code upgrades. If the features are seperated, then an upgrade in one portion of code would not require a re-deploy of all the features in the solution. Is this something I should worry about or does the "stsadmin -o upgradesolution" take care of any issues with the upgrade of a solution with many features?

Let me know if this makes sense to any SharePoint gurus out there.

Thank you,
Keith

Update: Looking at the website drax referenced, I found this reference site: http://msdn.microsoft.com/en-us/library/aa543659.aspx

This statement seems to put a large handicap on upgrading features in solutions:

Solution upgrade can only be used to replace files. You can add new files in a solution upgrade and remove old versions of the files, but you cannot install Features or use Feature event handlers to run code for Feature installation and activation. The following operations are not supported in solution upgrade.

  • Removing old Features in a new version of a solution.

  • Adding new Features in a solution upgrade.

  • Updating or changing the receiver assembly for existing Features in a new version of a solution.

  • Adding or changing Feature elements (Element.xml files) in a new version of a solution.

  • Adding or changing Feature properties in a new version of a solution.

  • Changing the ID or scope of old Features in a new version of a solution.

  • Removing Feature elements (Element.xml files) in a new version of a solution.

  • Removing Feature properties in a new version of a solution.

So... What can you do with a solution upgrade?

解决方案

I would advise against splitting everything into multiple solutions. Maintaing that can quickly become nightmare. Try to structure your project, which should is used to create WSP, in same manner as 12 folder of sharepoint. Then you can use WSP builder, last stable version brings a lot of useful stuff.

Also i've not noticed any problems with redeploying solutions. According to this article and to my experience deployment of WSP takes care of synchronization between versions. So if you will add some new features they will appear and if you remove/change features they will be modified accordingly.

EDITED:

So I did some quick research on MOSS Updating topic. According to MS there are two ways of updating solutions:

  1. In-place update
  2. Incremental update

Basically, in-place update is standard way of updating. Meaning you are relying on build-in functionality as described in this (same document as posted before) document. Problem with this solution is that it lacks quite a lot of functionality (versioning, changing of ID's of features,...).

Incremental update (this is how MS calls it probably) don't rely on build-in solutions. That means it is up to everybody to implement it by themselves :(. What is even better I was not really able to find any guidelines for this approach. I suppose that approach you would like to take is example of incremental update (splitting project into many independent solutions).

Also note that Incremental update is not officially supported by MS.

So I don't really know what advice should I give to you. Single WSP is more maintanable than buch of them, also if you are doing just some minor changes updates work perfectly. But if you need to make some bigger structural changes problems start to show.

I'll probably wait and see if people with more MOSS expertise can say something about this topic.

这篇关于我应该以1-1比例保持解决方案和功能吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆