These are the different resources available from this page:
This is a blog about my experiences with Microsoft Dynamics CRM, tips and tricks as well as news from the CRM community.
Monday, January 30, 2012
The CRM 2011 Endpoints
These are the different resources available from this page:
Monday, January 16, 2012
Setting up your development environment for a CRM 2011 project
Monday, January 9, 2012
Cannot delete components of managed solutions
With the introduction of managed solutions in CRM 2011, I have noticed that it is common in the CRM community to perceive a sense of "danger" in managed solutions. While it is true that managed solutions can give you a lot of pain in some scenarios, it is also true that some of that pain can be avoided by understanding exactly what managed solutions are about, what are their limitations and dangers. I have challenged colleagues to explain to me why they prefer to not use managed solutions and I found out that in some cases it came down to a miss-use of the managed solution concept, in some other cases it was simply fear and lack of trust for new features while in other cases they pointed out a particular disadvantage of managed solutions.
The one valid problem that most people find in managed solutions (which you don't have with unmanaged solutions) is the inability to delete solution components. Once you install a managed solution, you will never be able to delete the following components:
So what should you do if you run into that situation? In my experience, most enterprises will anyway not allow the deletion of any production data and because deleting entities/attributes will delete all the related data, this scenario is usually not allowed by the business anyway. However, if you run into this scenario and you really need to delete those components from a managed solution then you have two options:
1. Uninstall the managed solution: You can always remove the components from the originating unmanaged solution, then uninstall the managed solution and re-install the new version of the managed solution which does not contain the unwanted components. This option can be long and tedious and will certainly delete all your data related to the solution so it is usually unacceptable to do so.
2. Hide the unwanted components: You can always hide the components so they become invisible to the end user. For example, you can remove the entities from the sitemap, remove attributes from forms and views and hide the reports. However, these components still exist and can be visible from Advanced Find. Additionally, you can revoke privileges to all users for the entities that you are hiding.
I also hope Microsoft will in the near future remove this limitation. I would be interested to find out from other community peers if they have other specific scenarios for which managed solutions are a problem and help identify potential improvements that Microsoft should look at.
Tuesday, January 3, 2012
Managed or unmanaged solutions in CRM 2011: Best Practices
Similar to source code when writing a program, unmanaged solutions is your only choice during development: Every solution was once an unmanaged solution just like any binary was once source code. As long as your solution remains unmanaged, it is “open” (editable) so you can add/remove/edit components, update the publisher, the configuration and the managed properties of the solution. You will also be able to update the version of the solution and you will be able to export it. Additionally, if you are working on a multi-language solution, you can export and import the solution translation labels. Since CRM solutions now contain the translation labels in the same zip file, you should always import your labels into the unmanaged version of the solution; this way, each time you export the solution it will contain all the labels so you will not need to repeat the translation steps for every environment.
Another typical use of unmanaged solutions is to work as an integration solution to which multiple developers or teams contribute with different components. However, once your solution is ready to go into UAT or production, the solution should be installed as managed because it will no longer need to be editable, this will allow a more rigorous release control because it will force all updates to be made in a development environment and then promoted to UAT/Production as opposed to making direct changes in production environments (a fundamental best practice in IT).
These are similar to .net assemblies in the sense that you do not directly edit a managed solution; it is “closed” to development. Additionally, managed solutions provide a sort of read-only signature which includes the version and the publisher of the solution. You should always make use of a consistent publisher to uniquely identify you or your company as the entity that released the solution; there are also additional privileges granted to the solution when the publisher matches the publisher of an existing managed solution in the system and it works in a similar (but more primitive) way as strong name validation in .net assemblies.
One of the advantages of leveraging managed solutions is the managed properties feature. Managed properties allow you to restrict changes in the solution by an unauthorized publisher. This is particularly useful if you have an undisciplined IT department that does not apply a thorough change management process when making changes to a solution. By making use of managed properties you can ensure that you (as the solution publisher) will remain in full control of the solution and prevent other from making breaking changes to your solution.
Another great feature of managed solutions is that it is able to create layers of customizations. In the unmanaged model, all customizations are at the same layer, so making any customization will overwrite what is currently in the system. However, managed solutions have the capability to keep track of which customizations belong to which solution. To the end user, only the top layer (latest solution installed) is visible, but under that layer there can be multiple layers of customizations so you can build a solution on top of another solution without mixing up all the changes. You can think of this capability as using reference assemblies in .net. You can develop a solution by referencing an existing managed solution. The end result is that you will have two solutions (one depends on another) but there can be a clear distinction of which customizations belong to which solution. Solution layering also means that you can revert-back to a previous system state. If you uninstall a solution, all its components will be removed but the customizations from other solutions in a lower layer will surface back.
To summarize, these are some of the reasons why I very much prefer to use managed solutions in all environments that are not development environments:
- Solutions can be installed into multiple layers.
- You can build solutions on top of other solutions (solution-level dependencies).
- Additional change management control.
- Option to turn on managed properties on solution components.
- Capability to uninstall a solution and roll-back to a previous customization state.
- Solution publisher can truly own solution components.