We have a large solution that we are trying to import into another one of our Dynamics 365 online environments. However, the solution is missing around 3 pages worth of required components when we try to export it. If we try to add the required components through the "Add required components" button in the solution, then we can only do it 1 record at a time. This would take a very long time to do. Is there a better way to import these required components? If not, what is recommended in this situation and what are some best practices for managing solutions in a Dev -> Test -> Prod environment scenario?
There are so many reasons why a solution might fail on import, and even more "best practices" for pushing a solution from DEV to TEST to PROD.
Firstly, always make sure that each of your environments is as close to the same as possible. What do I mean by this? Mainly, make sure the managed solutions from each environment match up. Many times, dependencies are pulled in from managed solutions due to bad solution design. WHich brings me to...
Secondly - when you are adding components (entities) to your solution, are you clicking the "add all assets" button? If so - stop doing this. There is no need to pull in 'all assets' on ANY OOB CRM entities. Of course, a custom entity, you may want to pull in all assets. But say you're pulling the Contact entity into your solution, to build a few new fields and customize a form. Instead of all assets, just bring in the shell of account (no assets selected). If you want to clone a form, and make changes, include that form ONLY, then open it and save as, and you will have it in your solution. If you "add all assets", then you're bringing in every relationship in the Contact entity, which is typically where your dependencies will go wonky. Only include those assets you truly need - and always try to avoid including OOB relationships.
In the long run, there is no 'short way' or quick way, to identify and fix your dependencies. What I typically do is take a few screenshots, and go through them 1 by 1 and resolve them. The error should tell you what artifact is causing the error, and which element requires that artifact. You have to resolve each of these, and then re-attempt the import.
If you post some screens, Ill try to help you resolve the issues.
Related
In all environments, there is a field MXM_RemoveMe we want gone from the Account "Information" Form (one of the Account's OOTB Managed Forms, but of course we've customized it on our own a lot by now)
In Dev, I remove MXM_RemoveMe from the Account "Information" Form.
I put that Form in an Unmanaged solution in Dev, export and import into QA. Publish all.
Problem: but the "MXM_RemoveMe" field is STILL on the form in QA.
What could cause this? Do we have to manually remove fields from Forms in all environments? I don't think that's the case normally.
I've verified this behavior in a specific test after the fact. If I add a field to the Account form in QA... then export/import from Dev that Form (Unmanaged) WITHOUT the field... it still stays in QA! I encourage everyone else reading this to do this simple test themselves and see the same behavior I see.
How should this be handled/understood?
I think this is because the form itself is managed. The system simply adds fields to the form on import and does not simply overwrite unmanaged changes any more. In older versions of Dynamics CRM this did not work this way though.
When you prefer to continue working with unmanaged solutions (I feel there are valid reasons to do so), a best practice would be to always copy managed forms first and modify, export and import the copy instead of it.
The copy would be in its entirety an unmanaged form. Up to now I have never seen issues with those forms when imported in target environments in an unmanaged state.
I might be wrong here but this might be changed in the modern make.powerapps.com compared to how it worked in the classic import experience. You might have the option to overwrite your customizations there(not recommended).
https://learn.microsoft.com/en-us/powerapps/maker/data-platform/update-solutions#overwrite-customizations-option
Probably the safest way is to manually go about and delete the components.
Could have to do with solution layering and using the accounts OOTB managed form. Usually, id say it is better to use a custom form
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.
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.
I'm working on a website at the moment that has three separate "area's" to it. Firstly, there's the main website, then there is a User control panel, and finally an Admin Control Panel.
At the moment, I am working with three separate solutions which is less than ideal, as I can imagine updating this in the future will become rather messy.
What I would like to do ideally, is create a solution, and then include the three separate projects within that solution. I don't have a problem doing that, what I can't seem to figure out however is the publishing side of things.
I've searched around and been unable to find a solid answer to my question, which is:
If I am using multiple projects in one solution, can each one be published to a separate FTP Server Directory? -- I would also welcome any ideas on how this could be done better.
My apologies if this question has been asked before, but during my searching I have been unable to find anything that relates to this situation.
Thanks in advance,
Dave
This is definitely possible, since publishing occurs at a project level rather than at a solution level. What I like to do is go to Tools->Customize->Keyboard... and set a custom key binding for "Build.PublishSelection". Whichever project you have highlighted in your Solution Explorer will be published when you push the key binding. You can save multiple publish configurations in the publish dialog as well.
I hope this qualifies as programming related since it involves how to structure a project.
Because I've always used the web site model with VS.net I never had solution and project files and putting everything into source control worked great. I knew that everything I had in my web site directory was all I needed for the web site.
Now I'm using asp.net MVC and it only has a project model so now I have these solution and project files. If I work on it alone it's fine but once other people start to add/delete files from the project our solution file gets messed up and people end up having to grab the latest solution file, see what got changed and then add back/remove their files and check in the solution file again. It's become sort of a problem because sometimes people don't realize the solution file was changed, they make other changes and then when they check in everything other people do an update on their files they find that their files are gone from the project (although still physically on disk).
Is this normal? Is there a way to structure a project so that we don't need to check in solution and project files?
Your developers are not using TFS correctly. You should have multiple check-outs turned on, and everyone needs to be careful to merge their changes correctly when checking in. TFS will prompt you to do this, and accepting the defaults is nearly always the right thing to do.
It's not uncommon to have one or two developers who never get it, and you might have to help them now and then. But every programmer who works on a team needs to learn how to use source control tools correctly. If they can't manage that, they shouldn't be writing software.
[edit] It occurs to me that you might run into these problems if you check in the *.sln file directly, rather than choosing to "Add Solution to Source Control".
I don't think it's normal - what are you using for source control? It sounds like developers aren't respecting changes that others a making - checking in without merging first.
I know that early on in a project, when lots of files are being added & deleted, it can be a problem to keep up - you need to check out the project file, add your files, then check in the new file & project so other developers can also update it. You'll probably have multiple project files in a solution - perhaps one interim solution would be to have one "holding" project for each developer, then clean them up periodically - though these types of temporary fixes do have a tendency to become permanent.
I don't know of a way to set up a project file that's not in source control, though I suppose you could create a script that would generate them.
Having been through this, the key is respect & good communication between the developers.
This tends to happen with TFS multiple check outs. It can be hard to grasp coming from VSS to TFS as VSS allowed one person to check a file out at one time. Auto-merge should work most of the time for you but a couple of rules should ease the pain:
Check in early and often (if you add remove or rename a file check it in straight away even if it is a blank holder)
Before you check in do a get latest, this will ask you to resolve conflicts locally
Try to get continuous integration set up so that developers always know the state of the buidl and whether it is OK to check in\out.
We had a bit fo pain at the start of our current project but it soon settled down when we followed the rules above.
Personally, I think making changes to project and solution files requires discipline and clear (well understood) rules throughout your development team. These files (.sln, .*proj) are the bottlenecks of your project, and any errors or inconsistencies can cost you in team downtime. Changes need to be well thought out, planned and then executed.
They must be secured by source control (which you're already using, excellent) and your team members should work on the basis of only making the changes they need, and not leaving project or solution files checked out for an extended period.
If you are allowing multiple (shared) checkouts, this could become problematic in terms of overwriting another user's changes. Depending on your source control mechanism, people may be required to manually merge changes. Personally, I'd ask people to negotiate their project/solution changes with each other over merging (this can't always be achieved).
A third option if you are using TFS is the shelve feature. If someone needs to make changes locally, they can shelve the changes and merge later.
Lastly, another strategy is to try to architect your solution to be as modularized as possible - so people are distributed, working on separate projects and do not (ideally) have to overlap on too many common areas.
I'm not sure if you are using TFS, as people have mentioned, but if you are (or if you are using source control with similar capabilities) you can set it such that sln and csproj files are exclusive lockouts and are not able to be merged.
We have done this with quite large teams and while it causes some initial issues as people get used to it in the long run it has resolved many issues that were previously causing problems. Essentially you trade longer term merge issues/complexity for short term compile/checkin issues which we have found to be a good trade off.
Once you have set it to forced exclusive checkout and no merge you then get your dev teams used to the fact they should keep locks on the sln and proj files for as shorter time as possible.
Always check them in.
Always check out latest (merge if possible), make sure your change is there, before checking in a new version.
If your source control doesn't require a special action to check in from an old version, GET A DIFFERENT SOURCE CONTROL.