Issues with CrmSvcUtil
The biggest issue I have with the existing tool is the lack of naming ability. Say you have a custom entity called "new_project" with an OptionSet attribute on it called "new_projecttype". Ignoring all the other entities that will get exported regardless of whether you actually need them or not, and ignoring all the standard attributes that will be exported, the naming convention you'll end up with is this:// Class...
public partial class new_project...
// Property...
public Microsoft.Xrm.Sdk.OptionSetValue new_projecttype
// Enum
public enum new_project_new_projecttype
I've chosen the type OptionSet in particular to convey an additional problem, but there are a host of issues with what is generated.
- We end up with 1 huge unmanageable file.
- Really bad naming convention by default that is not easy to change. Sure, you could manually edit them, but it will get overwritten with each generation of the metadata
- OptionSet properties created as the type OptionSetValue. Surely if we are using Early Bound then shouldn't our option set properties be the equivalent enum type?
So the tool is quite lazy in what it does. It's a bit of a "bare minimum" to get you over the fence, and then you're left to your own devices. Quite frankly, you'd be quicker just writing the classes yourself and as long as you honor the correct attributes it would work perfectly fine.
I have investigated many tools, and all of them fell short. So this and all of the above issues caused the birth of my own pet project which has made my life a lot easier.
Extended Svc Util
It's named simply so, because all it does is extend and build on top of what the existing CrmSvcUtil does. Once the code has been generated it does not intercept the generation of the "monster file", but instead piggy backs the code generated for that to produce its own files. Let's take a look at what you can do.To fix the problems in the above files you could set up a configuration like this:
<configuration>
<configSections>
<section name="schemaDefinition" type="CodeGenerator.Config.SchemaDefinition, CodeGenerator" allowLocation="true" allowDefinition="Everywhere"/>
</configSections>
<schemaDefinition groupOptionSetsByEntity="true" exportAttributeNames="true" entitiesFolder="..\MyProject.DomainModels" enumsFolder="..\MyProject.DomainModels">
<entities>
<entity name="new_project" friendlyName="Project">
<attributes>
<attribute name="new_name" friendlyName="Name"/>
<attribute name="new_projecttype" friendlyName="ProjectType" />
</attributes>
</entity>
</entities>
<optionSets>
<!-- Global OptionSets-->
<optionSet name="new_someglobaloptionset" friendlyName="SomeGlobalOptionSet" entity="Global" />
<!-- Project OptionSets-->
<optionSet name="new_project_new_projecttype" friendlyName="Project_ProjectType" entity="new_project" />
</optionSets>
</schemaDefinition>
</configuration>
So what does this do? Firstly, you can add friendly names to your entities, attributes and option sets. Secondly, the export will use the correct enum for your option sets rather than using the out of the box OptionSetValue. So what you'll end up with instead is this:
// Class...
public partial class Project
// Property...
public Proejct_ProjectType? ProjectType
// Enum
public enum Project_ProjectTypeThe next configuration item I'd like to point out is not only can you depict where the file is generated, but you can decide to group all of your option sets into 1 file per entity rather than separate classes. These are defined at the top of the configuration under Schema Definition. All of this causes 2 files to be generated named:
- Project.cs
- Project.Enums.cs
Finally, only entities you have specified within the list will be exported to their corresponding file, all others will be ignored. All of the code will still be exported to the output file you specify so if you wanted to double check that source against what this tool exports you can do so.
All of this makes life much easier and readable in the Early Bound world, and makes it much quicker to generate the classes exactly as you want. I have included a global option set option in there just as an example of how to deal with that. But in effect all of those option sets in this example will be exported to a file called Global.Enums.cs. You can rename out of the box fields, status fields and their accompanying enums too. So you're not just stuck to your custom entities and fields.
Source
I have uploaded the source to github (https://github.com/conorjgallagher/Dynamics.ExtendedSvcUtil). There are further instructions up there on how to utilise the DLL it builds with CrmSvcUtil. It's fully open source so feel free to download, edit, and use to your hearts delight. In the root folder of the project I have included the latest built version of the DLL, so if you just want that feel free to download it.If you find bugs please feel free to submit a comment. I have not fully decided on how best to manage contributions, so if you are interested please contact me and we can discuss.
