We have two development teams working on seperate modules of the dynamics crm in different solutions, team A develops customizations in solution A, exports a managed Solution A, this managed solution will be imported on team B's dynamics development organization on regular basis, team B also develops customizations in unmanaged solution B and exports it as a managed solution when it will be given to customer.
When everything is ready Customer can either import only managed solution A or managed solution B on top of managed solution A.
But Both solution A and solution B includes changes to the ribbons. I am wondering how these changes are merged. Because in the above scenario team A's managed solution is imported into the development environment of team B. At this point Team B might have some unmanaged changes to the ribbon as well.
I am wondering how does dynamics CRM merges these changes. And I am wondering if there can be a case where changes in solution A can be overwritten by Solution B. Even though they are completely mutually exclusive.
From what I deduce from customizations.xml, when I import a managed solution, I don't see any ribbon changes related to that solution in the customizations.xml any more when I just export an unmanaged solution that only contains application ribbon. Which makes me think that when I import a managed solution, those changes in the managed solution are merged into the application ribbon.
Any information would be appreciated.
As far as I've researched, entity ribbon changes are shipped along entities and they are merged automatically. Global Application ribbon and custom group changes are shipped under client extensions in the solution, as far as I've researched they are also automatically merged when to managed solutions are imported one after another.
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.
We are in the process of creating and publishing a managed solution built on CRM 2016 8.1. This solution is meant to be forward-compatible with 9.x, and we plan to publish it to AppSource.
We may need to migrate our Publisher from one instance of CRM 2016 8.1 to another, and expect to be able to publish and deploy to the AppSource afterwards.
However, after much research, I can't figure out if the Publisher itself is easily migrated.
Let's say in our original instance, instance A, we have exported a managed solution and published it to AppSource.
Now we want to migrate to instance B. We import the unmanaged solution into B, make changes, increment the version number, and export a new version of the managed solution. We now try to publish this as an upgrade to our existing solution in AppSource (or by means of distributing an upgraded managed package to our clients).
Will this work? Or is there something that ties our publisher record to that instance that we need to be aware of?
Publisher information and other solution identification is maintained in the solution and transfers to your target organization. So if you apply your unmanaged solution to another org, that publisher will now exist in the target system, and you should be able to then export an update to a third system.
That being said, I wouldn't be shocked if you ran into issues carrying out this operation. There are still quite a few gotchas lurking within the solution metadata.
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.
My team currently works with an on-premises TFS 2012 server. I am migrating everything to Visual Studio Team Services, formerly Visual Studio Online. I am starting with a test project and was able to easily get all the code migrated, but can't figure out how to do the same for the work items.
Are there any good guides out there?
New options as of March 29th 2018:
TFS to VSTS migration - The official import option which will import 1 project collection into 1 VSTS account. It automatically imports everything stored in the backup. At the point of writing this, the TFS must be upgraded to TFS 2018 and some work item template customizations must be removed (there are a few well documented features unavailable on VSTS).
VSTS Sync Migrator - Marting Hinshelwood, the uncrowned king of TFS and VSTS migrations, has built his own little tool that can migrate work items from one server/account to another. It can even do migrations from one Team Project to another and while doing it switch between process templates.
VSTS Work Item Migrator - Microsoft has also open sourced a project that they used internally to migrate work items. It's less powerful, but it was made by Microsoft.
Previous answer:
At the moment there isn't a really good story. Your options are:
Start over - easiest :).
Start over and manually recreate items of value - It's a pain, but it's some teams have done these things in the past. keep the old TFS server available in read-only mode and each time you use a work item in the old system, you manually create it in the new one, set all the fields and upload the attachments. Depending on the number of items it'll take you a few sprints to migrate the most important stuff over.
Wait a while longer - Microsoft is currently working on a full fidelity import option which will allow you to upload a Project Collection and it will be exposed as a new VSTS Account (it's not going to be possible to import a project collection into an existing account).
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The trick is to extract from one Project Collection then copy all fields, except the ID to an Excel sheet bound to the target project collection. You will need to fix all Identity fields (works best when users have the exact same display name on premise as in VSTS) and you'll have to import once with state new and then past the current state/reason over the just imported values and sync again. Test Cases, Plans, Suites and Shared Steps will not be imported with their relations in tact. The approach would be very similar to this one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test cases, Shared steps and their relations will not be imported. This option will allow you to import import work items and source code with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and source control link migration you're looking at the commercial edition, which comes at a steep price. It still has a long list of known issues and last time I tried it, I ran into numerous issues which required their support to resolve them.
There are specialized TFS consultants who live off these kinds of migrations if your current state of the work items is precious to you, then you could reach out to them.
See also:
https://www.visualstudio.com/en-us/articles/adopting-vsts
I am wondering what is the Difference between Managed Solution and UnManaged Solution in CRM 5.0 (2011)?
Unmanaged solution: Essentially the same as 4.0. As soon as someone imports an unmanaged solution into an organization, it becomes an integrated part of the organization and can only be removed by manually removing all parts of the solution. The components of it can be freely edited, changed, and removed.
Managed solution: Managed solutions can be locked down by the creators to not allow or allow editing of forms, adding new forms, changing display names, etc. A managed solution can be easily removed by just deleting the solution, and all components (that aren't needed for another solution) will be removed.
Unmanned Solution**:That solution we are edit update Unmanaged solutions are groups of unmanaged customizations. Any unmanaged customized solution component can be associated with any number of unmanaged solutions.
You create a managed solution by exporting an unmanaged solution and selecting to package it as a managed solution.
Manged Solutions:A managed solution is a completed solution that is intended to be distributed and installed.we cant modify and customizations that solutions.
Also,
an UnManaged solution has no restrictions on what can be customized, and when you make changes to the system through an UnManaged solution the changes remain behind.
Managed solution all customizations are lost when it is deleted. So there is the potential for data loss in that event.