Back in January, after I published my How to unit test C# Dynamics CRM interface code - part III post on how to use NUnit and Moq to test Dynamics CRM interfacing code, I uploaded my project files to the MSDN code gallery. Earlier this week I revisited my original solution while preparing a demo for some of my colleagues. »
In this post I will show how to document a Dynamics CRM 2011 custom workflow activity assembly and use Doxygen to generate a compiled HTML (CHM) help file. (Doxygen can actually generate documentation in a variety of different formats, but I’m partial to CHM files because they’re entirely self-contained.) For this example, I have a project that consists of these three C# files: »
With the proliferation of RESTful APIs, JSON is frequently used as a message format for interoperability. My MSDN “Posting/processing JSON in a CRM 2011 custom workflow activity” code sample shows how to POST JSON messages to a REST endpoint and process the response in a Dynamics CRM custom workflow activity. »
In my current Dynamics CRM project, I am the solution architect for a new initiative that was set up as a “mini-project” separate from the existing CRM solution’s production support and feature enhancement teams. We had our own PM, testing team, business analysts and developers. As we approach go-live of our solution, we are at a point where we are now integrating our work with the other work streams, and this has led me to wax philosophical on the optimal arrangement of environments (dev, QA, production, etc. »
If you work with Dynamics CRM long enough, I can almost guarantee you will one day encounter a problem where a direct SQL insert/update/delete (DML) against your CRM database is either the only possible solution or the alternatives are so cumbersome as to make the direct SQL approach the only practical solution. »