我有一个网站，它有很多（大约20个）web部件。每个部分都有自己的Visual Studio解决方案。有人问我如何将这些web部件合并为更少的WSP。
我想知道的是围绕这个问题的做法是什么。我可以看到每个四月的利弊：
PROs:
-要管理的WSP文件较少
-将通用或类似功能整合到单个解决方案
-更容易找到你想得到的-更少的项目
CONs:
-更改一个web部件需要重新部署整个WSP，这意味着所有其他未受影响的web部件（这是真的吗？）
-部署不需要接触的代码的风险
似乎赞成大于反对，但这些都是相当大的反对。
更新 决定合并项目，但原因与列出的略有不同：名称空间。总的来说，这些项目都是独立的，尽管它们是同一个"站点"产品的一部分。然而，没有任何东西是以名字命名的。
因此，我们决定将项目命名为company.application.funciton.feature风格。一旦完成，将几个项目合并到以名称命名的.NET解决方案中似乎很有意义；因此，在许多情况下，只需将部署的程序集命名为"根"名称。
您的利弊列表非常好，但它们是基于完全独立的Web部件。我发现我经常创建一个或多个相互关联的Web部件，从而共享一些代码。将这些网络艺术放在一个单一的解决方案中会带来立竿见影的好处。
在实践中，你的两个骗局都不是真正的问题。当你只想更改一个web表单时，这类似于担心重新发布整个ASP.NET web应用程序
因此，随着Cons的退出，这个决定变成了一个方便的决定。对这些Web部件最方便的分组是什么。一些简单的区分是关于每个Web部件的目标，例如农场与解决方案。更简单的描述是围绕特定网站集Web部件的目标。
总而言之，我想决定对Web部件进行分组将比决定将哪个组进行更容易。
对于我的2c价值，我发现使用更少的解决方案更简单。您也会让SharePoint管理员更高兴，因为部署更改所需的时间更少。
如果你使用某种形式的源代码控制机制，你可以很容易地跟踪代码的更改，这有助于你列出的CON之一[部署不需要接触的代码的风险]。