Dynamics 2011 - 我的基础库解决方案中应包含哪些内容？
我正在尝试找出组织 解决方案，更具体地说，“基本解决方案”或“库解决方案”中应包含哪些内容。
SDK 的内容如下：
<块引用>解决方案库适用于拥有多个解决方案或大型解决方案的 ISV 企业部署，值得期待 许多解决方案组件将 必须分享。最好的方法 共享组件的解决方案是 创建解决方案库。你创造 通过创建一个解决方案库 单独的非托管解决方案 组织然后打包它们 组件集成到托管解决方案中。 将托管解决方案安装到 另一个组织让 开发人员参考这些共享 解决方案中的组件 创造。
Microsoft Dynamics CRM 解决方案 框架允许您构建层 相互依赖的解决方案。 通常，您创建一个解决方案 代表“基地”的图书馆 解决方案。可以构建其他解决方案 在此基本解决方案之上。
理想情况下应将哪些组件放置在基础/库解决方案中？核心业务实体和选项集？核心功能和工作流程？
动力学文档似乎没有太多指导。
I am trying to sort out a best practise approach to organising solutions and more specifically what should be included in the 'base solution' or 'library solution'.
The SDK says the following:
Solution Libraries For an ISV with multiple solutions or a large
enterprise deployment, it is expected
that many solution components will
have to be shared. The best ways for
solutions to share components is to
create solution libraries. You create
a solution library by creating an
unmanaged solution in a separate
organization and then package those
components into a managed solution.
Install the managed solution into
another organization and let
developers reference these shared
components from the solutions they
create.The Microsoft Dynamics CRM Solutions
Framework lets you build layers of
solutions that depend on each other.
Typically, you create a solution
library representing a ”base”
solution. Other solutions can be built
on top of this base solution.
What components should ideally be placed in the base/library solution? Core business entities and option sets? Core functionality and workflows?
There doesn't seem to be a great deal of guidance on the dynamics documentation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您计划在多个组织之间共享任何功能，并且这些功能将与组织的其他部分分开进行修订，那么我会考虑将其放入单独的解决方案中。
例如，假设您的企业中有多个区域，每个区域都有自己的 CRM 组织，但每个区域都使用标准的评分和分配潜在客户的方式。在这种情况下，我将创建一个包含该功能的解决方案并将其安装在每个组织上，这样当流程发生更改时，可以将相同的解决方案推送到所有组织，并且每个人都会获得相同的更改。
另一种可能性是您在多个组织中使用的一组通用 JavaScript 库和插件，可能用于自动命名或自动编号记录或某些自定义业务逻辑验证等。这样，如果您发现其中的任何错误，您可以再次将相同的更改推送到所有组织。
如果您没有多个 CRM 组织或者您不是 ISV，我不会费心提供解决方案。它们对于 CRM 来说是一个巨大的飞跃，但这绝对是第一次，与它们合作会遇到一些怪癖和令人头疼的问题。
If you have any functionality that you plan to share across multiple organizations that will be revisioned separately from the rest of your organization, then I would consider putting that in a separate solution.
For example, say you have multiple regions in your business that will each have their own CRM organization, but each of them uses a standard way of scoring and assigning leads. In this scenario, I'd create a solution that encompasses that functionality and install it on each organization, and that way when the process changed, the same solution could be pushed out to all the orgs and everyone would get the same changes.
Another possibility would be a common set of JavaScript libraries and plugins that you'd use across multiple organizations, maybe for things like autonaming or autonumbering records, or some custom business logic validation. That way if you found any bugs in them, you again could push the same changes to all orgs.
If you don't have multiple CRM organizations or you're not an ISV, I wouldn't bother with solutions. They're a great leap forward for CRM, but it's definitely the first pass around, and there are some quirks and headaches to working with them.