Crm 2011: Unmanaged changes to managed solution form gotcha

Question

I am learning a lot about managed vs. unmanaged solutions these days, and I definately see a lot of benefits using managed solutions in production.

I see that the recommended pattern is to have a development environment where you work with unmanaged solutions, exporting both unmanaged and managed versions of the solution, and finally deploying the managed solution to production (and possibly to a staging environment first for testing).

This is all very nice and clean, but not without pitfalls. I recently experienced the following scenario:

1.

We used the above pattern to create and deploy a managed solution for the account entity and install it for a customer. The solution contained among other things a form and some other stuff for integration with a legacy system

Sketch:

Managed section

---

Field A Field B

Field C Field D

2.

Without my knowledge, the customer went ahead and customized the account form using the 'customize' menu. What he did, was to create a new form section, and move some of the custom fields included in our managed solution from the original section to the new section

Sketch:

Unmanaged section

---

Field A Field B

Managed section

---

Field C Field D

3.

Since this is an unmanaged change, it takes priority over my managed changes, wrecking havoc to the form layout afer I did some other changes (deleting some other fields and changing the order of some fields on the form)

Resolution attempts:

I have tried re-installing the solution of course, also with the 'overwrite customizations' option that promises to overwrite unmanaged customizations to the entity, but that does not change anything.

I also tried removing the new section and the fields that were moved as an unmanaged customization (using the customize menu) and then reinstalling the managed solution, hoping that this would somehow 'undo' the unmanaged change and that the diff mechanism would detect that the fields in question were only present in the managed solution and that this would cause them to appear in the original location. But as it turned out, it seemes like I was only carving more changes in stone - this time telling the system to remove the fields from the form altogether.

Can it really be like this, that once you do unmanaged changes to a form, your managed form is just screwed?

Is there no way to force the managed form take priority again?

I can of course do some more unmanaged customizations to the form to put the fields back where they originally were, but that would just postpone the problem until next time I want to e.g. change the order of fields in the managed form - the unmanaged changes from last time still have priority.

It seems that my only options are either to start from scratch again, or to switch to an unmanaged regime for the account entity.

Lessons learned:

If this is as bad as it seems to be, I should probably have used managed properties to disallow customizations to the forms in my managed solution. If this was a custom entity I would have done so, but I thought this would be a bit strict for an entity like the account entity. Another lesson learned is probably to never give the customer sysadmin/customizer rights...

Would love some other thoughts and experiences regarding this.

Answer 1

I know I'm late to the party here, but for what its worth and for anyone that comes across this post I'll add my two cents. we have a setup almost exactly as @TMan mentioned, except that we have a Dev, QA, and production site where Dev is unmanaged and the source of our customizations and QA and production are both managed. I've spent far more time than I would have liked to with the solutions and customization layering processes to understand how everything comes together to get the final result. I've also added third-party managed solutions into the mix. Seeing the end result of all that, I have come to the conclusion that managed solutions are absolutely NOT the way to go, except maybe for a third-party solution provider, but the target systems IMHO should all be customized with unmanaged changes. One major issue I found was when I brought third-party managed solutions into our Dev environment, we will have dependencies to components in that solution once we export our own customizations as a managed solution to deploy to QA and production. The interesting thing with this is that the layering and dependencies on the Dev site are flipped around in reverse order once you go to a QA or production managed site because your own customizations go from unmanaged to managed, and managed customizations are applied in order of install date in the system. Without getting into a lot more detail here, the summary is these dependencies will never go away once introduced into one of those managed environments and you can't uninstall your own customizations unless you want data loss, and in some cases you might not be able to uninstall the solution even if you were ok with data loss due to the dependencies. All our environments are CRM Online so we don't have the option of mucking around in the database directly to get rid of stuff we don't want. The key here is to know that in most cases once you put a managed solution in place it is forever, permanently there and you can only apply additional unmanaged changes on top of what is there, you will have no way to clean up unused or unwanted components. I spent a lot of time doing my own research and testing and also spent a lot of time on the phone with Microsoft.

Bottom line: managed solutions for a multi-site setup such as Dev to QA and/or production is a very bad way to go, you're losing flexibility and could possibly hit a brick wall in some situations. You're much better off keeping everything unmanaged and having the flexibility you would expect to properly customize your systems