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.
Series: Intune
- Get your apps in Intune
- Package apps for Intune
- Publish apps to Intune
- Remove platform dependency for WingetIntune
- Analysing Win32 Content Prep Tool
- Decrypting intunewin files
- Introducing Content Prep PowerShell
- Creating IntuneWin files with C#
- Hyper-V template for 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: https://winget.azureedge.net/cache/source.msix
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.
[New Blog] @svrooij built a fantastic tool to package winget applications for Intune called winget-intune.
— Niels Kok | MVP (@NielsKok5) September 19, 2023
I used his tool to create an Azure DevOps pipeline for easily packaging Winget Packages. It only takes about 25 - 30 seconds to run the pipeline. https://t.co/4w85FjFFpJ
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.
Conclusion
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.