You’re offline. This is a read only version of the page.
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.
Runner288
ScottDurow 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?
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.
Hi Jamie,
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.
Thoughts?
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
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
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
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (