Dynamics 365-关于Solution的那些事(三)

　　这一篇的内容，是关于Solution的使用建议的，若是你们有什么实用的建议，欢迎留言讨论。

　　一. 版本控制

　　Solution是有版本号的，率性的人可能在新建一个solution的时候，直接赋值1.0，就再也不管了。可是这里仍是简单说下MS风格的版本号，通常是用.分隔的四个数字：主版本号.子版本号.编译版本号.修正版本号。后面两个版本号可选或者互换位置，前面两个必须。建议迭代周期，要作好Solution版本号的设计和管理。这方面的好处很少赘述了，毕竟不论是不是开发，都能想得明白。

　　二. 分门别类

　　分类实际上是为了更好对Solution进行管理。咱们知道CRM有很多类型的Components，而在Solution里，若是你把全部的Components都放到一个Solution里，你会发现越到后期，你的Solution就越难维护。那么是否是我把components从数量上简单地拆分开就能够了呢？好比我把不少的workflow，plugin，Entity拆分到多个Solution里。并不是如此，这里说的分门别类，通常能够从这几个方面考虑：

　　1. component自己的类型

　　2. component涉及的业务：包括业务逻辑，业务部门

　　3. component的依赖关系

　　4. component的数量

　　5. component与项目迭代的关联

　　如今MS的产品，走的是模块化的设计理念，那么这个模块化，咱们应用到Solution里，也是同样适用的。好比你要考虑，哪些Solution能够规划成一个“模块”，若是部署以后，未来客户不要了，能够在不影响当前业务的前提下直接删除（看如今的AppSource里的Solution产品，都是能够在不影响环境结构的前提下，实现Solution的导入和删除的）；哪些Solution是属于xx部门的，即便之后Solution有更新，也能够在不会影响其余部门业务的前提下实现更新；哪些Solution对其它的Solution有依赖，而被依赖的Solution是否是设计的比较Common等等。

　　三. 下载日志

　　通常状况下，Solution导入成功或者失败，最后都会有download log选项。借用这个日志，咱们能够准确高效地定位出错的Component以及可能的缘由。

　　1. 导入失败

　　不要用记事本打开下载的log文件，那样你会看到密密麻麻的信息，很不直观。使用Excel打开log，你会发现全部的component信息，状态信息，comments信息都已经有条理的列好了，很方便地就能够找到失败的component，以及失败的描述信息，来帮助咱们解决问题。有一点须要注意的是，由于CRM的导入操做就是往数据库里修改数据，那么就会碰到一个让人很无奈的状况：即便你的Solution问题再多，CRM也只会导入一次才暴露一个问题，而不是像有统计列表那样，一次把全部的问题都暴露出来。

　　2. 导入成功　　

　　可能许多人看到CRM显示Solution导入成功，就直接关闭窗口，以为log无关紧要了。在这里，仍是建议你们，即便导入成功了，也把log保存下来。有两方面的缘由：一方面是即便导入成功了，还可能会有不少的warning信息，有些warning信息甚至会影响后续的操做。好比，你更新一个workflow的Solution，导入虽然成功了，可是你发现为何workflow activate失败了呢？若是你查看导入log的warning信息，就可能找到一条提示信息“workflow涉及到user在当前环境没有......”。另外一方面的缘由，是若是之后有一个环境问题是由于当初的这个Solution，还能够当作一个处理问题的依据。

　　3. 导入ing

之全部说导入Solution通常都会下载log的选项，是由于还存在非通常的状况。若是硬件资源不足，或者Solution自己太复杂，可能会出现的状况，是进度条卡在最后的85%左右，而后就再没有反应了。这种状况，能够经过检查Solution的版本号，来确认Solution是否导入成功，固然，这个时候，就不会有下载log的操做了。