Personalized Community is here!
Quickly customize your community to find the content you seek.
Microsoft Customer Co-creation
Help impact how the tools and services you rely on are developed. Microsoft Customer Co-creation connects you directly with our engineers so you can provide feedback before a single line of code is written. Interested? Learn more at Microsoft Customer Co-creation
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In a general three instances environment (DEV, QA, and PROD), you may face the choice of unmanaged or managed solutions. Except distributed solutions, in what situations do you use an unmanaged solution?
What are advantages in using an unmanaged solution?
Thanks for reading and answering my question.
This link may be helpful.
My advice (from some very bad experiences with Managed Solutions) is that unless you are an ISV shipping a solution to many clients - stay unmanaged!
There are so many pitfalls with Managed solutions that they are too many to describe. Ultimately they allow you to back yourself into a corner that you can't get out of!
Hope this helps
Hi, you should create an unmanged solution in your DEV environment and export it in managed solution to import in in youy QA and PROD environment.
So you can modify your solution only in the DEV environment and can be sure that your 3 environemnt are OK
Not that I want to disagree with Scott ( he is a legend after all :)) but I normally opt for unmanaged in dev, managed in QA and PROD. I know there is a real split with professionals about what is best and the safe answer is what ever is the right fit for the client, if they have tight change control the managed path is a great way to enforce that. If they are a small business and have limited resources they may not have those requirements and need the agility. The big downside of managed solutions is if you lose the unmanaged version (it does happen)
I think managed solutions became easier to digest with the introduction of patching https://msdn.microsoft.com/en-us/library/mt593040.aspx
I really appreciate the debate!
I'm not saying it's best practice one way or the other. Indeed - the 'theoretical' advice from the platform team is to do as you suggest and use managed solutions in deployement downstream from DEV.
Rather - I'm recommending that you only take the managed solution approach if you are 100% certain that you actually need it and it will give you significant benefit over an above the likely issues you will encounter.
I find that if a company has a tight change control process then this often means you don't actually need to opt for managed solutions - so I disagree that it has anything to do with change control process.
Managed solutions do not enforce a change control process - nor do they prevent unmanaged changes on production. As a result, as soon as you get an unmanaged change in production you can be locked out from applying your managed changes.
The top 3 advantages I see with managed solutions are:
1. The ability to delete attributes/entities etc. on solution install. Something that unmanaged can't do - but is often undesirable due to data loss. The Solution Packager automatically creates a holding solution and gives you the opportunity to migrate data as an intermediate step.
2. The ability to have your client create unmanaged changes on top of your solution so that you can update it without changing their customisations.
3. The ability to combine multiple changes from different sources so that they can overlap without affecting each other.
These are all points are very important to ISVs - but less so if you are completely in control of your DEV/QA/PROD systems.
I have been burnt so many times with managed solutions and ended up with some customisations 'concreted' into PROD with no supported way of changing them - this is just a word of warning that you really need to know what you're getting into when using managed solutions!
Personally I would like to see managed/unmanaged being an Organization setting such that by switching to 'managed' on an org - it means that there is no way of applying unmanaged changes - and installing managed solutions is guarenteed to overwrite the current metadata. Whilst ever we have a hyprid - I'm going to stick with the path of least resistenance unless I absolutely have to.
I agree with Scott. We have been using the standard approach for several years now and we have a buildup of deprecated fields, jscript, workflows, etc.
Also the managed solution importer has many bugs that require us to make post deployment changes.
Only a limited number of people should have admin access to a PROD environment so I can't see the value add of a managed solution.
Rollback is best achieved at a database level rather than uninstalling a managed solution.
Scott Durow how to you come around first limitation? I'm now using SolutionPackager / PackageDeployer to "sync" developer organizations. with unmanaged solutions in all dev environments + prod and component deletion is biting us (having to do it manually between developer organizations is pain). But I guess managed won't help as DEV environments still have to be unmanaged :doh:
You've only been burned by managed solutions where unmanaged has different customizations on top? How is that an issue if you are completely in control of all systems?
Probably stuff should be just hanging in the solution, just unused (scripts, plugins)/deactivated (workflow) state?
Business Applications communities