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

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.

{
"$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.

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).

Figure 2: The user interface for developing a software installer in Microsoft Visual Studio with the Installer Projects extension.

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].