商业SharePoint产品版本的解决方案/功能

假设您正在为SharePoint创建一个商业产品。本产品将提供社区版（免费）和企业版（付费）

Community edition的代码库是一个子集，其中包含所有通过（C#）define语句处理的次要增量。实际上，它是一个单一的代码库。构建过程构建两个解决方案（每个解决方案包含两个功能），每个版本一个

不可能同时在服务器场中安装这两个版本。当前的业务模式仅为单服务器SharePoint场提供社区/免费版本。这是为了支持个人和开发场景

这些解决方案包括各种功能元素，但目前没有web部件。将来的版本中可能包含一个或多个web部件。从长远来看，任何限制解决方案/功能内容的方法可能都不是最好的主意

---

您将在多大程度上跨版本重用解决方案和/或feaure ID？为什么？

我希望人们能够轻松地从免费升级到完全升级，如果他们选择这样做的话

想象一下一个web部件的情况——如果您设置了几个免费web部件版本，然后取消安装并安装完整的web部件，那么大多数人都希望所有现有实例都能继续工作，但不能在新的web部件上工作

我想你需要保持解决方案不变，这样才能起作用

您还需要具有相同的完整程序集名称（文件版本可能不同）或设置绑定重定向

---

哦-当然，您的代码中没有破坏性的更改。

我将使用相同的id，并提供一个额外的功能来解锁企业功能。 此功能包含额外的DLL、web部件、许可证密钥等。。。需要解锁企业版

---

我将确保用户在升级后可以继续使用您的产品，而无需更改其自定义设置。

谢谢您的回复。您关于所需升级行为的逻辑很有道理。解决方案的设计方式和您描述的升级行为都可以通过这两种方法实现。还有其他原因吗？您确定如果SolutionId更改，SharePoint将加载新的web部件，而不是用户已设置的旧web部件吗？我猜不会，你会得到“缺少程序集”错误，但还没有时间检查。这是一个有趣的问题。Web部件绑定到强名称程序集。正如您所建议的，我必须检查功能或解决方案级别是否有额外的绑定。关键是要使升级变得容易，而不会“丢失”任何东西。通过附加功能进行升级的模式可能非常引人注目。例如，对于SharePoint 2007中的标准搜索控件和企业搜索控件，这非常有效。在其他情况下，例如事件接收器，这可能需要更多的努力。谢谢你的回复。