Going from unmanaged to managed is easy! Just export as managed and your done ! Moreover, With Azure DevOps pipelines, it is easy to automate export in unmanaged and managed at the same time. Then, when importing to a new environment, you could choose the manage or unmanaged version. This will also be very helpfull if for any reason your dev environment is lost.
Maybe be a bit more carefull when importing this new big managed solution in another environment, do a first test in copy of the instance to check if everything is correct.I think that your greatest work will be to create the Big Solution! If you still have the previous sprint solutions (or perhars the zip files for the older ones ?), you could use the wonderfull "Solution Component Mover" from XrmToolBox to help you.In the future, you may consider using "Clone a patch" from your big solution to manage each of your sprints !Best regards,
I would NOT recommend going to manage, especially if you are the only developer for an in house solution. If you are selling your solution then managed is the only way to go. But for in house projects managed solutions just add unnecessary headaches. Remember that managed is an all or nothing deal. It is a lot easier to remove components in an unmanaged solution and VERY painful in a managed solution.And if you use patches, you are out of luck with managed.
- A patch is created for unmanaged solution. You can't create a patch for a managed solution.
JonasHow would one remove a component in a managed solution? If I have unmanaged, then it is a simple delete of the component. I still haven't found a painless way of doing so in managed.
I have to disagree about the "insensibility" of unmanaged. We have a dev, stage, prd environment utilizing devOps. We have been using unmanaged solutions to promote enhancements, changes and patches between environments without any issues. Yes, there is more responsibility with managing the components, but at least we have that freedom without being bogged down by a managed container. Managed solutions would lock you down.
I know MS has been pushing for us to use managed. But it still doesn't make sense to me as to why we should do it for an in house solution with all of its restrictions with no clear benefits. I would appreciate it if you can provide any info that would cite these managed benefits.
"I'm just wary of doing this in the event that going from unmanaged to managed messes something up." - original post
I may be mistaken, but I thought Steve was trying to find out what cost he would be paying for the benefit of not having to clean up old unmanaged solution containers.
Found the answer to my primary concern, but how difficult is it to incorporate the process to devOps?
Based on the article I posted, I think you are missing a few steps. The author specifically stated.
If you try to delete one the components manually in production, you will get this kind of error, because the components are in a managed state.
To which he then outlined the required steps to create a clone solution which you then merge with your target solution.
Repeat 3-4 for PRD.
And you are correct about what you said about managed and unmanaged. But I think you will encounter some difficulty when it comes to DevOps. You need an Azure component that would do the managed upgrade merge (I don't think there is one yet) or you will have to write a custom powershell script to do the aforementioned steps. This is not a problem for unmanaged as the necessary components are readily available.
$existingSolutionResult = Get-CrmRecordsByFetch `
-conn $connection `
-ImportAsHoldingSolution:($existingSolutionResult.Count -eq 1) `
-MaxWaitTimeInSeconds -1 `
$upgradeSolutionRequest = New-Object Microsoft.Crm.Sdk.Messages.DeleteAndPromoteRequest
$response = $connection.ExecuteCrmOrganizationRequest($upgradeSolutionRequest)
There are a number of inaccurate statements in this thread and I want to shed some light on the topic and where we are going.Here is the official statement for the use of managed and unmanaged solutions and I hope that it helps add some clarity for the community: Unmanaged solutions are to be used in a development environment and to be exported and processed by Solution Packager to be checked into your source control system. Managed solutions are to be used to deploy your solution to all other environments.Notice that at no point in that statement is team size, project complexity, or other dimensions a factor in the appropriate solution type. It really is as simple as that.Deleting components is only possible through solution import actions if you are using managed solutions and if you use the stage for upgrade (or promote and delete) mechanic. In the new UX, this is now the default behavior. To delete a component, simply remove it from your solution in your development environment and export a newer version of your solution file (as managed). Import that into your production environment using the stage for upgrade mechanic and the system will remove that component.We are making a lot of investments this year in making solutions more reliable and easier to work with. We are adding many more components to solutions, cleaning up the UX, investing in making solution import a zero-downtime and non-disruptive experience, giving you better insights into layering, and the ability to undo active customization. We are also shipping Azure DevOps tasks to help enable easy ALM automation. ALL of our investments are based on the design of managed solutions. Any advise to using unmanaged solutions for deployment is doing customers a disservice as it will put them on an unhealthy ALM path and will make it more difficult to use solutions and to automate ALM. I find that most folks that are still advocating the use of unmanaged solutions are doing it because of their experience years ago and how difficult it was. I would encourage them to refresh their knowledge and consider the proper way of using solutions to enable healthy ALM - whether they are a one person team or embedded in a larger project team.A quick checklist for everyone to self-assess your ALM health:1. You consider source control as your single source of truth and not a running environment.2. You check in your unmanaged solution files after they are unpacked using Solution Packager (or our unpack task in our DevOps tasks)3. You deploy managed solutions to all other environments (test, UAT)4. You run solution checker in your ALM pipeline5. All ALM operations are automated and do not require manual deployment steps to be taken6. There are no unmanaged changes in your production environment - all changes are brought through only using managed solutions.7. While you are developing a solution, your development environment will *only* have the direct managed dependencies installed and no other solutions, and you do not ship multiple solutions from the same environment.
ShanWhat does MS recommend in the "Dev Refresh from Prd" scenario? It should be easy to just restore the Prd DB to Dev, change the managed solution to unmanaged and be on our merry (following the recommended) way. This feature has been requested since 2011 and so far no official solution nor guideline was given.
As I have stated before, this is the only thing that is keeping us from going managed. Thanks!
ShanThe "refresh dev from prd" is not for the sake of solutions/code, but for the sake of having a dev environment that has production data. As you have stated, unmanaged solutions is for the dev environment. So a feature that would allow us to easily change managed to unmanaged after a dev refresh would be perfect. This would allow developers to code and test against real world data and have "very near production" results.
This is a common practice in many erp systems like SAP. It would be nice if CRM has this feature as well.
Thanks for taking the time on this subject.