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!
CEO, Chief Architect and co-Founder at CRM-konsulterna AB