My colleague Rickard and I are working with one of our customers who have gotten managed to get themselves into a rather big mess with huge numbers of attributes on the account entity that should not really be there. If any of you ever wondered what the limitation for number of attributes in Dynamics CRM is, it is around 700 and it is not recommended to use since the system becomes very hard to work with. Proper data modelling with experienced architects is usually a good idea that pays off tenfold later, so that you do not get your self into this situation.
However, the production system at hand has several hundred attributes that were erroneous in a managed solution, and something had to be done.
The first thing you might think of trying is just to remove the attributes from the development environment, packaging a new version of the managed solution and overwriting the production environments managed solution with this new reduced solution. This will, however, not work, as solutions cannot remove attributes (they contain the state of the CRM-system, not the transactions).
After a few more ideas had been tried, we finally registered a support case with Microsoft where a very helpful technician assisted us with a solution to this, based on this very good blog posting by Gonzalo Ruiz. The latest news on this is that it seems to be working, although neither Rickard nor myself is doing the actual work.
This has also caused us to have a very in-depth discussion on if managed solutions are suitable for normal project production systems or not. I had a discussion with former Microsoft employee Peter Björkmarker who is a very skilled architect, and we came to the conclusion that managed solutions are really best suited for ISV-packages, and not so much for normal customer projects where unmanaged solution are easier to work with. This is, however, something I would be more than happy to discuss, so if you have any opinion on the subject, please leave a comment!
Gustaf Westerlund
CEO, Chief Architect and co-Founder at CRM-konsulterna AB
www.crmkonsulterna.se
Hi Gustaf. Nice article! Solutions have certainly thrown up some interesting challenges for us! We have found that having unmanaged solutions in a production system makes the system "unmanageable". It allows customers to believe that they can edit and customise the live system at will, without having the necessary change control in place to ensure changes are made correctly and in a reproducible manner. Therefore, as has often been the case with us, we find that Live systems are configured differently to development systems, and moving the customisations from development to live via a test system can cause unexpected results. An example being that we had one customer that manually created an attribute in live, and separately in test, but created them with different data types. This obviously caused the solution to fail to import. We have found that applying the same level of control at a customer site that we do in development means that you can develop an upgrade path for your live system when updating test, meaning that there is less risk to downtime whilst upgrading live to the latest changes.
Thx. I am a trainer for the customization course and I usually elaborate quite a lot on this subject. Allowing for Changes to be made directly in the production system while at the same time moving Changes from development via QA systems to production systems like you describe sounds like a asking for trouble. In general I would also like the QA system to be as Close to the prouction system as financially feasable for the Customer, and allowing for Changes in the production system does not make that easier. Also, do Review the solution layering model, the unmanged layer will ALWAYS be ontop of the managed layer which can cause some very strange behaiviors in the situatuion you describe.
Thanks for the swift reply Gustaf. Yes, modifying the unmanaged layer will be a problem if you layer an additional managed solution on top. You have to make sure that customisations are done in the same order that they were done on the development environment, and if they weren't, then you are in trouble. This is a particular problem with Views, Dashboards and Option Sets, where importing managed solutions may not affect them if they have been edited, but importing an unmanaged solution may overwrite. We are trying to push out a simplified version of the Microsoft ALM which will apply to the majority of our customers for the scenarios that we know about, but are having a little trouble explaining component deletions through managed solutions (and using the transient solution approach).
Yes, there is definatly a challenge trying to explain this complexity.