Deleting things from a deployed CRM 2011 managed solution package

DISCLAIMER:  This is technically unsupported, but works.  If that makes you cringe, then walk away.  If you read it and think it will work for you, then make the decision that's best for you.

Example scenarios:

“I have a a field in an entity.  After deploying a managed solution to production, we decided we don’t need that field any longer.  I removed it from my development environment.  When I deploy an updated version of managed solution in production, the old field is still there.  I know it’s harmless to keep it in production, but I want it gone.”

“I renamed a web resource in development after already deploying it to production in a managed solution.  None of my code references it any longer.  When I deploy an updated version of the managed solution, the old web resource is still there.  I want it gone.”

This was something that stumped me when I started focusing on Dynamics CRM 2011.  Technically, the CRM solution package infrastructure has no way to delete something.  However, Shan McArthur explained to me that there is a way to accomplish deletes.  I plan on using this approach in the next release of my validation sample because I did some significant refactoring since my first release.  The general concept is to:

  • Create a temporary managed solution to “hold” the latest “good bits” using the same publisher
  • Import it on top of your existing managed solution
  • Delete the older managed solution
    • This deletes the older stuff while the “holding” solution prevents the “good bits” from being removed
  • Import the new version of the managed solution
  • Delete “holding” managed solution

Let’s walk through this step by step.  You can download the three files to try this yourself here.  I have two orgs: dev and target.  In my dev org, everything is unmanaged:


In my target org, I have already deployed the 1.0 managed solution that was exported from my dev org:


If you want to try this out yourself, just import the 1.0 managed solution into your own CRM 2011 org.  Here’s a look at the form in it’s current state:


Notice that it has a “delete me” field and web resource.  For version 1.1, in my dev environment,  I went ahead and removed the two items from the form, then deleted the field from the entity:


…and and the web resource from the solution:


Next, I updated the version to 1.1:


Finally, I exported the 1.1 version as a managed solution (make sure all your customizations are published).  Ok, so we have the old and new managed solution version.  How do we create the “holding” solution?  Unzip the 1.1 solution, edit the contents of solution.xml like so:


I use _HOLDING in UniqueName and LocalizedName to make it obvious.  After you have saved the changes to the solution.xml file, zip up the contents of the unzipped folder:


…and name it something unique.  My conventions is to use a name similar to the latest managed solution it will “hold” for:


I replace _managed with _HOLDING in the name of the file.  Ok, now you are ready to accomplish a delete.  If you are still following along using the sample files, then do the following:

  • Import if you haven’t already
  • Import
  • Delete (deletes what’s not in the holding solution)
  • Import (creates the proper UniqueName reference to the items in the holding solution)
  • Delete (removes nothing but the solution based on the temporary UniqueName)

The end result is that you will have the items you deleted in your dev environment deleted in your target environment and the solution UniqueName is maintained.  Thanks again to Shan McArthur for explaining this to me.  This general approach can be applied to other “delete stuff that’s no longer used” scenarios as well.


Comments (17)

  1. Bruce says:

    Why do you have to have to delete the holding solution and add the 'new' solution?The holding solution is the new solution(1.1) aint it? Basically arent the last 2 steps the same?

  2. devkeydet says:

    No, they are two different solutions with different UniqueName values.  That's why you see two when you import the holding solution.  CRM sees it as a different solution from the same publisher.

  3. devkeydet says:

    During the delete process, the CRM server finds anything that's from the same publisher and effectively says "I won't delete you because another solution from the same publisher claims you too."  We're just using the rules of solution import to our advantage here to effectively delete.

  4. Bruce says:

    Sorry I wasnt quite clear enough, whilst the solutions names are different, their contents are the same arent they?So basically when you delete the holding solution then add the 'new' solution, there arent any component changes are they?….so couldnt you install the new solution( with the updated form & fields) and delete the old managed solution?

  5. keydet says:

    Yes, the contents are the same, but in two managed layers.  You delete the holding solution after the new version of the solution, but I think I understand your point.  While you could eliminate the last two steps, you would have to be accepting of the change in UniqueName nuance for what's really a new version of an existing solution.  I'm not Ok with that.  Therefore, I think the last two steps are worth the effort.

    I've updated the post to reflect this clarification.  Thanks!

  6. Neil Benson says:

    I always thought Shan was smart but too lazy to write good blog posts himself :). Thanks for sharing.

  7. Jan Nebendahl says:

    Thank you very much for this post, it helps immensely.

  8. Matt says:

    This method is not supported by CRM support, see the SDK:

    Customization XML Reference


    Editing a managed solution file is not supported.

  9. Arnaud says:

    @matt, this is not supported, but it realy helps. When MS will support 'deletion' of items then we can go back to the wonderful blue sky world.

    @keydet, thanks for this example. Do you have any 'unsupported 🙂 ' trick to delete DB Fields or to change fields type ? I have an issue in my Org about a field that has been created by external consultant as numeric but it must be alphanumeric. The workaround is to create a new custom attribute, but it's confusing for people building reporting stuff as the old field is still available in the database……



  10. Michael Blackburn says:

    The only thing that is unsupported is manually changing the unique name of the solution from DEV to "create" the _HOLDING solution. You could accomplish the same thing by manually creating two solutions with the same content in DEV. The approach described is simply more efficient and less error-prone (if you make a mistake by leaving something out when you manually create the HOLDING solution, you could potentially lose data (since that content wouldn't be "held."

    Manually editing the solution is a zero-risk proposition, but if you're absolutely (contractually) unable to do anything unsupported, this is still a workable approach, it just requires a bt more tedious work.

  11. markpittsnh says:

    Unfortunately, this approach is not able to remove option set values from an existing entity field.



  12. StingRayYellow says:

    THANK YOU!  We had a schema type mismatch on 9 different fields.  We used this approach to remove them.

  13. Vlado Turnic says:


    I need do this in CRM 2013. I've found the "solution.xml" file has different structure. It looks like this workaround doesn't work anymore in CRM 2013 (…/how-to-delete-a-field-from-one-crm-2013-solution-when-another-solution-is-built).

  14. Chris B says:

    I've tried this, and although I can get both the holding solution and original solution to appear under 'all solutions', when I try to delete the old solution, I get an error that StageId isn't a customer field and cant be deleted, although I does exist in my holding solution. It's no way related to the custom entity I'm trying to remove..

  15. Gee says:

    This helps me on our problems…. Thanks 🙂

  16. Krish says:

    I think, During Development, that is in Unmanaged Solution, if the Managed Properties Customisable is set to True, then we should be able to delete the required processes and entity attributes by bringing them to a temp unmanaged solution. I deleted some of the unwanted process in CRM 2013.

  17. Ronald Lemmen says:

    You can do this in a fully supported manner as well.

    In your dev environment, just create a new solution using the same publisher and copy all the same solution components to the new solution (tanguy's xrm toolbox has a tool to do this for you). Then export this as a managed solution and that way you have an exact copy of your solution with just another unique name / display name and you have not touched anything unsupported.


    Ronald Lemmen

Skip to main content