Introduction

In the previous parts of the series, we created our UDE environment, installed the required tools, configured Visual Studio, and completed our first X++ development.

Up to this point, we have focused mostly on getting the development environment up and running. In a real project, however, writing the code is only one part of the job. How the code will be shared within the team, which change was made by whom, how to return to an older version when necessary, and which source the build process will use are at least as important as development itself.

This is exactly where Git and the Azure DevOps Repository structure come into play.

Using Git is also particularly important on the UDE side. This is because custom metadata now resides on our local machine, and multiple developers can connect to the same UDE environment. Therefore, the source code needs to be kept in a single, traceable reference.

In this article, we will mainly look at the following topics:

• Where custom metadata should be stored within the repository
• How the repository folder structure can be designed
• The approach to metadata, Visual Studio projects, build files, and .gitignore
• Branch structure options based on the size of the project
• The Pull Request, branch policy, and hotfix approach
• A developer’s daily Git workflow and metadata conflicts

The Metadata Approach That Changes with UDE

In classic Dynamics 365 Finance & Operations development VMs, Microsoft standard metadata and the custom metadata we developed were stored under the same PackagesLocalDirectory structure.

For example, the folder we had been accustomed to seeing for years was:

Inside this folder, Microsoft packages, ISV solutions, and our custom models could exist side by side.

With UDE, this distinction becomes much clearer.

In the metadata configuration in Visual Studio, we define two separate locations:

1. Folder for your own custom metadata
2. Folders for reference metadata

The first field points to the folder containing the X++ models we develop ourselves, while the second field points to Microsoft standard metadata and, if applicable, other reference models.

In my opinion, this separation is one of the most useful aspects of UDE.

In practice, it provides us with the following advantages:

• Microsoft standard metadata does not become part of the repository.
• We can limit the repository to only our custom code and project files.
• Switching branches and synchronizing code becomes cleaner.
• Microsoft updates and custom code are separated from each other more clearly.
• Which files the build pipeline will use becomes more controlled.

The basic rule I use here is:

Recommended Local Folder Structure

In the previous parts, we used the following folder for custom metadata:

Read more

Introduction

In the previous article of the series, we connected Visual Studio 2022 to the developer-enabled UDE environment we created on Power Platform. We covered the distinction between the Environment URL and the Finance and Operations URL, the Connect to Dataverse step, the Finance & Operations assets download process, the metadata configuration check, and how to verify that Application Explorer opens correctly.

In this article, we are now taking one step further. In a UDE environment where the connection has been completed, we will create a new model, position this model in the correct package structure, open an Operations Project in Visual Studio, and do our first simple X++ development.

For developers coming from the classic development VM model, there are both familiar and different points here. Model, package, project, Application Explorer, and build concepts are familiar. However, because the development tier and the execution tier are separated with UDE, some habits need to be reconsidered. Code and metadata are prepared on the local computer; execution, deploy, and test take place on the Finance & Operations runtime in the cloud.

Understanding this distinction correctly is one of the basic requirements for healthy development on UDE. Because creating and building an X++ object on the local computer does not mean that it will automatically run in the cloud runtime. To run and test it, the related model must be deployed to the online UDE environment. In this article, I will focus on the model, project, and first build side; I will cover the deploy and debug side with a short introduction and connect it to the next article.

Read more

Connecting Visual Studio to a UDE Environment on Power Platform

Installing Visual Studio 2022 and Preparing the Development Tools

In the previous article of the series, we covered how to create a developer-enabled UDE environment by using the Power Platform Admin Center interface.

Proceeding through the interface is especially useful in the first trials. Seeing which option is on which screen, how Dynamics 365 apps are enabled, where Platform Tools and Provisioning App are installed from, and where the Developer Tools option appears makes the process easier to understand.

However, in real life, especially for partners, ISVs, or teams managing multiple environments, doing these operations from the interface every time is not a very sustainable method. The environment creation process needs to be standard, repeatable, and documentable.

In this article, we will look at how we can do the same work with PowerShell.

Why PowerShell?

The most important advantage of creating a UDE environment with PowerShell is that it standardizes the process.

When creating an environment from the interface, many selections are made manually. Settings such as template selection, region, demo data, developer tools, language, and currency are determined by the user each time. Naturally, this increases the possibility of errors.

On the PowerShell side, we include these decisions in the script. This way, the same script can be reused for different tenants, projects, or trial environments with small changes.

Read more