I’ve been using the Unified Developer Experience (UDE) for development / troubleshooting of D365FSC for a while now and am finally making the switch to making it the primary development platform from an ISV perspective. I wanted to share what the process looks like and how developing / creating new code differs from a Cloud Hosted Environment (CHE).
So what are the key differences between a UDE and CHE instance?
A CHE environment:
A UDE environment:
There are already some great resources created to help walk through the process of setting up and configuring your UDE instance:
Unified Developer Experience for Finance and Operations Apps – Microsoft Learn
Dynamics 365 FinOps Unified Developer Experience – PowerAzure365.com
Unified Developer Environments – Ariste.info
The first step in the process was to connect to Azure DevOps source control and map the projects to local folders. I currently still use TFS as our source control system, but if you are using Git a majority of the process below would still apply (if you are curious on setting up a D365FSC project with Git you can find information in one of my other blog posts). This led to the first question I had, where is the PackagesLocalDirectory folder for UDE instances?
This folder contains the X++ source code for all models in a D365FSC environment, on cloud hosted environments this folder is normally located on a service volume (for example, in a majority of my CHEs this exists at K:AosServicePackagesLocalDirectory):
Because our D365 solutions contain both X++ and .NET code our workspaces are set up in the following configuration:
So we need to find where this directory exists at for UDEs. After some digging I was able to find it at the following folder path:
This means the workspace paths need to be updated to point to the new path and will need to updated based on the version of D365 we are developing against:
Once I was able to successfully obtain the code from source control, the next step was to try and build the solution. This led to the next issue because I have post build events on the .NET project which utilized the built in Visual Studio macros to determine the ‘TargetDir’ and ‘ServiceDrive’, both of these existed in CHEs but the ServiceDrive did not resolve (understandably) on a UDE.
As I didn’t want to hard code the correct path into each solution, I decided my best course of action was to create a Windows environment variable with the correct path. That way when I want to update the D365 version I am building against I can change the value in one place and it will update across all of my projects:
Now I can update the post build event to correctly utilize the environment variable when building:
Note: You must restart Visual Studio after updating the post build event for the environment variable to correctly apply.
Next I needed to be sure that all D365 library references that are utilize are updated to point to the new directory of the PackagesLocalDirectory/bin folder:
Once updated, I was able to successfully build the project and perform a database sync:
Note: I had to perform a full database sync the first time for this process to work, doing a partial sync just for my project resulted in errors
One of the new actions when publishing custom code changes to a UDE is the idea of ‘deploying models to an online environment’, which basically means pushing your code changes from your local environment up to your cloud D365FSC instance.
The first thing we have to do is build our model by going to Extensions -> Dynamics 365 -> Build Models and selecting the model you want to build:
Note: If you try to publish your model without performing a model build, you will get an error like the following: ‘Aborting Deployment. Reason: Dynamics.AX.{ModelName}.dll not found’:
The model build process creates this file so it must be performed prior to publishing.
I can then go to Extensions -> Dynamics 365 -> Deploy -> Deploy Models to Online Environment:
And then select the model you want to publish:
I can then ensure the deployment was successful in the ‘FinOps Cloud Runtime’ output window:
And then validate that the model deployed within D365FSC once deployed:
An overview of the steps required to go from CHE development to UDE are:
Hopefully this guide helps show some of the issues you can potentially run into while moving from doing D365FSC development on a CHE to a UDE environment.
The post My Experience Moving D365FSC Development From CHE to UDE appeared first on Alex Meyer.
Original Post https://alexdmeyer.com/2025/07/07/my-experience-moving-d365fsc-development-from-che-to-ude/