Well to start with, I’m sure that I’m going to get pulled up by some people for my use of the word ‘field’ in the title. After all, officially it’s now a ‘column’! But I (still) can’t let go of calling them as I’ve done so for over a decade, so field it is.
Now to the actual topic of this blog post, which is centred around Managed Solutions. Leaving aside the whole debate about whether we should be using managed or unmanaged solutions (& when/where to do each), there is one definitive benefit of using a managed solution.
See, unmanaged solutions are additive in nature. Work is done in the development environment, then deployed. Further work is done (additional items added, etc), and deployed, and they then appear in the downstream environments. However, if you delete an item in the development environment, it’s not removed when the solution is deployed downstream.
Managed solutions, on the other hand, are both additive & detractive. As with unmanaged solutions, items added in the development environment are also added downstream when deployed. However, if an item is removed from the solution in the development environment, it will also be removed when the solution is deployed downstream. It’s one of the useful ways to ensure that you don’t end up with random unused items just lying around in Production (which have a habit then of popping up in the Advanced Find window, for example). So it’s really quite handy for a lot of reasons to go down this route.
Well, I found myself going down this route recently, but with slightly unexpected results, I’ll freely admit…
The scenario was that we had deployed a managed solution to the UAT (test) environment on a client project. Then the client changed their mind (shock & horror!!) as to a specific item, and we needed to change it from a text item to a lookup item. Obviously (as per best practise, of course) this would need to be done in the development environment, and then released downstream. Given that this is a managed solution, I’d expect this to work, without any issues. Well, it didn’t…
The change in the development environment (deleted the old item, ‘re-created’ it as a lookup with the same system name) was done, we exported it as managed, and then went to import it in the UAT environment. It took the solution file, thought about it for a while (it’s somewhat of a large solution), & then errored:
Exception type: System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault] Message: Attribute mdm_field is a String, but a Lookup type was specified.
Now I was somewhat confused by this message occurring. It’s not been the first time I’ve seen it over the years, but in my previous experience I’ve seen it when handling unmanaged solutions. It’s when you delete an item in the development environment, re-create it as a different item type (with the same underlying system name), and then deploy it as unmanaged. The solution import in the second environment fails due to the different in the type (as it sees the same name). This, of course, is to be expected.
But here we’ve been using managed solutions for deployment, and as mentioned above, they’re detractive as well. The expected behaviour (at least from my side of things) would be that the system would note that the item type has changed, remove the old item, & import the new item. In my mind, that’s logical, but apparently not?
See, even managed solutions have their limitations, of which this is one of them. Having checked with several other people who I reached out to around this, I’ve discovered that it can’t work in the way that I was expecting it to. Instead, a specific process has to be followed
- In the development environment, remove the item, & export the solution as managed
- In the downstream environment(s), deploy this (interim) managed solution. This will remove the item from the environments
- In the development environment, re-create the item with the different system type. Then export it as managed
- In the downstream environments, deploy this solution. This will then add the item (with the new system type) into the environment.
This means that development & deployment teams (if separate ones) need to co-ordinate around this, to ensure it’s done in the right way. It could also be developed/exported in succession, and then imported in succession as well (either manually, or through an Azure DevOps Pipeline, for example).
This worked wonderfully for us, and to be honest, I was quite relieved after several hours of frustration with things. Even better, it was a Friday, so meant that the week could end well!
Have you ever come across this, and been frustrated as well? Have you got a similar story with something else that happened to you around solutions? Drop a comment below – I’d love to hear!
Yes came across this same situation many times and the steps you had mentioned been followed but here lies an important development team management issue. They should be organised and managed to tackle these situations otherwise you will struggle in solution deployment.
Hi Faisal
Indeed so, hence why I mention above the need to co-ordinate around such things!
This is pure horror. I really wonder which citizen IT persons have developed the dataverse solution? It takes a professional IT department to use the dataverse due to the limitless shortcomings and design flaws.
Curious as to why you think this is ‘pure horror’? Developer environments shouldn’t be used for Production environments, so I’m not seeing the issue.
Well, this article has helped me out, so thanks! A further question though. What if the change needed is identified after the managed solution is live (production) and being used for real data. How do we go about migrating / not losing data out of that field (which will be deleted and recreated)?
Amazing to hear – glad it’s helped!
If you’re needing to re-create a column, you’ll need to create/release a solution with holding column in place, migrate the data to the holding column, then release the updated solution, and finally migrate the data back. It’s a pain, but really the only way I’ve seen it being done.
You have two options to choose from:
1. Initially do an ‘Update’ deployment of your managed solution with the new column. This will be additive only and will not delete the old column. Then run your data migration routine to migrate data from the old column to the new. Then do an ‘Upgrade’ deployment of your managed solution which will result in deleting the old column
2. Alternatively you can use the two-stage managed solution upgrade process, which involves an ‘Import as holding solution’ step, followed by an ‘Apply Upgrade’ step. The first step introduces the new column and the second step deletes the old column. Between the execution of these two steps, both the old column and new column will be available and this is where you can run your data migration routine to migrate data from the old column to the new column between these two steps.
This is a fantastic solution. I was facing the same issue, tried Attribute Manager tool from XRMToolbox to update the field in dev environment as in my case, the field in QA was decimal whereas the same field was made string in dev after initial deployment to QA, but attempt to update the field via the tool didn’t work.