Integration of NuGet packages from Azure DevOps Artifacts into the DynALM process

In this post a want to describe how we integrate NuGet packages from Azure DevOps Artifacts into the  Microsoft Dynamics 365 for Finance and Operations application lifecycle management process. As you may know from my previous posts I´m working for an ISV and we´re doing implementation projects based on our ISV solutions. Of course we´re also using ISV solutions from other partners, but this is not relevant for this post. The focus of this post is how we integrate our ISV solution into our implementation projects, also containing project/customer specific extensions.

Publish NuGet packages during release creation for our ISV solutions

When we´re build our ISV solutions in Azure DevOps, we´re creating/packing/pushing the binaries at the end of our build pipeline as a NuGet package to a feed in the Azure DevOps Artifacts. When we´re then creating a release out of these builds, the release pipeline promotes the version to the release view of the feed and also tags the version with the corresponding number in our Git repository. This process creates the basis for referencing/using our ISV solutions in our implementation projects.

Integrate NuGet packages into the build process

The first part of the story is the integration into the build process. For this integration we´re using a csproj-file to manage the referenced packages including the referenced version. During build we´re restoring the referenced packages directly from our (ISV) Azure DevOps account using the concept of service connections. A service connections is a mechanism to store connection and authentication details in Azure DevOps. For a service connection to a feed in the Azure DevOps Artifacts of a different account, you only have to specify the URL of the feed and a personal access token. The restore it self happens after checkout of the customer implementation project specific source code and before the actual build. After restoring the referenced packages, we´re copying over the binaries to the build directory, to use them during build and also including them into package creation. Overall the process is similar to what is used for hosted build automation.

Integrate NuGet packages into the build proces

Integrate NuGet packages into development VMs

Another part of the integration is the usage of the binaries, from the referenced packages, in a development VM. For this integration we´ve add a nuget.config and a PowerShell script to our setup. The nuget.config contains the URL of the feed to restore packages from and the personal access token for authentication. The PowerShell script executes similar steps, as we use in the build process. First we restore the NuGet packages to a temporary directory, to copy them from there to the AOS directory. After executing the PowerShell script, the restored packages are available in Visual Studio as “binaries only”.

Integrate NuGet packages into development VMs

Now I´m interested in your thoughts and questions on this integration process.

14 thoughts on “Integration of NuGet packages from Azure DevOps Artifacts into the DynALM process

    1. Yes, “real” integration of nuget packages for X++ via package management would be even better.

  1. Hi Paul.
    Very interesting reading.
    One question. With this approach, are you the updating Customers to newest version of your ISV solutions when ever a they run thier build pipeline ?

    1. Yes we´re updating the ISV solution to latest released version when we´re building the release version in our implementation project. What versions we´re including depends on the referenced version where we can choose between the following:
      – Major floating: 1.*
      – Minor floating: 1.2.*
      – Fixed version:

      So during the implementation phase we´re using major floating and moving to a more “strict” referencing after Go-Live.

      1. Hi Paul, finally got a chance to give this a try. I’m curious how you got the floating versions to work. Are you using package references?

      2. We´re using dotnet.exe restore and our packages.csproj looks like this:

      3. Seems your last reply got truncated. I gave this another go and your hints with dotnet.exe restore and that it is a C# project file gave me some ideas to try. However, no complete success yet, so if you are still willing to share the .csproj content, let me know.

        Are you using the dotnet restore also for the Microsoft Nuget packages used in the Microsoft hosted build? Or just for your ISV solution Nuget packages?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s