- The first instinct is to directly map the folder where all the models are (on the D365FO development VMs, C:AOSServicePackagesLocalDirectory): so that it includes our models:
- But if we do this, the following happens:
- By promoting these changes:
Turns out we have ALL the models of the standard stuffed into our version control system. With this, we run two important risks:- Given Microsoft's policy for D365FO, the objects of the standard can be modified. If we keep them in our DevOps, we will simply override those changes.
- And most importantly: WE RUN A HIGH RISK OF DOING “OVERLAYERING”. Since version 8.0 of D365FO, overlayering is strictly prohibited. Doing this type of mapping is a guarantee of outdating in previous versions, and disaster from this included version.
- So, if for some reason we do it, we must immediately undo it:
-
- Undo all changes under the metadata folder:
- Undo all changes under the metadata folder:
- Undo the mapping to the VM metadata folder, returning to the Workspaces form, right-clicking on the line we want to delete, «Delete», and then «OK»:
- And map each of our models (See INITIAL UPLOAD OF A D365FO MODEL TO DEVOPS)
-
JM stew