Coding Stephan

Remove platform dependency for WingetIntune

WingetIntune, my latest open-source project to publish apps to Intune, has a dependency on Windows. This post explains why and how I’m planning to remove that dependency.

Open-source winget community index

Series: Intune

Finding the latest version

To find the latest version of a package, WingetIntune uses the winget show command. This command will return the latest version of the package and several other details, by actually starting winget this has a direct dependency on that app (only available on windows obviously). If you are on a Mac or Linux machine, you’re out of luck. You’re probably not packaging apps for Intune on Mac or Linux anyway, so that’s not a big deal. It’s a big deal if you want to package the apps in the cloud, then you’ll need a full Windows install to do that.

API available for package details?

I’ve been looking for an API to get the details of a package, but I haven’t found one yet. If you know of one, please let me know. I’ve found the winget-pkgs reposiory which contains all the manifests for all the packages, but that’s not an API. I’ve also found the location of the source.msix file (20mb) , containing an sqlite database with all the details, but that’s not an API either.

Not sure if this is public knowledge but you can get it from here:

If there would be an API that would of course be the best option, but for now I’m stuck with the winget show command.

Building a package index

The is this repository and a zip disguised as an msix file containing all the manifests. Let’s see if I can make an easy available index of all the packages. If I have the exact package id and the latest version, I can pull the rest of the data from GitHub. So I only need the package ID and the latest version.

These details are available in the source.msix file, but that’s a 20mb download. So my idea was I create a script I run periodically on Github Actions that downloads the source.msix file, extracts the data I need and pushes it to a repository. This way I can keep the index up to date and have a small (292 KB) json file with exactly the data I need.

Use whichever you prefer to use in your own project.

Package update trigger

The described GitHub Action runs every 6 hours, which seems to be enough for the reason I’m using it. The added benefit is that I now know when a certain package is updated, which I might use as a trigger to kickoff some automated update process. Anyone interested in that? Let me know.

Using Azure Pipelines to package apps

Niels Kok recently published a detailed description on how to use Azure Devops to package apps for Intune. This is a great way to package apps in the cloud, but it requires a Windows agent to do so. Check out his post for more details.

Reduce the dependency on Windows

Now that I’ve build the index and the refresh script, and it actually seems to be working if I check the latest commits, I’ve been planning to remove the dependency on winget show for finding the latest version of the installer. Using the index instead of winget show will be implemented in the next release of WingetIntune, falling back upon winget show will be an optional parameter.

This improvement also shaved off a few seconds on the package command, since it no longer has to start winget to get the latest version. And this new index.json can be downloaded much faster then the mandatory source.msix file.

Last Windows dependency: IntuneWinAppUtil

The last dependency on Windows is the IntuneWinAppUtil, which is used to create the intunewin files. I’m planning to remove that dependency as well, but I’m not sure how yet. The intune content prep tool is a closed source windows application. There seems to be a reversed engineered version of it, but I’m not sure if I can use that in my project. I’ll have to look into that.


I’ll be removing one dependency on Windows in the next release of WingetIntune, and I’m planning to remove the last one as well. This will make it possible to package apps for Intune in the cloud, without the need for a Windows machine.

Keep in mind this is an open source project, so if you want to help out, please do. I’m also looking for feedback on the project. Any feedback is more then welcome.

In the future this project might be a website that does the packaging completely in the cloud, but that’s a long way off. Check out the post by Niels Kok on how to use Azure Devops right now (that still needs a Windows machine/agent).

Be sure to follow me on Twitter to get notified when I publish that post.