Introducing PackageManagement in Windows 10

  • Article

In Windows 10 we are launching a new PackageManagement feature (formerly referred to as OneGet) that enables ITPros or DevOps to automate software discovery, installation, and inventory (SDII), locally or remotely, no matter what the installer technology is and where the software is located. 

So why are we implementing PackageManagement? In the Linux world, people are familiar with package managers such as Apt-Get, YUM, RPM, etc, for different Linux distros. In the Windows world, however, there are quite a few installer technologies, each having their own way to install software, such as MSI, MSU, APPX, and the list goes on and on. This creates a challenge for ITPros and DevOps and a need for a tool to automate the software deployment experience. PackageManagement is aimed at solving this problem. Let’s first have a glance at the architecture.

 

Architecture

PackageManagement is essentially a Package Management Aggregator. It creates a unified and consistent PowerShell interface for users and provides a plug-in model at the back end that different installer technologies or package managers can plug-in as providers, using PackageManagement APIs. Each provider further manages one or multiple package sources (repositories) where software packages are stored.

Regardless of the installation technology underneath, users can use these common cmdlets to install/uninstall packages, add/remove/query package repositories, which we call Package Sources, and query a system for the software installed.

 

 What’s in the box?

In the box, we will have

  • PackageManagement Core component,

  • a PowerShell module to provide cmdlets, and

  • a key set of providers. 

That’s it, all other providers can be installed on the fly. This allows for a small footprint while not losing agility to dynamically bootstrap package providers and install packages from those providers.

The key set of providers coming in the box are:

  • a Bootstrap provider (the provider that knows where to get more providers from)
  • an MSI provider for handling MSI files
  • an MSU provider for handling Microsoft update files
  • an Programs provider (Add/Remove programs) for providing inventory data of anything that registered itself with Add/Remove programs
  • PowerShellGet -- for accessing PowerShell modules.

 

Quick Start

Let’s explore what PackageManagement can offer you. A handy Get-Command is a good start.

You can see that we provide three levels of management, i.e. provider, package source, and package. The cmdlets are pretty much self-explained. We are particularly interested at the Package level operations, so let’s explore further on the SDII operations.

Discover Packages

This will look at all package sources for the provider PSModule and return all the versions matching the package name.

Install Packages

Once you find the package, you can simply specify the version without specifying a package source and PackageManagement will install that version of package from the correct package source.

Inventory

You can specify the –provider parameter at Cmdlet get-package to check what’s installed in the local machine. There is a special provider Programs included. With –IncludeWindowsInstaller option, it returns a superset of packages comparing to the Add-and-Remove Program, which only lists those ‘volunteering’ registered MSI packages.

 

Where to get it for down-level platforms

Besides Win10, PackageManagement is available for down level platforms in a few ways:

  • It is included in the Windows Management Frameworks 5.0 (WMF 5.0) Preview that supports back to Windows 7 and Windows Server 2008 R2. WMF 5.0 also contains PowerShell 5.0, DSC, and other components. 

  • For users who only want PackageManagement, we will soon release a stable version of just PackageManagement and PowerShellGet provider as a MSI package, and plan to refresh it frequently.

PackageManagement is also an open source project at https://github.com/OneGet. You can check out the latest news and code from there.