Hi Mark,
Thank you for the post.
We, Microsoft, do not recommend deploying solutions in DEV unless you are planning to work with those solutions all over your systems, otherwise you might face dependencies problems like those you currently encounter.
The approach suggested by the other post will not work, and it will not work because once you have dependencies and add the required components, those will arrive with their own set of dependencies which you will need to fix before the solution deployment in your target instance.
At the moment you have the following two options:
1. Remove the dependencies one by one, they might come back as soon as you deploy a build of the Field Services, Project Services and Portals in your DEV together with some others which are right now in the roadmap for future releases of the three Apps.
The way you remove them depends on the component type from solution.xml missing dependencies section, you have the component type list below:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/solutioncomponent?view=dynamics-ce-odata-9
Within the missing dependencies section you will find something like this:
<MissingDependencies>
<MissingDependency>
<Required key="0" type="10" schemaName="abc_account_contact" displayName="abc_account_contact" parentSchemaName="account" parentDisplayName="Account" solution="Active" />
<Dependent key="1" type="2" schemaName="abc_contactid" displayName="contact_id" parentSchemaName="contact" parentDisplayName="Contact" />
</MissingDependency>
</MissingDependencies>
Type 10 means entity relationship, type 2 means field/attribute. In the example above I had created a lookup between contact and account, just as an example and you can see while I've introduced the lookup abc_contactid in my solution the relationship has been added to the required section.
In order to remove this type of dependency I will need to check the following:
a. The dependencies abc_contacid field might have, if it is on a form, I need to delete it from there, if the form is associated with an workflow, that as well might use it later on in a step, I will also need to delete the step and so on until nothing else from my solution points to the field and only then I will be able to remove the field from the solution.
The problem with this type of approach is the fact that it is very time consuming and at the end of it if you are not careful you can undo all your changes with a first party optional solution update.
2. The safest way to fix this issue and less time consuming in terms of implementation would be for you to go to all the possible target instances and install Field Service, Project Service and Portals Apps from admin.powerplatform.microsoft.com from resources section, Dynamics Apps and from there install the proper app.
I hope this helps.
Thank you for using Microsoft Dynamics 365 Communities,
Dynamics CRM Support Blog
Madalina Toma
Support Engineer
Microsoft Dynamics 365