Azure Devops Artifacts: how to deploy tools for internal usage

Question

Recently, I've been developing .NET Core applications (simple console apps) that my team uses for other parts of our solution.

Currently, I maintain a wiki where I share the latest version of the app, which is then integrated into our pipeline. However, a significant issue with this approach is the lack of versioning. Whenever I create a new version, I must manually update the wiki by copying the link.

I've considered utilizing Azure Artifacts with an internal NuGet feed. However, I understand that Azure Artifacts primarily supports publishing DLLs for referencing, rather than executable files for direct download.

Do you have any suggestions for establishing a centralized location where I can publish versioned executables for my team to download and use?

Thanks.

Answer 1

Universal Packages is our recommended general solution for distributing tools and such. It's not specialized to any particular type of content. Since you're using .NET Core/.NET 5+, also check out .NET Tools.

Answer 2

As @Jonathan Myers has suggested, you can publish the executable files of the console apps as the Universal Packages into a private Azure Artifacts feed for your team.

To publish a Universal Package, you can configure the pipeline like as below:

1. At first, use the build task (such as DotNetCoreCLI, VSBuild or MSBuild) to build the console app to generate the executable file.

2. Then use the CopyFiles task to copy the generated executable file into a specified directory (such as $(Build.BinariesDirectory) or $(Build.ArtifactStagingDirectory)). If some other files required by the executable file, copy them together.

3. Finally, use the UniversalPackages task to publish the files as a Universal Package from the directory into the specified Azure Artifacts feed.

For more details, you also can reference the documentation "Universal Packages in Azure Pipelines".

---

EDIT:

When you publish a Universal Package, you need to pay attention to the following things:

1. The package name cannot contain uppercase, it must be lowercase, start and end with letters or numbers, and contain only letters, numbers, and nonconsecutive dashes, underscores, and periods.

   

2. When specifying the path that contains the files to publish, ensure you have specified correct relative path or absolute path. The relative path should be relative to the current working directory. For example.

   File path: D:\a\1\s\pkgDir\mytool.exe
   Working directory: D:\a\1\s
   Relative path: pkgDir\mytool.exe
   Absolute path: D:\a\1\s\pkgDir\mytool.exe
   

---