tag:blogger.com,1999:blog-28669706.post520673825161590947..comments2024-03-25T08:33:57.056+01:00Comments on Gustaf's Microsoft Dynamics CRM Blog: Managed or unmanaged solutions - and how to remove attributes from managed solutionsGustaf Westerlundhttp://www.blogger.com/profile/02522937600083440624noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-28669706.post-49001867173271933982014-05-07T20:35:01.217+02:002014-05-07T20:35:01.217+02:00Yes, there is definatly a challenge trying to expl...Yes, there is definatly a challenge trying to explain this complexity.Gustaf Westerlundhttps://www.blogger.com/profile/02522937600083440624noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-56335481780658844942014-05-07T17:25:28.355+02:002014-05-07T17:25:28.355+02:00Thanks for the swift reply Gustaf. Yes, modifying ...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).Ian Carterhttps://www.blogger.com/profile/03801454368864359817noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-15587093024291797882014-05-07T13:35:39.389+02:002014-05-07T13:35:39.389+02:00Thx. I am a trainer for the customization course a...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.Gustaf Westerlundhttps://www.blogger.com/profile/02522937600083440624noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-57006378985416996112014-05-07T13:25:43.722+02:002014-05-07T13:25:43.722+02:00Hi Gustaf. Nice article! Solutions have certainly ...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.Ian Carterhttps://www.blogger.com/profile/03801454368864359817noreply@blogger.com