I am starting to get into the nitty gritty of programming using the SDK.
When I tried to run through the Ribbon example in the SDK, it was a nightmare. Adding a button into CRM 2011 is a lot harder than the adding a button in CRM 4. The main reason for this is because of the Ribbon. Although the Ribbon is good because it provides context to all the screens, tabs etc it makes it very painful to add in buttons.
It was difficult running through microsofts walkthroughs, now this to me says the using the ribbon is difficult if you struggle to understand a step by step walkthrough.
This blog has a nice quick summary of the CRM 2011 SDK
Microsoft Dynamics CRM 2011: The Good, The Bad, and The Ugly
For the good I agree that improvements for solutions management, improved Javascript, reusable Javascript. Although Solutions do provide some bad because you can’t import any of your CRM 4 entities because they are not in a solution.
One of the good things he mentions is Early Bound Entities. I hadn’t used this yet but I think it’s basically involves using code generation tool (CrmSvcUtil) to create classes that you can use to access business data in Microsoft CRM.
From my brief look at the SDK document (more investigation to follow) it creates one class for each entity, a couple of links for you from the CRM 2011 SDK
Use the Early bound entity classes in code
Use the Early Bound Entity Classes for Create, Update and Delete
The Bad
In the bad he basically describes that working with CRM is not easy for developers. There are lots of xml files to be edited manually and not many tools to help you get this right.
Deploying CRM code is tricky and can often lead to mistakes. It would be a big help if Microsoft created some kind of installing software to help automate the process to make sure we didn’t miss anything out and didn’t accidently change some of the settings.
I am going to quote the ugly part because he describes the pain perfectly
The Ugly
I wish I could say there’s nothing truly ugly about CRM 2011, but that would be a lie. There is one new component who’s implementation from a development perspective is so painfully clunky, that uglyness just scratches the surface. The Ribbon.
Don’t get me wrong, I love how the ribbon enhances the end user UI experienceand brings CRM inline with all of Microsoft’s new products. And I love how the new ribbon offers alot of flexibility in terms of when and how things display. But implementing changes to the ribbon is far more painful than it should be.
First off, the xml schema for the ribbon is fairly complex, and the SDK doesn’t do a good job explaining how all the parts play together. I actually plan to give a brief internal presentation for the developers who haven’t worked with it yet, just so they don’t have to spend so much time trying to parse through the samples Microsoft provides to understand it.
This complexity in itself wouldn’t be bad. In fact it’s because of that complexity that the ribbon is so flexible. But the problem is that it means that there are at least 5 actions you have to take in order to implement any change, even just adding a single button. There’s no quick shortcutting and it’s easy to forget and leave something off.
Which brings me to the main problem. When you have something that’s complex and easy to mess up, easy debugging is crucial. But the process of editing, and then deploying the ribbon is almost unconscionably painful. To start, you have to export your entire solution. Either that or create a separate solution just for the entities whose ribbon your changing and export that. You have to unzip the solution, edit customizations.xml directly, rezip everything, import back into CRM, and publish. In my experience, each change takes 2-3 minutes to deploy. Not quick debugging at all.
What’s even more problematic from a change management perspective, is that your ribbon is lumped in with other entity customizations. If you edit the ribbon while I’m adding or changing attributes, you may overwrite what I am doing.
I did a little research to see if it might be possible to develop a standalone ribbon management tool, kind of like the plugin registration tool provided by Microsoft, but it appears that’s not supported. The entities that hold ribbon customizations (RibbonDiff, RibbonRule, RibbonCustomization, RibbonCommand) are almost all noted as “for internal use only” in the sdk. I can only hope that means Microsoft is planning to create some sort of internal tool to ease the pain here.
Like this:
Like Loading...
Hosk's Dynamic Blog 