How To Install A Package In D365

Do you have Model files that you wish to bring into an environment? Or perhaps you want to better understand how x++ files are stored in Microsoft Dynamics 365 for Finance and Operations. In this article I will show you how to install a package in D365. And how the code files are stored in the environment.

Different Approaches

This article will not cover how to build a package for Dynamics 365 for Finance and Operations. But often you are provided with a package or model are are asked to deploy this code to an environment.

As part of learning how to install a package in D365, I will cover three common methods.

1. Apply a package using Life Cycle Services (LCS).
2. Install a deployable package from the command line.
3. Copy or Sync the model files into the AOSService website.

Each of these methods are useful in different situations.

The first is the most common way of deploying a package. And should be used in most situations.

The second can be useful when you need more control while the package is being deployed.

And the third is a great option when you are working with the source code and working in multiple development environments.

Building A Package

Again, I am not going to go into detail about how to build a package as part of this article. But I briefly wanted to cover the most common steps so that you have an idea of where a package comes from.

A typical life cycle for a developer follows this process.

1. First, a developer will write some code in a Cloud Hosted Development environment.
2. After completing the code, they will check in their code into source control.
3. Next, the source code will be merged into a Test branch.
4. A build server will take all of the source code and generate a Deployable Package. This zip file can be downloaded from DevOps.
5. After the build completes successfully, the package is downloaded from DevOps. And the package is uploaded to the Asset Library within LCS.

Finally, now that the package is in the Asset Library in an LCS project, we are ready to apply the package.

Apply A Package Using Life Cycle Services (LCS)

After the package is uploaded to the Asset Library in LCS, the user can apply the package. Next, the user will go to the ‘Full details’ page of the environment in LCS. Then click Maintain>Apply updates.

7. Finally, the user will select the package to apply, and click the ‘Apply’ button.

This process is typically done against a TEST environment when the package contains custom code. For the most part, in a development environment, this method is typically only done when the package contains base Microsoft updates.

Conversely, this is the only way of updating code for TEST, STAGE, and PROD environments. Because users are not able to remote into the machine itself.

Install a deployable package from the command line

In a cloud hosted development environment, a user is able to remote desktop into the machine itself. And because of this, there are a couple more options to install a package in D365.

One option is to install a deployable package from the command line.

First, remote desktop into the cloud hosted development machine. The URL, and credentials to the machine can be found on the full details page in LCS.

Download The Package

Next, open a browser, and browse to the Asset Library in LCS. Then download the deployable package to the computer.

The package will be a .zip file. Right click on the package file and select ‘Properties‘. On the General tab, if there is an ‘Unblock‘ checkbox, select it and then click ‘Apply‘. If you do not have an Unblock checkbox that is ok. You do not need to do anything.

Apply The Package

Next, go to Windows>Start, and type in cmd.

Right click on the Command Prompt application, and select ‘Run as administrator‘.

Then, change directory to get into the folder with the unzipped files. In my case I entered the following:

cd C:\AXDeployableRuntime_7.0.5934.35741_2021.5.7.283

Finally enter the following command to install the package. This process could save multiple hours to complete.

AXUpdateInstaller.exe devinstall

Ultimately, the system will deploy the files in the packages to the correct locations. As well as run scripts to update the database.

You can view the Microsoft documentation for this process here.

Copy Or Sync The Model Files

The first two methods are great for when you have a deployable package. This third option is for when you have the source code and are working in multiple development environments. Technically, it is not steps for how to install a package in D365. This process could really be called installing model files.

AOSService Website

First, before I explain further it would help to understand how the system reads the code. Microsoft Dynamics 365 for Finance and Operations runs as a website on a server.

The website can be seen by going to Windows>Start>Internet Information Services (IIS) Manager.

Expand the nodes on the left side until you see the node ‘AOSService’ under Sites. This is the website that contains all of the code.

The files that contain the code are stored on this machine. To see where, right click on this node, and select ‘Explore’.

This will take you to the folder: K:\AosService\WebRoot

Go up one folder, and then go into the ‘PackagesLocalDirectory’ folder. This folder contains all of the Models installed in the system.

When a package is installed, part of what the system does is to updates files in this directory.

In a previous article, I showed you the steps for how to create a model in D365. When you complete those steps, the system will create a folder in this directory. And any x++ code you write will be put in this folder. Along with any form, table, or other objects.

In some cases, the code will be compiled into dlls and put into a ‘bin’ folder. But in other cases, the raw x++ code will be stored in individual xml files. This is the case whenever you write the code for the model.

Copying Or Synching Code

Now that you understand that the D365 website contains files that are stored on the server, we can talk through what you can do with this knowledge.

If you are a developer working in a development environment, you can setup source control. And you can then sync down code directly into the K:\AOSService\PackagesLocalDirectory folder. See the Microsoft documentation here.

This allows developers to check in code on one environment, and then do a ‘get latest’ on another environment. Downloading new and updated files into the PackagesLocalDirectory folder allows the D365 website to see and run the latest code.

Even if you don’t have source control setup, you can manually copy files directly into this folder and that will work as well. I will soon share a GitHub of the source code used in these articles, and you can copy the model directly into your If you are a developer working in a development environment, you can setup source control. And you can then sync down code directly into the K:\AOSService\PackagesLocalDirectory folder. See the Microsoft documentation here.

However, there are some important things to know about updating code in this manner.

Add A New Model Folder Manually

When you copy an entire model folder in the PackagesLocalDirectory for the first time, you need to do a few things to ensure the newly added code will work.

1. After copying the folder into the PackagesLocalDirectory folder open Visual Studio. Then go to Extensions>Dynamics 365>Model Management>Refresh Models.
2. Next, go to Extensions>Dynamics 365>Build Models… Select the checkbox next to the name of the Model you added. Then, in the Options tab, check the checkbox next to Synchronize Database. Then click Build. This will ensure the code is compiles and the database is updates with any new tables and views that exist in the newly added Model.
3. Optionally, open Source Control Explorer by clicking View>Other Windows>Source Control Explorer. Assuming you already have source control connected to the PackagesLocalDirectory, add the folder to source control. Do this by right clicking on the parent folder in source control, and select ‘Add Items to Folder’. Then, you can check in the code.

Add Code To An Existing Folder

If you happen to already have a model folder, you can still add code to it manually. Either by copying new files into the folder, or by updating existing files in the folder. This is essentially what happens when source control pulls down new files.

Note: It is highly recommended that you use source control to update these files. But it is useful to know and understand that in the end these are just files that contain the code and information.

However, the files need to be put in the appropriate folder inside the Model folder. Each model folder has another folder by the same name inside of it. And inside of that folder, there exists a folder for each type of object in the system. Initially these folders will all be empty. But as you add objects to this model using Visual Studio, the system will create xml files in these folders.

After any code is changed, it should be compiled. This can be done by either performing a full model build, as described in the last section. Or, create a project in Visual Studio, add the objects to the project, and compile the objects.

In addition to compiling the objects, any objects that affect the database, need to be synchronized. Do this by checking the ‘Synchronize database’ option when building the model. Or, by setting the ‘Synchronize Database on Build’ property on the Project. If you don’t do this, the database will not be updated, and the system will have SQL errors at runtime.

Conclusion

In this article you learned how to install a package in D365. You learned how to apply a package using Life Cycle Services (LCS). As well as how to install a deployable package using the command line. Lastly, you learned that when dealing with the raw source code, that the code exists as xml files on the K drive of the system. And that with the help of source control, these files can be updated too.

Understanding how the code is stored behind the scenes, and how the system reads it, can help ensure that code is moved properly between different types of environments.