不少从事D365研发工作的朋友，可能或多或少都经历过这么一种情况，使用CrmServiceClient对象初始化一个实例，然后发现OrganizationServiceProxy对象是null。不仅如此，还可能碰到的情况是封装好的Common构造，连接一个CRM环境时好用，但是连接另一个却不好用。下面是针对这样的情况，总结的一些注意事项，用以尝试解决问题：
1. TLS1.2的指定是否添加了。对于使用最新版本CRM dll的开发来说，这不是个问题，因为.Net Framework 4.6.2已经把TLS1.2作为默认选项了。但是如果你的版本还是旧的，那么就需要明确指定它了，具体的指定方式是这样的：
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
2. 一般我们在初始化CrmServiceClient对象的时候呢，传入的参数是一个ConnectionString。这个ConnectionString长什么样，大家可以上网查。这里我要说的是String里有几个参数需要注意，一个Domain，一个Username，还有个authType。
a. 在连接OP环境的时候，建议使用Domain和Username都带上的String作为参数；在连接OL环境的时候，建议仅使用Username参数，并且赋值方式为xxx@xxx的格式
b. 不管哪种连接方式，ConnectionString都带上authType参数，并正确赋值
3. dll版本升级或者.Net Framework升级，更具体点就是对dll以及.Net Framework版本匹配的检查
不管是dll版本改变还是Framework版本变化，都需要注意新版本的dll对.Net Framework的要求，还有对依赖项dll的要求。举个最近碰到的例子，最新版本的CRM dll需要Framework的版本是4.6.2，在把Framework升级以后，发现ServiceProxy是null，经过一系列的排查之后，发现是某些系统dll的引用版本过低，以及nuget上之前添加的其他dll版本过低导致的，但是这些问题都不会在build阶段给你暴露出来。
如果碰到1和2都满足的情况下，ServiceProxy还是构造失败，那么看看error message是如果描述失败原因的。在构造CrmServiceClient对象之后，如果存在什么异常信息，一般会在LastCrmException属性里暴露出来，所以还可以看看这里的信息来诊断问题。
目前博主碰到的问题大致是这几个方面的，如果再遇到其他情况，会继续进行更新。