标签：其它 模块化 download 没有 拆分 excel 版本控制 删除 风格
这一篇的内容，是关于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的操作了。
Dynamics 365-关于Solution的那些事(三)
标签：其它 模块化 download 没有 拆分 excel 版本控制 删除 风格
原文地址：https://www.cnblogs.com/yobyron/p/9870754.html
