Managed Solution vs Unmanaged Solution Best Practices CRM 2011
Managed Solution vs Unmanaged Solution Best Practices CRM 2011 is an argument that has been had quite a few times since the advnet of MSCRM 2011. The choice of Managed Solution vs Unmanaged Solution can have a huge impact on how deployments go so it’s an important distinction. There’s a lot about development that left much to be desired in previous versions of Microsoft Dynanics CRM. B/c of how strange it was, new developers frequently abandoned traditional development practices and just did things in a largely one-off fashion. Microsoft Dynamics CRM 2011 introduced many developer friendly features and concepts, among them were Managed Solutions and UnManaged Solutions.
<SoapBox Process=‘AutoStart’ Completion=‘Automatic’>
My fundamental guidance is this – you can read all the posts you can, dissect solutions as I do in this article, but here’s the takeaway. Development and test all you want with Unmanaged Solutions. When you’re ready to package up your product and either deploy it or ship it, Make the Final Release Version a Managed Solution. Just like we use Debug builds for development and do a special Release compile for our final product, the same should be done here. The physical reasons are different but the functional ones are identical. So when it’s all said and done, which you should use amounts to “Both” . Using Managed Solutions for deployments that aren’t finalized will lead to unnecessary headaches. Using Unmanaged Solutions for final deployments will result in sloppy and potentially problematic installs (you can get either wrong, Managed Solutions aren’t a magic bullet – But they do allow you to minimize known risks and pretty much prevent such risks. Some problems may be inevitable but safeguarding against the ones you can control is the only prudent course of action. If there’s one thing I want you to take away, it’s this. You may have valid reasons for doing one or the other but don’t do it based on superstition of water cooler talk. Development goals regarding deployment are pretty universal – do it, do it right, make it predictable, make sure it works, if it fails, make it easy to diagnose and correct. To that end, Unmanaged Solutions throughout, Managed Solutions for the final product are the winning combination for pretty much everyone. This isn’t the final world on everything related to solutions, I’ll explain ‘why’ later and show how to do it and automate it with TFS Build and MSBuild, but this is the groundwork needed before going much further.
The term Solution is one that’s used all over the place but it’s a proper noun in this sense. Moreoever, although it’s a proper noun, it’s one that’s used in a different context from the other Proper Noun Solution used in Visual Studio Development. Anyway, I want to start a discussion about Solution Management and Dispel some major nonsense that’s prevalent in the CRM Development community.
In theoretical terms , the question “Shoudl I or Shouldn’t I use Solutions” is an idiotic one. You are going to use a solution whether you want to or not, whether you realize it or not. By default, when you install CRM, a solution, not surprisingly named the “Default Solution” is created. When someone asks if they should use a Solution or not, what they really mean is “Should I use a solution OTHER than the Default Solution“.
I’ll cut to the chase on things and work my way backward from here. Also, I’ve read more discussions on the net about the issue than I care to recall and I’ll link to them at the bottom (it’s a waste of time for the most part unless you really just feel compelled to prove something to yourself and are a glutton for punishment). Remember though, just b/c it’s on the Internet, just b/c it’s on a blog and the blogger has a fancy title, just b/c he seems certain of himself, just b/c she has tons of commenters who agree, that doesn’t mean someone is right. [Note that I'm referring to myself just as others in many of these cases - so I'm not just saying, I'm YELLING, Don't just take my word for it - Look for yourself!!!! ] These can all be good indicators, but people are wrong frequently and commentors can at time be little more than an echo chamber. Additionally, there are often prevailing myths repeated over and over that are completely untrue. If you don’t believe me, I’d use the example of “Benefits of Stored Procedures” as my best example. For a long time, it was taken as axiomatic that Stored Procedures were preferable to in-line SQL (particularly with SQL Server) b/c of Security, Performance and Maintainability. Everywhere you turned, every forum, blog post after blog post, you’d hear someone parrotting the line about Stored Procedures being a best Practice. One day, my friend Frans Bouma whipped out his PimpHand, puts some weights in it for good measure, and just issued a collective Bitch Slap to all the Stored Proc Fetishists out there. It caused lots of butthurt, there was much gnashing of teeth, but what there wasn’t was a Legitimate Rebuttal to Frans post. And what made Frans bitch slapping so worthy is that he didn’t just use his opinion or experience, he went straight to the Sql Server Books Online documentation and took it straight from the horses mouth. Although this post is about Managed Solutions vs Unmanaged Solutions, I’d like to quote from his post to illustrate the point (b/c in the rest of this point, I’m going to copy my brilliant Dutch Friend’s technique):
Everyone who thinks stored procedures are pre-compiled, say “Aye!”. Whoa, what a noise! For all of you who said “Aye!” a few seconds ago: open SqlServer’s Books Online (v7 or v2000, doesn’t matter), search for “cache execution plan”. You’ll find fine articles like “Execution Plan Caching and Reuse” and “SQL Stored Procedures”. Let me just quote some lines from the “SQL Stored Procedures” article:
SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans.
One last thing before going too much further. I’ll posit that there’s the conventional wisdom going around about Solutions (Managed Solutions and UnManaged Solutions Alike) that says something to the effect of “If you’re a 3rd party vendor, use Managed Solutions b/c you have to, otherwise use Unmanaged Solutions b/c Managed Solutions aren’t well suited to in house development”. Here’s a few samples:
- Managed and Unmanaged Solutions in CRM 2011
- Managed Solutions or Unamanaged Solutions in CRM 2011: Best Practices
- Managed and Unmanaged Solutions in CRM 2011: Know the Difference
- Difference between Managed and UnManaged Solutions
- Managed to Unmanaged Solution Dynamics CRM 2011
- Bing.com – Managed Solutions vs Unmanaged Solutions
- Google.com – Managed Solutions vs UnManaged Solutions CRM 2011
Each of the discussions brings up valid points and does a good job highlighting the differences. My problem isn’t with any of the discussions. However different people can walk away from reading the exact same thing and have completely different conclusions. After reading any of those posts or coming here, I hope you understand the basic distinctions. I hope you’re hear to see why I have a different opinion and what proof I offer to support that opinion.
So the consensus seems to be that if you’re a 3rd party vendor or ISV, use Managed Solutions (mostly b/c you have to). If you’re in-house, use unmanaged solutions b/c Managed Solutions aren’t ready for prime time, don’t apply to your development scenario or are too punitive in the way they behave. I’m calling Bulls*** on each of those. Again, just to be diplomatic, I have tremendous respect for everyone I linked to above (in fact you may well notice I’m a featured blogger on one of the sites – or was anyway in a previous life). I think they all cover the issue correctly. The commenters are where things are going off the track (and those are frequently cited) and those for some reason, tend to set the tone of the conventional wisdom.
Managed Solutions Are Only Good for 3rd Party Vendors and ISV’s:
This one annoys me the most. It’s true that if you want to sell things in the MarketPlace, you need to use Managed Solutions. But if you have to draw a naive conclusion from that fact alone, wouldn’t you assume that it’s a “GOOD THING” since Microsoft forces them to use them? The retort I frequently hear is “Well maybe that’d be a safe assumption, but the reason is b/c it has to be that way to distribute it.”. Well, that’s not true. I can send you an installer package or give you an unmanaged solution and you can easily install it. There are API methods that handle installation and they don’t discriminate (if you’re not familiar with it, the ImportSolutionRequest and ImportSolutionResponse messages handle this for you). We know that everything that happens in CRM happens through the CRM Web Services so there’s nothing magic about clicking the Import Solution or Export Solution buttons. They trigger internal web service calls and on importing, the ImportSolutionRequest is what’s behind the button click. My point is that you can just as easily pass a byte array from an UnManaged Solution to the ImportSolutionRequest call as you can a Managed Solution’s byte array – so the whole “Deployment” issue is a non-starter. That leaves us at “Microsoft determined it’s the most effective way to distribute content” as a starting point.
But let’s look at this another way. There might be things that could benefit a child but not his parents. There could be things that benefit a husband and not his wife. But what’s different in this regard? If getting X deployed in your environment if I built it, what’s different if you built it? Either way it needs deployed easily, correctly and effectively. It needs to work, it needs to fail gracefully if it fails and it needs to let us know how things went (so we can confirm things went well, or track down where they didn’t).
Some will make the case (which is not very compelling) that Managed Solutions are used to protect intellectual property. Well, as flimsy as it is, I would argue the same applies as a benefit to in-house shops and ISVs. The reasons may be different, but the fewer people that know the inner workings of the software, the better in terms of security. In either regard the Public API is visible and how to use the Black Box is known – so the only difference is seeing the inner workings. If it’s in house, development will have those details so there’s no downside in this regard. This means that 3rd party vendors can keep prying eyes out but allow them all the info they need to use the stuff, and inhouse shops can do the same while allowing people that *should* see the inner workings see what they need.
The Whole Value of CRM is Customizing Entities – With Managed Solutions People are Prohibited from Doing that
This is one of those points so utterly dumb I am almost embarrassed to refute it. Few people should have direct access to the Deployed Project. Users should be able to use it, but as far as being able to change schema, dlls or the like, the fewer the better. if you don’t concede this point, I really can’t help you. If you’re making changes on Production, you’re doing it wrong. Production shouldn’t be your sandbox. It shouldn’t be a place to experiment. It should be the place where things go that are tested and verified. So, in development, you use Unamanged solutions and change them all day long. Then in production, you use a Managed Solution to stop people (and access control should be doing this primarily) from doing this. The Managed Solution is the 2nd part of a structured insurance policy. This is a feature not a bug, and if you can’t see that, you’re looking at it incorrectly.
Managed Solutions Mean Data Loss
You have the ability to fully uninstall a Managed Solution and if you do, it does what it’s supposed to – it removes what was added in the first place. So yes, this could mean data loss. However data loss isn’t the issue, it’s unwanted or unexpected data loss. Even if it really risk unwanted data loss, the database should be getting backed up regularly so you should have backups with the pre-rollback version. But even granting this can be misleading. When you uninstall something, you typically want it removed which is what uninstalling a managed solution does. Let’s say we had an inhouse system and we found out it was computing incorrectly and letting people take out more money than they had. We decide that it needs removed and rebuilt. Do you want to let this exist in any capacity until the new version is rolled out? No, you want it stopped. The confusion comes from people thinking that Bugs and Service Pack type additions entail a full rollback. That’s not the case. You use Managed Solutions (and UnManaged ones) in a Structured or Scaffolded approach – you add to them. If a field is removed in a later version, that’s by design and it shouldn’t be there anymore, otherwise you’d leave the field in. If the data needs stored “just in case” then you’d keep a backup – but the field should be gone from the production system. If not, then it shouldn’t be removed in the first place. DUH.I could go on and on about every possible solution but suffice to say I’ve dealt with this inside and out and there’s only data loss if you do it wrong, handle things incorrectly or are completely careless. Changes should be made through updated versions, not removal of the old system and reapplying it. If you do this, data loss won’t be an issue for you. (If you want to argue some one off scenario with me – please do so in the comments. I admit I didn’t cover every possible example but I’m prepared to if someone wants to argue)
Managed Solutions are Too Rigid
By this they usually mean that at some point, just b/c you put something in a Managed Solution, it can never be changed. This simply isn’t true. Just b/c it’s in a Managed Solution doesn’t mean it’s wholly locked down, If it’s locked down it has to be done so by design, intentionally, so the author(s) will know exactly what they’re locking down (again, it doesn’t happen by default or magic).
Managed Solutions Don’t Work for Large or Complicated Enterprise Installs
This is another one of those myth’s (I believe started by a commentor at Gonzalo’s excellent blog. I’ll note it wasn’t Gonzalo making the point. Ok, so some guy on a blog comment says he had problems with the feature, so clearly the feature is the problem. If that was true, then the whole 3rd Party/ISV market would cease to exist and what was there would be vendors currently being sued out of existence. I don’t want to be accused of pimping anyone’s projects but I can tell you for sure that many products in the market are being used on HUGE, Extremely large, extremely complex installs and working just fine. Look through the marketplace. Do you see any warnings “Only works on Single Web Server or Database Server”? Nope. Do you see any “Won’t work with Firewall”, or “Won’t work with Load Balancer” or “Won’t work with Clustered Servers”? Me Neither. That’s b/c no such warnings exist. Look around the feedback – while there hvae been problems with certain vendors products (software after all isn’t a bug free endeavor, especially with new products) do you see any that have great feedback saying “Works Killer on our Single Server Simple Install” and then diametrically opposite ones “Absolute Disaster on our Big Complex system”? Me Neither. That’s b/c they don’t exist. This is 2012 and particularly in an online marketplace, if your stuff sucks and has problems, it’ll be known. There’s other issues with any given product, there are even issues with CRM 2011 itself, but not anything magic with CRM 2011 and Managed Solutions.
This leads me to my main point. Look at all the discussion about the vast differences between Managed Solutions and UnManaged Solutions. They mostly read like a list of bullet points (and that’s fine, most people want a synthesized side by side comparison) . Many of these are just taken verbatim from the SDK documentation or taken from other people’s blogs (Sadly, I’m starting to get popular enough that I’m getting a lot of people plagairizing my content and when searching for other items, I see a lot that’s plagairized as well). Spouting off something when you didn’t do the research and you’re holding yourself out as an Expert (which being a blogger tends to do at least implicitly) is irresponsible. But blogs are free content so it’s buyer beware. So what is a solution?
MSCRM Solution File
In it’s basic form, it’s a .zip file containing a minimum of 3 .xml files:
The below image shows a basic structure of an unmanaged solution that has only a few entities in it (no web resources, no workflows or plugins) and for the record, a managed solution showing the same items would look identical:
Ok, nothing too dramatic (and we’ll go through what’s in those files shortly. However this shows a relatively trivial solution, most production ones will have other items such as Web Resources and Workflows/Plugins. So what does a ‘real world’ non-trivial solution look like? See the next image:
Pretty much the same thing but with a Workflows and WebResources folder.
The Workflows Folder (Managed Solution | Unmanaged Solution)
If you examine the Workflows Folder show above what you’ll see is a bizarrely named .xaml file. That file(s) (unless you named it yourself when you added it and changed it to something without a Guid identifier in the name) will typically look like some name you gave it and/or the process being performed with a Guid appended to the end of it. CRM does this automatically in part to help insure that the resource name doesn’t run into any conflicts with existing or future items. But yes, it’s just a xaml file with a distinct name as shown below:
The WebResources Folder (Managed Solution | Unmanaged Solution)
The Web Resources folder isn’t much different, it contains each of the Web Resources with a Distinct name and a little identifiable information on it:
It’s worth repeating at this point that if I had done this with a Managed Solution instead of an Unmanaged Solution, nothing I said so far would be different.
When you dig into the Solution file, it reminds you of what a Visual Studio Solution (.sln) file looks like. What’s that mean? In it, there’s XML that contains information about the projects and their locations that the solution contains. Combined with the Project file (which in turn is just an XML file that provides build instructions about all the contents it contains, via XML of course) MSBuild has all it needs to create the applications or web sites specified in the respective projects and solutions. There’s no exact metaphor equivalent for Projects here, but the Solution.xml file simply contains information about all the items that will be deployed (it has information about missing dependencies and a few other nuances – which are used to help drive the Import Solution UI Sequence). In a nutshell though, you’ll see references to the items shown above, along with the other deployment artifacts:
<RootComponent type="61" schemaName="gaf_acctmgtsolutionconfig" /> <RootComponent type="61" schemaName="gaf_acctmgtsolutionconfig" /> <RootComponent type="61" schemaName="gaf_script_account_fields" /> <RootComponent type="61" schemaName="new_html_twostepper_warning" /> <RootComponent type="61" schemaName="new_icon_accountimportid_16" /> <RootComponent type="61" schemaName="new_icon_accountimportid_32" /> <RootComponent type="61" schemaName="new_icon_area_16" /> <RootComponent type="61" schemaName="new_icon_area_32" /> <RootComponent type="61" schemaName="new_icon_corporatenotes_16" /> <RootComponent type="61" schemaName="new_icon_corporatenotes_32" /> <RootComponent type="61" schemaName="new_icon_coverage_16" />
As you can see, there’s a direct mapping with the only distinction (if I showed you the entire contents it’d probably be a little clearer but too wide to easily show in the blog layout) is the Guid appended at the end – but look through the sample, you’ll see the name equivalence. The main other piece is the Customizations (which show what will happen to the entities). On Import, here’s what happens.
Each of the web resources are examined and corresponding deployment api methods are called on them, putting them in the active system. The customizations are reviewed and the corresponding changes are made to it (ultimately they translate to SQL DDL Statements, ALTER TABLE, CREATE TABLE and the like – I highly encourage you to turn on Sql Profiler on an Import to see this happen real-time if you’re seriously intersted in learning what happens).
So let’s summarize the Import Process. A .zip file is extracted and the items are taken apart. Each one has its own purpose, but basically you have a portion that looks at various text , xaml and compiled code and inserts it into the CRM Database. It also extracts information needed to build SQL Statements, and it uses that to fire changes that need made to the schema. This ends up meaning you have some conversion and a bunch of Web Service calls and SQL Statements being fired. That’s a SOLUTION. That’s what it does. Managed Solutions vs Unmanaged Solutions to the EXACT SAME THINGS. Where they differ is exclusively on the parameters passed in to those methods which tell it what behavior to allow. But that’s an implementation detail. That means you could have an Unmanaged Solution that looked exactly alike and behaved almost exactly like a Managed one. That means you could manually edit an Unmanaged solution to be a managed one and vice versa (doing so would be a silly waste of time outside of illustration, but could be done nonetheless to prove the point).
At some point in the future, (as soon as I have time, hopefully tomorrow) I’ll go through the solution elements one by one and show exactly how they work, but my point for this post is to show the differences, and lack thereof of Managed Solutions vs Unmanaged Solutions. Now that we know what goes into a solution, and what it does, let’s see if they’re really different after all.
I went ahead and created a CrmOnline sandbox at CrmOnline. I created a few small customizations and then made a Solution named “UnManagedSample” (probably should have just named it sample, since the same solution was exported, first as an UnManaged Solution then as a Managed one. But suffice to say, I used the exact same entities, had the same dependencies met/ignored, used the same settings and did everything so it’d be identical other than making one managed and one unmanaged. Here’s the output for both. Be honest, can you tell which is which (remember they both have the same name “UnManagedSample” so don’t try to cheat using it).
First off is a side by side showing the structure of the Managed Solution versus the Unmanaged Solution:
Here’s the first one:
Here’s the second one:
Lest I be accused of cheating by collapsing the elements, note that the file sizes are identical (which could mask differences possibly, but I assure you in this case they are identical. In fact, you can pull down both sets if you’d like to compare them on your own, which I would highly encourage you to do so you don’t just take my word for it:
The main thing I wanted to dispel was the myth that there’s some major differences between the two. As you can see, in this example, they’re virtually identical in every single meaningful way. The differences aren’t even inherent. Yes, these are trivial solutions but that doesn’t change the nature of anything. That doesn’t mean there aren’t practical/functional differences, but when you see it from this perspective, all the “Doesn’t work in large deployments” mythology starts to look pretty flimsy, doesn’t it? So next up (the post isn’t up yet but will be – so i”ll update when it is, the link is already setup though so you can count on it being there – Managed Solutions vs Unmanaged Solutions, Part II) I’ll walk through what each aspect of the solution does and show specific instances of differences between the same solution being implemented with Managed Properties (which is where the real differences lie). Remember this – if Managed Properties aren’t used on the Entities, there’s not any real difference between the two solution types as I showed above. Once we change the properties to Managed Properties, we’ll start to see some differences, but they’re still quite minor. So all this arguing is around basically, how many angels can dance on the head of a pin.
KeyWords: Dynamics4, Dynamics4.com, Managed Solution CRM 2011, Unmanaged Solution CRM 2011, Managed vs Unmanaged Solution, CrmConnection, ImportSolutionRequest, ImportSolutionResponse, PublishAllXmlRequest, PublishAllXmlResponse, CrmConnection, CrmConnection 2011 , Solution Management Best Practices MSCRM 2011