Sunday, April 01, 2012

Why should you use CRM Developer Toolkit for your next CRM project engagment


[DISCLAIMER] This blog post contains strongly-opinionated information. For this reason, you are expected to use your judgement to decide whether the information is helpful for your development practice. As such, I make no warranties of any kind. [/DISCLAIMER]

Many of you are probably aware that I am a big fan of CRM Developer Toolkit. However, it is an unfortunate fact that the tool has not attracted enough attention in the community. Many of us are sceptical about using the toolkit with the concerns that the complexity or limitation of the tool might overweigh its benefits. This is reasonable for a new tool, and it is also expected.

With my limited experience with the toolkit, I have identified quite some important benefits when the tool is properly used. Here are some of them.

Unified Development Experience

The toolkit helps handle most day-to-day CRM development tasks. The toolkit supports the development of CRM web resources, Plugin, Silverlight, Workflow projects.

The toolkit provides a consistent approach for CRM development practice. Using the toolkit, you have one single Visual Studio solution to work with, which allows you to manage most (if not all) of CRM artifacts. The solution file include a CrmPackage project which is the container of CRM artifacts that you deploy and publish to CRM, including the source code of web resource files, references to plugin, workflow, Silverlight projects. If any of us have worked with SharePoint, you probably remember the days before its Visual Studio extension was available. If you asked 10 developers to do one single task for SharePoint, in most of cases, they would probably have done it in 9 different ways. It has been significantly better after the SharePoint extension became available. I believe CRM developer toolkit is an equivalent tool of the Visual Studio extension in SharePoint development practice, which has been widely embraced and welcomed by SharePoint community, and it has become part of Visual Studio shipment in VS 2010. I dare to say that nobody in SharePoint community wants to go back to the time without the extension. I would hope that the CRM developer toolkit can one day make into Visual Studio shipment as well, however I am very aware that we have a long way to go to get there.

Increased Development Productivity

The toolkit significantly improves your development productivity. Working with CRM web resources can be a very tedious task if you do it from CRM user interface. The process is significantly simplified, if you are using the toolkit. You make the changes to the web resource within Visual Studio, then you right-click CrmPackage project, and choose "Deploy" menu, the websource is deployed to CRM. It is as simple as a snap. The only thing you need to do after this is, you have to publish the changes in order to see the changes in effect. What I usually do is to always leave a web page open, which has a "Publish All Customizations" button on it, so that it takes me one single click to have the deployed changes published in CRM. Since the toolkit supports most CRM development tasks, you rarely need to leave the environment. Also the toolkit has included a few other productivity tools including the capability to create a plugin class, and generate early bound entity classes from CRM Explorer, etc.

Managed Development Process

The toolkit manages your CRM web resources so that you can source control them. The toolkit allows you to manage your CRM web resources using file system within Visual Studio, each web resource is represented by one physical file in CrmPackage project. Such files can be easily version controlled using your favorite source control system. In the good CRM4 days, I have used some code snippet to load JavaScript from file system, so that I can version control my JavaScript files. This is totally unnecessary with the help of the develop toolkit in CRM2011 (also thanks to the Web Resource feature).

Advocate of Best Practices

The toolkit provides some guidelines for CRM development practice, and also it advocates some best practices when working with CRM. It has got a plugin project template in the Visual Studio solution for us to start with, which includes quite some informative comments.

Free of Charge

Last, but not the least, the toolkit is free, it comes with CRM SDK at no charge. ;-)


With all the above benefits using the toolkit, you should also be mindful about the constraints or limitations when using the tool. It is particularly important to know the boundary of the tool, and know what the tool can do, what it can't do or should  not be used. With the help of the toolkit, we, the developers, are really the director of the development. The tool has its own way to get the job done, it is up to us to leverage its flexibility to make our development life more enjoyable. After all, CRM is the final judge, the toolkit won't cover 100% of development scenarios, but there is usually some workaround when it comes to CRM platform, the primary value of the tool is to help streamline the process of working with CRM, so that we can be more productive.  Some in the community may say that the toolkit is just a CRM metadata browsing tool. This could be the case for the toolkit's CRM4 version, and it is definitely not the case for CRM 2011 developer toolkit, it is much more than a CRM metadata tool.

Although the toolkit is overall a great tool, it doesn't mean it is perfect. One important feature that is currently missing in the toolkit is the ability to deploy individual WebResource (CRM MVP Rhett Clinton and me both raised this as a feature request). I think this is an important feature to make the toolkit work better in a shared team development environment. For instance, if we have two developers using the same DEV environment, both of them are working on a different piece of web resource at a time. With the current version of toolkit, it will deploy the entire project when the Deploy command is used, so what would typically happen is, one developer will overwrite another developer's latest change. If we have the capability to deploy individual file, it will not cause this kind of trouble. Please vote for the change if you agree with me, so let the voice heard. Also there are also other areas that could make the toolkit better, if you have any other feature requests, I would encourage you to use Microsoft connect site to report them to Microsoft.

Thanks for reading.


No comments:

Post a Comment