« Previous 1 2 3 4 Next »
Manage software apps publicly and privately
Special Delivery
Manage Your Development Toolchain
WinGet lets you install a collection of packages. To prepare a Windows environment with a specific set of software packages, use the export
command and tweak the exported definition's contents in JSON format; later, you can distribute it across any number of Windows environments for import.
Assume you have already set up a local environment with the packages listed in Table 2. Before exporting, quickly check the help text to understand the options available with this command:
winget export --help
Table 2
Developer Packages
Package/App | Short Description | WinGet Package Name |
---|---|---|
7-Zip | A free and open source file archiver | mcmilk.7zip-zstd |
VSCode | Community VSCode with no telemetry tracking | VSCodium.VSCodium.Insiders |
JDK | Microsoft's spin of the Java Development Kit | Microsoft.OpenJDK.16 |
Python | Python SDK and runtime distribution | Python.Python.3.11 |
Az CLI | Azure command-line interface | Azure-CLI |
The command returns several options, the most interesting of which are the options to name the exported file (--output
or -o
) and to output detailed logging (--verbose
and --verbose-logs
):
winget export --verbose-logs --output fullstack-dev-toolchain.json
The export
command executes quickly, so you can move to inspect the JSON file structure, which generally looks like Listing 2; it is an in-depth example of a series of package exports that represent a development toolchain. Customizing the package selection for this scenario requires a bit of editing of the JSON export. Crucial elements within this JSON structure include SourceDetails
, which dictates the sourcing of packages, and the specifications of the packages themselves.
Listing 2
JSON Package File
{ "$schema" : "https://aka.ms/winget-packages.schema.2.0.json", "CreationDate" : "2024-03-05T03:41:14.411-00:00", "Sources" : [ { "Packages" : [ { "PackageIdentifier" : "Microsoft.VisualStudio.2022.Community" }, { "PackageIdentifier" : "Microsoft.VisualStudio.2022.BuildTools" }, { "PackageIdentifier" : "mcmilk.7zip-zstd" }, { "PackageIdentifier" : "Microsoft.PowerShell.Preview" }, { "PackageIdentifier" : "Microsoft.VisualStudioCode" }, { "PackageIdentifier" : "Microsoft.OpenJDK.16" }, { "PackageIdentifier" : "Python.Python.3.12" } ], "SourceDetails" : { "Argument" : "https://cdn.winget.microsoft.com/cache", "Identifier" : "Microsoft.Winget.Source_8wekyb3d8bbwe", "Name" : "winget", "Type" : "Microsoft.PreIndexed.Package" } } ], "WinGetVersion" : "1.6.3482" }
Be aware that the export can contain installed packages beyond your interests, requiring manual effort to reduce it to the ideal package set for a particular scenario or use case. Once this step is done, employ the import
command and the option syntax below to bring in this tailored set of packages:
winget import -i fullstack-dev-toolchain.json --disable-interactivity --accept-package-agreements
The -i
option specifies the JSON file containing a list of apps to install, allowing for bulk installation. The options --disable-interactivity
and --accept-package-agreements
automate the process by skipping user prompts and agreeing to any terms, streamlining app setups without manual intervention.
Writing a Package Manifest
Microsoft employs a Git-based process for those looking to contribute a new package. Contributors develop a package manifest and submit it for approval to the Microsoft Community Package Manifest Repository. To begin, install the Windows Package Manager Manifest Creator,
winget install wingetcreate
which facilitates generating or updating manifest files for the Community repository. After installation, you can proceed to create a new package:
wingetcreate new https://github.com/krwittmer/admin-magazine-source/blob/main/exploring-winget/ficl-win-setup/4Debug/FiclSetup.msi
The new command accepts one or more URLs of HTTPS-accessible installer files and downloads and parses the executable setup program. The parsing process extracts several key data points, as shown in Listing 3 [2]. The InstallerUrl
is an open, web-accessible location from which the installer can be downloaded. The calculated hash of the installer file is maintained in the field InstallerSha256
.
Listing 3
YAML Installer File
PackageIdentifier: OSC.Ficl PackageVersion: 1.2.0 InstallerLocale: en-US InstallerType: msi ProductCode: '{116A96E1-3C5C-4147-AC63-98427DFE866B}' Installers: - Architecture: x86 InstallerUrl: https://github.com/krwittmer/ficl-win-setup/raw/main/4Debug/FiclSetup.msi InstallerSha256: 1EE67FC17B0F38EF50CD1BEEDA9E12355DC8F98B5E2FD9D4D1403BAFC0DAF6BA ManifestType: installer ManifestVersion: 1.6.0
Command-line execution of the wingetcreate
tool generates three YAML files during the creation process: (1) an installer YAML, which is the primary file containing instructions for installing the application; (2) the local YAML, which includes language-specific information; and (3) the YAML configuration file specific to the packaged OSC.Ficl application.
After creating the manifest file, you have the option to submit it to the Windows Package Manager repository, which I cover later in the article. See also the "Simple Installer Creation" box for instruction on creating an MSI installer in Visual Studio.
Simple Installer Creation
To create an MSI installer in Visual Studio, download the free Community edition and add the Microsoft Visual Studio Installer Projects extension (from the Extensions | Manage Extensions menu item). This extension simplifies creating an installer and managing the files it will distribute (e.g., executable files, DLLs, and other necessary application runtime files). The main workspace for this task is the File System area of the project, where you can easily add these files (Figure 2).
Building the installer takes place in Visual Studio's graphical user interface or with the devenv
command, which offers a command line. To build the command line, specify the path to your solution or project file and the desired build configuration:
devenv C:\Users\<windows-user>\source\repos\FiclSetup\FiclSetup.sln / Rebuild "Debug"
The result of this command is an MSI executable installer file.
Testing Your Manifest
Once your manifest file is created, you can test it locally in the same Windows environment in which you initially authored the manifest or in a different Windows host environment. A prerequisite to testing manifest files locally is to enable the LocalManifestFiles
setting,
winget settings --enable LocalManifestFiles
which requires activating administrative privileges for the CMD or Terminal session. The modification can be confirmed by reviewing current admin settings with the --info
option (which prints the LocalManifestFiles
setting to the console, among other settings) and WinGet environment properties.
Next, validate the manifest file:
winget validate --manifest .
The dot at the end instructs the validate
command to search for the previously generated YAML manifest files in the current subdirectory. If validation fails, correct the errors according to the line numbers provided in the console error text. You can then install the package while continuing to reference the package manifest locally:
winget install --manifest .
As before, specifying the dot at the end instructs the winget
command to search for YAML manifest files in the current subdirectory.
Also consider testing your manifest in Windows Sandbox with the .\Tools\SandboxTest.ps1
PowerShell script included in the winget-pkg
repository. Ensure your script path matches your manifest's location. After testing package installation, which should include launching the app post-package install, you can rollback by issuing the uninstall
command or remove
alias:
winget uninstall --id OSC.Ficl
Finalize your submission by testing the contribution process in the winget-pkgs-submission-test GitHub repository [3]. Begin by forking the repository and follow standard Git practices for adding and pushing changes. Add your manifest to the local repository under
manifests/<first letter of publisher>/<publisher>/<application>/<version>
Ensure it matches the required structure and information. Commit your changes with a descriptive message and push them to the remote test repository. Note that contributions typically require acceptance of a contributor license agreement (CLA) to verify your sharing rights, so ensure these details are met during this testing phase. For additional information, visit the CLA page for WinGet package contributions [4].
« Previous 1 2 3 4 Next »
Buy this article as PDF
(incl. VAT)