记得在以前的CRM版本中是怎么进行功能扩展的吗？让我们将之提到一个新的高度。使用CRM2011，我们能够在几天内（一些核心组件甚至可以在几小时内完成）定义，转移，部署，维护并使用架构在CRM框架上的整个商业应用，而不像以前需要几个月的时间。仅仅点击几下鼠标，你就能够定义你的数据模型，工作流程，用户界面和分析工具。一些高级扩展，例如.Netplug-ins和SRS报表，都能够包含在CRMSolution中。所有内容都能够以一个统一的模型进行转移和部署。

　　这绝对是一个了不起的功能。CRM2011允许我们将组件打包并将其视为一个“Solution”。为何说这个功能了不起呢？下面才是关键点。不仅仅因为它允许将组件打包，而是因为系统平台现在能够知道solution的边界，并执行相应的智能操作。请继续往下阅读。

　　开发和发布Solutions来控制客户化（unmanaged和managed）对于大多数以前为CRM4开发人员的“新人”来说，第一件事情就是我们引入了unmanaged和managedsolutions的概念。可以把unmanagedsolution理解为你的系统的源代码，而把managedsolutions理解为编译后的版本。当然，你不必在这点上咬文嚼字，因为CRM中的一些组件只是“定义”，不需要被编译；但尽管如此，这种类比还是十分有用的。所以，当你最初创建一个solution的时候，它总是被创建为unmanaged，你能够创建新的组件并修改其他组件。你甚至能够定义一些限制来使solution的管理更方便，例如将一些组件设置成不可自定义化。

　　当solution已经完成并准备最终发布使用，你可以将其导出为managed。当客户安装了一个managedsolution，我们强制执行你所设定的任何限制（例如：设定某些组件为“不可客户化”来阻止对其进行客户化）。尽管solution自身不能被修改，可客户化的组件仍然可被客户化，但系统会将这些客户化视为在managedsolution的“上层”所作的修改。因此，你拥有更灵活的选择，你能够限制一些组件不可被客户化，而对其他组件仍然具有内嵌的扩展功能，并且不需要写一句代码。

　　智能更新

　　如果你允许客户修改你的solution（创建在上层），将会给你将来的维护工作带来噩梦般的困难。其实并非如此，我们会帮你解决。每当你对一个managedsolution进行更新时，系统架构会自动保存创建在上层的客户化。我们有2种基本的冲突解决方案（mergeandpreserve），这点我将在随后的帖子讲解。总之，这两种冲突解决方案的结果是让客户能够维护他们的客户化，并且你仍然能够进行更新。

　　自动记录依赖关系

　　你怎么能够记录什么组件在哪里被用到，并且没有被意外删除而影响其他组件呢？如果你允许客户进一步客户化你的solution，那么这个问题会更加严重。不需要担心，因为solutions的架构会自动地记录系统中所有的依赖关系，相当了不起的功能！

　　一处创建，多处部署

　　在CRM框架上创建的solution能够在所有的CRM部署类型（Online,PartnerHosted,On-Premises）和所有的CRM客户端（Web,Outlook,Mobile）传送。它真的越来越接近开发者所崇尚的神圣目标“codeonce,deploy/useeverywhere”。哦，对了，我有提起过我们还可以在Outlookclient上将你的solution变成“离线状态”吗？有多少构架能够提供这种功能？

　　Solution共存

　　目前为止，一切都不错，但如果一个用户安装了多个由不同的合作伙伴创建的solution，那么它们会相互影响吗？事实上并不会，solution框架自动处理让2个或多个managedsolution能够共存。但是，不同的solution必须要有一定关联才能共存（在功能上，要有意义）。尽管从技术上说，在同一个组织（organization/tenant）中安装两个完全不相关的solution（例如医院管理和教育管理）是可行的，但最终结果或许对终端用户来说没有任何意义，特别是如果两个solution需要修改共同的组件（例如一个希望把客户（Account）当做医院，而另一个希望把客户（Account）当做学校）。

　　MicrosoftDynamics市场

　　系统中还有一个市场板块，你能够在上面放置一些和产品相集成的应用。