We are a Housing Association. We use CRM 2016 SP1. Our Dev and QA environments are single server configuration and staging and production are multiple server config with load balancers. Our custom solutions in QA, staging and production are managed.
We needed to update a "Quick Find Active" view for two of our entities Person and Property with some extra search columns in our staging and production environments.
I added the new columns to those entities' views in Dev environment by going to Settings->Solutions->[custom solution]->Entities->[custom entity]->Views->Quick Find Active [entity]->Add Find Columns. I did the same for both entities.
To deploy the update to other environments as a patch, I exported a standalone solution file that only contained the Person and Property entities with the updated views. I then imported the solution file into the QA environment to test.
Having published the changes in QA after import, I checked the entities' Quick Find Active views in the default solution (Settings->Customization->Customize the system->[custom solution]->Entities->[custom entity]->Views). I noticed that the Property entity was updated with the changes but the Person entity was not. It made no sense.
Having spent some time to search the Internet for an answer to no avail, we decided to try out the patch solution in staging. So we exported the solution file but before publishing the changes we decided to check the update. To our surprise, both entities had been updated. So we did not publish the changes.
Happy with the result and blaming the problem on our QA environment, we decided to go ahead with the deployment to production. We imported the file and check the changes and noticed that this time around the opposite happened to our entities, i.e. The Person entity had been updated but the Property entity had not!
We tried publishing the changes but it made no difference. So at the end we gave up and had to complete the deployment by manually updating the views in production.
I am wondering if anyone else has experienced this oddity. Any help/suggestion is greatly appreciated.
You mention that you are deploying managed solutions, and that your changes are not taking effect. The entities contained in the solution have previously been deployed to the target environments.
If you have previously made any modifications directly to the target environment (which would not seem improbable given that you did so this time), these changes will be in the unmanaged layer, which by default overrides changes in managed solutions:
MSDN says:
Because unmanaged customizations are considered ”above” any managed
solution in terms of conflict resolution, organizations installing an
update to a managed solution may not see their changes applied because
of unmanaged modifications. An option exists to make sure that changes
applied by an update to a managed solution are available.
When you
release an update to a managed solution, the organization installing
the update can select:
To preserve any customizations it has applied on top of your managed solution.
To overwrite any customizations it
has applied on top of your managed solution.
In conclusion: Never make any modifications directly to your target environments if you are using managed solutions. It will cause you issues later.
Thanks to Henrik who replied to my question and put me in the right direction. We managed to resolve this issue. Refer to this page to read the solution.
Related
Unmanaged solutions, not managed.
Let's say you deployed a Site Map previously (Client Extensions item in a solution) that had a link to entity ABC.
It was started in Dev and exported/imported all the way to Prod.
Now you want to remove it. So you remove "ABC" from the Site Map in Dev, then export/import to Prod.
PROBLEM: it didn't remove entry "ABC" in Prod despite it being removed in Dev and exported/imported that way.
Is this documented/intentional behavior? Are Client Extensions/Site Maps only additive and don't remove entries in Solutions? Where is this documented?
Are you importing/exporting unmanaged solutions?
If you're importing as unmanaged then it's likely the customizations to the sitemap are being applied over the existing unmanaged layer in the target environment, and like you said, additive only.
From a previously deployed unmanaged solution, if you remove an entity and redeploy, that entity will remain in the target system. Likely that same behaviour is applying to the site map layering.
Try exporting the site map as part of a managed solution. This might help, although I can't make any promises. We have experienced odd behaviour with sitemaps that exist in multiple managed solution layers. So depending on your configuration this may or may not be helpful.
I found the most reliable way to manage a site map is in a single managed solution that sits at the top of the solution layers.
I have a managed solution where I want to add a process/workflow with custom entities. I am able to add process in unmanaged solution for custom entities but have any way to do in managed solution or any alternative way to do so?
Please suggest me what I can do.
Managed solution is not recommended for regular development lifecycle projects, as the future schema changes will be challenging. Managed solutions are good for redistributable components like CRM REST Builder, where author want to have full control & customizations are not allowed in those components as that may break future upgrades of that particular managed solution.
Still you can go ahead & create a standalone solution with your custom entities, then add a WF for that entity. Finally you can export as managed solution to import in other environments (usually only Prod). This way you can customize anytime in lower region like Dev/QA, but Prod can have managed solution & if anything goes wrong - deleting managed solution in Prod will wipe out components + data. You can change in Dev again & a fresh exported Managed solution can be imported in Prod.
Managed solution components cannot be directly customized.
I have some questions regarding the registering/updating of 3rd party plugins that were previously loaded via a managed solution by a 3rd party.
The issue we are having is that they(3rd party) sent us a plugin update and a new plugin outside of the Managed Solution and had us register it manually though the registration tool. Then, next time we tried to import a later version of their solution, the Managed solution import failed. We eventually realized that there where duplicate rows in the pluginassembly and pluginassemblytype table that had the same Pluginassemblyid and plugintypeid respectively with different solutionids.
These solutionids were "Active" which I assume came from the manual registration and "IPM Global" which is our 3rd Party Managed Solution. The only way we were successful in getting the solution to import was to change the overwrite time
on the table(s) to 0 and then delete the "Active" pluginassembly and plugintype records.
Is there any other way to accomplish this same thing that is supported?
BTW. We did try to unregister the plugins before trying this, but there were too many dependencies in our workflows.
Wow, this is a thorny problem. Since you mention updating the tables directly, I'll assume that the system is on-prem.
Registering a plugin that exists in a managed solution outside of that managed solution is something I've never done, and while I have directly updated the plugin registration table, it is certainly something to minimize.
As unpleasant as it sounds, to get back to a good state in a supported way you may be looking at having to:
Backup the SQL database
Backup all the data from any managed solution entities.
Undo all dependencies on the managed solution (i.e. edit all the workflows so they no longer depend on the managed solution). To ease the pain of this piece you might want to experiment with exporting the affected workflows via an unmanaged solution. Then you could delete them rather than trying to weed out the dependencies. Then after you have the managed solution back in the system, you could theoretically import the unmanaged workflow solution to restore the workflow. But, admittedly this working depends on workflows finding the plugin assemblies they depend on by name rather than Id, which I'm not sure is the case - so like I said, experiment.
Unregister the "out-of-band" plugin
Uninstall the managed solution
Install a clean copy of the managed solution, INCLUDING the previously problematic plugin.
Restore/reconfigure the workflows
Restore the managed entities data
It's a lot... so much in fact that I would consider opening a Microsoft support ticket to see if they can provide any alternative methods to correct the situation.
In this situation I personally might also consider unsupported methods like using SQL to copy the tables of any managed entities before deleting the managed solution and then using SQL to copy the data back after the managed solution is fixed. Of course I (almost) never recommend using SQL in an unsupported way, so explore that option at your own risk (and with copious backups).
First, try to avoid direct DB updates in system tables whenever possible. You never know when it will hit you (next solution import, next CRM upgrade, moving to cloud, etc).
I assume that yours vendor solution contains entities and attributes and not only assemblies with SDK message processing steps. Thus you can't just simply remove that managed solution cause there will be data loss. Also I assume there are no workflow activities in their assemblies.
Ask them for solution with properly registered assemblies and SDK message processing steps. Then go into your organization with plugin registration tool (https://msdn.microsoft.com/en-us/library/gg309580.aspx) and unregister their assemblies. Then just import their latest solution. It should be able to import their assemblies with whatever is inside them.
It's good idea to restore copy of prod organization and playthrough whole process in safe environment first.
I have a few (3) core projects I want to share across many solutions (12+).
So, say I have 12 websites and they use some shared back end core code (in this case I'm not talking about shared js, css or views - I'm talking about business objects, entity stuff, etc.).
I need to be able to identify which site has which version of the shared code in dev, test, prod, etc. so a developer can get the website code and get the right version of the shared code to develop or patch the website.
And then the MS build server needs to know which version of the shared code to get for the deployment.
To solve this, I'm seeing people branch that core code - which seems absurd to do 12+ times. (I do expect to branch the core code sometimes for things like hot fixes and long running projects.)
I'm also seeing people copy DLLs of the core code and check those in.
I would think I would list the dependencies for my solutions based on TFS label names somewhere so developers can easily get the apps running with the right code and given a tfs label the build server can get the code for the website and the proper version of the core code. I'm using TFS & VS 2013 at the moment too, so there's that.
So, is there a way to do this that's straightforward, supportable/scale-able and intuitive? Thanks - Peter
Labels in TFS is very limited. For example once the label created you couldn't change and update it. If one of your core projects updated, did you need to create a new label for it. If you did and use the new label for one of your solution. However you found there are some bugs in this update, you need a newer update of your core project to fix the bug. Then a newer label created, you need to manually maintain the dependencies which seems not to be an easy job.
Moreover how to list the dependencies for your solutions based on TFS label names? TFS don't have this built-in option, seems the only way is store it in a txt or someother files and check in the source control. Every time the developer open a website application need to check it first and get label from server to their workspace and work on it.
Usually the purpose of sharing code between projects is reducing maintenance. There’s two main code sharing paths: source and binary. The difference between them you could take a look at this blog: Code Sharing in Team Foundation Server
Sharing code between products is a primary cause of quality erosion and elevated bug counts. I would recommend you to build separately and sharing binary output through NuGet which use preferable.
Also take a look below similar questions:
Sharing code between solutions in TFS
TFS 2010 Branch Across Team Projects - Best Practices
For Dynamics CRM 2011, Microsoft suggests moving entity customizations from DEV to PRD by packaging the changes as managed (or unmanaged) solutions. Unmanaged is bad because you cannot remove the entities when you need to (deleting the solution only deletes the container, entities contained in the solution remain). In most lab examples during training, you’d customize the system, then export the customized entity as a managed solution, then import it into production. This solution-based approach is clean, makes it easier to control what’s in PRD, bundle related entities together, track dependencies, etc, so I get that.
There are times, however, when you need to dump the org on the DEV server and restore from PRD (to address a data-specific issue or for other reasons). We do that by disabling, then deleting the DEV org, then asking the DBA team to restore the CRM database from production, then we import the org back to the DEV server. But if we implement this “managed solutions”-based change migration process, won’t we lose the ability to change our entities after we dump DEV and recreate it from PRD, where these solutions are sitting in read-only mode? If we enable customizations in these managed solutions, will we be able to add new entities to the solutions or remove entities from inside the solutions without deleting the entire solution? Because I thought managed solutions are treated as a single unit of code, so it’s either delete all or delete none. Interested in learning how others have resolved this issue.
One way we have handled this is using a seperate clean dev machine which we use to manage the configurations as the "configuration master". That machine is not used for any other dev or test work. The dev machines for plugsin, etc. can be rebuilt from prod, but this machine continues to be the master for all solutions. Not an ideal solution, but it does avoid the "feature gap" of being able to convert managed solutions to unmanaged (maybe through some password facility)
I would advise against using solutions in these type of dev-to-testing-to-prod situation.
If you are unsure about this try to remove an entity in your dev environment and publish the change to your production environment.
Solutions are inclusive meaning that CRM doesnt remove fields and entities that where deleted in your solution.
The only way to remove an entity is to uninstall your solution therefore deleting the production data in all entities covered by your solution!
While in theory solutions seem perfect they are only usefull for third party vendors.
The goal of beeing able to rollback by uninstalling your solution is a pipe dream. Consider a data model update that involves data conversion. No magic function will reverse that.
It is a far simpler and reliable to restore your backup.