The importance of not messing with unmanaged customizations when you have agreed to use managed solutions

By | March 1, 2019

 

image You may have managed to put in an unmanaged change in production where you have agreed to use managed solutions only, and it may look like you are doing fine, nobody noticed.. So it’s all good until, suddenly, something starts going wrong!

 

Here is one scenario that does not seem to work well when you start mixing managed and unmanaged customizations.

Let’s say you have an application in your solution, and there is an entity added to that application.

You’ve exported that as a managed solution, then you’ve imported it into another instance.

Everything is going well, and, then, some sneaky person (like the one above.. whose picture I’ve found here ) decides to remove that entity from the application directly in the target environment through the default solution:

image

That plan ends up being a huge success – the entity is gone, it’s not in the application anymore!

But, as it turns out later, there is just no way to add it back through a solution import. You can update solution version numbers, you can try using “overwrite unmanaged customizations” option while importing.. it just does not work – that entity is not coming back to your application. Well, I did not try voodoo magic in my tests.

The only way to fix it is to go to the default solution in the target environment, open the application, and re-add the entity there. After that, you can continue to use managed solution imports whenever you want to remove or add that entity to the application.

So. Dynamics is doing a great job when layering the solutions, when merging them, etc. Do not interfere with this process – if you are relying on the managed solutions in your ALM, don’t do unmanaged customizations in production.

3 thoughts on “The importance of not messing with unmanaged customizations when you have agreed to use managed solutions

  1. Bill Gates

    Chrome says your site isn’t secure, for my own safety I will have to stop reading your blog.

    Reply
  2. Betim Beja

    Well unmanaged solutions are on the top layer and you can’t undo a change you do in the unmanaged layer. The only possibility we have is to do a compensating change, which is why we have to restore the entity from the default solution again.
    Also to keep Bill Gates and his chrome friends reading your blog I suggest you use the free cloudflare service and activate https for free.

    Reply
    1. Alex Shlega Post author

      Hi Betim,

      you are right of course as far as layering goes, though some changes can still be undone if you use “overwrite unmanaged customizations” option when importing the managed solution. It seems as a rule of thumb that option just does not work for any kind of XML-based configuration (such as formxml, or, in this case, application modules). It does work in some other places – for example, an attribute display name can be restored that way. As for managed solutions in general, I think I won’t go as far as Gus Gonzalez here: http://crmmvppodcast.com/episode-37-not-even-once , but, as the title says, it seems important not to mix (at the very least) managed and unmanaged customizations in production because of the layering.

      Thanks for the hint (cloudfare). Let me see if I can make Bill Gates happy:)

      Reply

Leave a Reply to Alex Shlega Cancel reply

Your email address will not be published. Required fields are marked *