在日常工作中，我们时不时会遇到在CRM测试环境上添加Optionset的时候，Default Value是某个值，但换到Production环境或者其他环境，添加的时候，Default Value可能却是另一个值。当然，一般的Optionset，比如Global Optionset，我们可以通过部署Solution的方式来保证Optionset的一致性，但是如果是非Solution可添加的Components呢？CRM是通过什么机制来确定Optionset Default Value的呢？ 笔者最近遇到个问题，就是希望在System Settings -> Reporting里添加分类，但是CRM开发环境和Production环境在添加的时候，Optionset的Value就不一致，而这个设置，也没发现可以当作Component添加到Solution去部署到Production环境，进而转向去研究这个默认值到底是怎么来的。
CRM Organization在创建的时候，会有一个默认的Publisher，打开这个Publisher，我们会发现有个字段叫Option Value Prefix
然后对比一下我们添加分类时候的Value
我们发现添加的Value的前缀，就是Publisher设置的前缀值，如果想要保证Optionset Value的一致，就需要先保证Publisher的Option Value Prefix的一致。
接着我们再想一想，一个CRM环境，Publisher可能有很多个，那么对于上述情况，应该以哪个Publisher的设置为准呢？
我们知道，CRM所有的Components，都是在一个大的系统Solution中的，叫做Default Solution。而类似于这样的系统配置，我们可以理解它就在这个Default Solution中。接着我们查看Default Solution的Information
可以看到Publisher字段对应的Publisher，就是Default Publisher，不能修改。
那么问题又来了，上面说到需要看Component所在的Solution对应的Publisher，来确定Optionset的Value。如果Component在多个Solution中呢？比如Entity，在Solution1，Solution2中，并且对应的Publisher都不一样，Prefix也不一样，这个时候，我们如何确定Value呢？
不知道大家有没有发现，在打开某个字段的配置的时候，CRM会有个关于Solution的标识。
在开发环境，如果我们通过Entity的某条Record，打开Form Edit，再进入上面的界面，Working on solution的值是Default Solution，这个时候添加的Value前缀，就是Default Publisher的前缀值；如果我们在Solution1中展开Entity，打开Field进入上面的界面，Working on solution就是Entity1，而添加的Value前缀，就是Entity1 Publisher的前缀值。所以对于之前的问题，我们也就明白了，对于类似于Entity的这种情况，需要注意的是Working on solution。