You may have read some of my previous postings on SharePoint, but in my world of Solution Architecture I touch on other products such as SQL Server, Microsoft CRM and whatever else is an appropriate fit to the requirements of client work I am engaged on.
A recent job for a multinational consultancy was an excellent opportunity to catch up with the Microsoft CRM 4.0 SDK and the tools contained therein. I’ll post separately about the business problems we solved with Microsoft CRM 4.0 and some integration code, but in this article I’ll focus on what I discovered in using the xRM tools included in the recent SDK.
This isn’t the article to discuss the improvement in the support for developers, but I have to say that the shipping of accelerators that are good enough to be reference material are a great way of supporting the learning process for building on CRM. Hot on the heels of the accelerators have been the SDK improvements to allow you and I to make the most of CRM, and this particular post concentrates on the library class generator CrmSvcUtil.exe.
When you download and extract the CRM 4.0 SDK from Microsoft you will find a microsoft.xrm directory alongside the other collection of directories containing sample code, user interface design guide, SDK help file etc. In that directory are four useful documents: two guides and two walkthroughs giving you as the developer an idea of what is intended by the Microsoft Dynamics CRM 4.0 SDK Advanced Developer Extensions (Microsoft xRM), to give it its full title.
These documents explain how to use the code generation tool and I’d recommend you read the developer's guide to get a quick heads up of what is intended by the inclusion of these tools in the SDK. At this stage the documentation is rather “light” but I would expect more detail to emerge in subsequent releases of the SDK. To cut a long story short, CrmSvcUtil is a command line tool that generates a whole pile of classes from your CRM instance. This is important, because as well as creating classes for managing the built-in entities, it also generates them for your custom entities. This does of course generate a minor configuration management headache, and I’ll post an article later on what we have implemented,with recommendations for integrating this with automated build in order to ensure that your generated classes keep pace with what your entity developers are doing.
It took me a few tries to get the right combination of parameters to get the class output I needed. In particular I found that I had to get the dataContextPrefix exactly correct in order for the correct classes to be included. I created a number of different sets of files either singly or collectively that represented the entity activities but these depend on certain shared classes that I found were not included in all parameter combinations.
Additionally I discovered, through using the tool, that it will prompt for missing parameters provided essentials like the server name have been specified. As I mentioned earlier the tool can create separate c# files for each entity, but with getting on for almost 200 entities (not including any custom ones), I found the generation of a single .cs file preferable from a logistics point of view.
In the end I settled down to a command line like the following:
crmsvcutil.exe /connectionString:"Authentication Type=AD; Server=https://crm.microsoft.com/Woodgrove User ID=WOODGROVE\devaccount; Password=***" /out:"Xrm.cs" /namespace:Xrm /dataContextPrefix:Xrm
This will generate a single class file called xrm.cs based on reading the entities in the specified organisation on the specified server. A full description of the parameters can be found in the Advanced Developer Extensions Developers Guide. A word of warning though, the file isn’t small – with a full set of standard entities and custom entitities the xrm.cs file generated out at just over 4Mb.
The great thing about this approach is that, as the generated code runs off your organisation in your CRM, it picks up not only your custom entities but also the changes that you have made to customisable entities. In my opinion, this makes it a lot easier to get up to speed with concentrating on the business logic and specifics of integrating with CRM rather than crafting your own way through wrapping up the CRM web services. I’d recommend having a look and running the generation tool to see if the classes it provides would have helped to make your last CRM development project easier, and will make your next a lot easier. In follow-up posts I hope to take a step back to talk about the business requirement we satisfied with this technology, but also perhaps take a step sideways and describe how this code generation can fit into an overall governance policy for regular build and test using Team Foundation Server.