My Experience Moving D365FSC Development From CHE to UDE

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).

Unified Developer Experience (UDE) vs Cloud Hosted Environment (CHE)

So what are the key differences between a UDE and CHE instance?

A CHE environment:

• Is deployed via LCS
• Is a Azure hosted ‘all-in-one’ virtual machine that includes:
  • Modified version of Visual Studio with Dynamics 365 extension
  • SSMS
  • AOS
• Paid by the hour the virtual machine is on, plus any other Azure resources deployed as part of the environment

A UDE environment:

• Is deployed via PPAC
• Development occurs on your local machine
• D365FSC assets are downloaded to your local machine
• Price per environment is dictated by storage consumption in PPAC

Background Setup / Configuration

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

Connecting to Source Control

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:

• C:Users{UserId}AppDataLocalMicrosoftDynamics365{D365Version}PackagesLocalDirectory

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:

Building the Solution

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

Deploy Model to UDE Instance

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:

Conclusion

An overview of the steps required to go from CHE development to UDE are:

• Map source control to UDE instance and obtain latest code updates
  • Create environment variable for UDE PackagesLocalDirectory path (if needed)
  • Update library references for new PackagesLocalDirectorybin path (if applicable)
  • If either of the above are done, restart Visual Studio
• Build solution and perform a full database sync
• Build the model
• Deploy model to UDE instance

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/