-1

We have a problem deploying our CRM solution from our development environment [Dev] to production [Prod] in the following scenario:

  1. Create a new custom field (new_number) on the Account entity in our unmanaged solution in [Dev]
  2. Export our solution as managed (v1)
  3. Import managed (v1) into [Prod]
  4. Delete custom field (new_number) from our unmanaged solution [Dev]
  5. Export our updated solution as managed (v2)
  6. Update [Prod] with managed (v2)

At this point, the field (new_number) still exists in [Prod]. From what I have read elsewhere, this is by design: the fact that the field is not in the managed (v2) solution would not cause it to be deleted from the default solution in [Prod].

So my question is - how do I remove this field from [Prod]?

If I try to delete it from the default solution, I get the following:

Managed Properties Error: You cannot complete this action for this component because of the configuration of its managed properties

Any suggestions much appreciated!

We are using CRM 2015 on-premise 7.0.1.129 (DB 7.0.1.129)

1 Answers1

0

This blog post about creating holding solutions should still work for CRM2015.

Matt Dearing
  • 9,286
  • 1
  • 23
  • 25
  • Unfortunately we have another issue where CRM is not allowing us to delete the managed solution (described at: http://journeyintocrm.com/archives/545) so I will have to solve that problem before I can try this suggestion. – Danny Byrne Aug 11 '16 at 14:04
  • I guess I'm just surprised that MS does not provide a 'proper' way to delete fields in this scenario, especially given that the documentation seems to guide you towards using managed solutions for deployment. – Danny Byrne Aug 11 '16 at 14:08
  • We only use managed solutions when doing work for ISVs. If you're doing development for your own company or for another company who isn't giving the solution out to their customers then I'd stick with unmanaged. When using managed, the hope is that before the solution is deployed to customers you've pretty much figured out your schema but, over time there will be "dead" attributes no longer used in the customer's environments if they have early versions of the solution. – Matt Dearing Aug 11 '16 at 14:21
  • We had a similar issue and we ended up paying a lot of money to the Microsoft Support, which told us, that there was an object (in that case: an instance of the standard-entity SLA I played with), that had to be removed from the unmanaged (dev-) solution. Microsoft is pretty terrible with error messages, I guess they want to earn from support tickets, because that error could've easily been detected and then put out in a comprehensible error message... – Johannes Aug 16 '16 at 16:23