Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Q and A
Clone this wiki locally
What is PackageManagement (aka OneGet)?
OneGet is a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a given package type.
What are major components in OneGet?
OneGet Core – Provides the unified interface for software discovery, installation and inventory (SDII). Handles the loading and multiplexing of plugin providers and provides isolation for them. Exposes APIs for package management providers to access common features. Defines a set of APIs that host applications should implement when consuming the library.
OneGet PowerShell Module – implements a set of PowerShell cmdlets that give users access to the functionality of the OneGet Core.
Multiple providers – PowerShellGet, Programs, MSI, and MSU are "in the box" providers in Win10 and WMF5.0 RTM. And there are a number of providers contributed by the Community in the http://www.PowerShellGallery.com. Plus several c# based providers in OneGet blob such as nugetprovider. You can use find-packageprovider to find what providers out there.
Getting started with writing a OneGet provider in PowerShell
You can download the sample PowerShell PackageManagement provider, MyAlbum, as a baseline and add your basic logic there.
Getting started with writing a OneGet provider in C#.
Use the template of the provider as the baseline and add your basic logic there.
What PackageManagement providers are supported?
See the provider list here
Are there provider guidelines I can use?
How to debug my PowerShell provider?
See the debugging tips here
Why didn’t you just use the current version of Chocolatey?
The original Chocolatey project was built as a set of PowerShell functions wrapped up with batch files, and wasn’t built in such a way that could be easily or efficiently adapted to working in the OneGet plugin architecture.
Our prototype implementation of Chocolatey is written from scratch in C#, and offers much tighter integration with OneGet, than would be possible if we just wrapped the existing Chocolatey. This greater degree of integration offers performance benefits, as well as the future ability to expose the functionality via managed and native APIs, along with manageability via WMI. This also gives us the opportunity to deliver security and service improvements to Chocolatey as we proceed.
We're going to work with the Chocolatey project to have one single chocolatey plugin that meets everyone's needs : see Rob's post
[Update - January 2016] The Chocolatey provider under OneGet project is only a prototype as a proof of concept and Microsoft internal team does not maintain it. Please send your chocolatey provider request directly to the community. In this case, Rob Reynolds is developing the chocolatey provider: https://github.com/chocolatey/chocolatey-oneget.
Aren't there security concerns around using Chocolatey scripts?
The current implementations of Chocolatey has a tight, small-community built up around them, and packages are published by those involved in the community. Certainly it currently has a lot of implicit trust of the package publishers, and as such, could easily be subverted for nefarious purposes. Our goal is to work with the community to drive the design and implementation of Chocolatey and drastically improve the security and verifiability of Chocolatey packages so that consumers are protected from malware.
What's the difference between Chocolatey and OneGet?
OneGet is designed to be a package-management-manager. It will expose a plugin APIs for third-party package management systems to plug into it, as well as APIs for applications to access diverse package-management systems without having to code for each one. Chocolatey (the original) does support multiple package types (cygwin, ruby, etc), but isn't designed to support WMI, PowerShell, Native and Managed APIs.
OneGet includes a (new) prototype implementation of the Chocolatey package manager. You can install it on-demand.
OneGet is also shipping with PowerShell, which means that, it's a in-box component since Windows 10.
What's the difference between nuget-anycpu.exe, Microsoft.PackageManagement.NuGetProvider.dll and nuget.exe?
A lot of times (hopefully not too many), you will see OneGet and/or PowerShellGet asking the user for permission to download one of these files.
nuget.exe is used by PowerShellGet to publish packages.
Microsoft.PackageManagement.NuGetProvider.dll is used by OneGet and PowerShellGet to discover and install packages.
nuget-anycpu.exe is a wrapper of nuget.exe and the old NuGetProvider.
Earlier versions of OneGet and PowerShellGet only require nuget-anycpu.exe since it can discover, install and publish packages.
Newer versions of OneGet and PowerShellGet (released for Windows Server 2016 preview and after) will require Microsoft.PackageManagement.NuGetProvider.dll for discovery and installation of packages. Only the Publish-Module cmdlet of PowerShellGet will require nuget.exe.
We do not want to wrap Microsoft.PackageManagement.NuGetProvider.dll and nuget.exe together because Microsoft.PackageManagement.NuGetProvider.dll source code can also be compiled to work on Nano Server whereas nuget.exe does not work on NanoServer. In addition, we have more control over the source code of Microsoft.PackageManagement.NuGetProvider.dll and not nuget.exe
Why I do not see nuget.org listed as the default package source for NuGet provider?
When you first bootstrap and install NuGet provider, we do not assign any default NuGet repositories, including nuget.org. This is because for some enterprise cases, they may set their own NuGet web server as the default, instead of nuget.org. This is to reinforce users to explicitly choose which NuGet sites they intend to use. To use nuget.org, you can call 'register-PackageSource -provider NuGet -name nugetRepository -location http://www.nuget.org/api/v2' at the PowerShell console.
What's the difference between Register-PSRepository and Register-PackageSource?
Register-PSRepository is not a OneGet cmdlet, it is a PowerShellGet cmdlet. PowerShellGet is a OneGet provider that manages PowerShell artifacts. The Register-PSRepository actually uses the Register-PackageSource under the hood with the provider as PowerShellGet. This is why after you do a Register-PSRepository, you can see the same source registered under PowerShellGet when you run Get-PackageSource.
How do I install a package provider such as NuGet provider if I do not have Internet connection on my box?
In order to use PowerShellGet (e.g. Find-Module xjea), you need to have the NuGet provider installed on your system because PowerShellGet uses NuGet to find and download modules. Under the system without internet connection, you need to find a machine that has the internet to download the NuGet first and save it to a shared location. Here are a few steps to allow intranet computers to use OneGet:
- Download the NuGet provider using another computer that has an internet connection by using
Install-PackageProvider -Name NuGet.
- Find the NuGet provider you just installed under either
$env:ProgramFiles\PackageManagement\ProviderAssemblies\nuget or $env:LOCALAPPDATA\PackageManagement\ProviderAssemblies\nuget.
Copy the binaries to a folder or network share location that the intranet computer can access. Let’s say
Go to your machine that does not have the internet. You can use Find-PackageProvider -Source \sharedserver\NuGet to find the NuGet provider and then use InstallPackageProivder -Source \sharedserver\NuGet to install it.
The other workaround is that, you simply copy the Microsoft.PackageManagement.NuGetProvider.dll to your machine without Internet connection under
Launch PowerShell session and type Get-PackageProvider, you should see NuGet provider is listed.
Also see the "Detailed Description" section in https://technet.microsoft.com/en-us/library/mt676543.aspx.
How many ways out there to find items in PSGallery?
Find-Module usage: (a) We have added parameters like -DSCResource, -Command, -RoleCapability, -Includes to help with discovery. (b) We have -Tag / -Filter that we plan to use for cases that may arise after WS2016 RTM ships (c) DSCResources/Cmdlets/Functions/JEA RoleCapabilities can be discovered using the specific parameter as described in (a) or using Tag as shown below. (d) Here is how the usage looks like
PS C:\> find-module -DscResource xArchive Version Name Repository Description ------- ---- ---------- ----------- 18.104.22.168 xPSDesiredStateConfiguration PSGallery The xPSDesiredStateConfiguration module is a part of the Windows PowerShell Desired State Configuration (DSC) Resource Kit, which is ... PS C:\> find-module -Tag "PSDSCResource_xArchive" Version Name Repository Description ------- ---- ---------- ----------- 22.214.171.124 xPSDesiredStateConfiguration PSGallery The xPSDesiredStateConfiguration module is a part of the Windows PowerShell Desired State Configuration (DSC) Resource Kit, which is ... PS C:\> find-module -command "Get-SteroidsAST" Version Name Repository Description ------- ---- ---------- ----------- 126.96.36.199 ISESteroids PSGallery Extension for PowerShell ISE 3.0 and better PS C:\> find-module -Tag "PSCommand_Get-SteroidsAST" Version Name Repository Description ------- ---- ---------- ----------- 188.8.131.52 ISESteroids PSGallery Extension for PowerShell ISE 3.0 and better PS C:\> find-module -Includes Cmdlet | select -first 2 Version Name Repository Description ------- ---- ---------- ----------- 1.0.9 AzureRM.profile PSGallery Microsoft Azure PowerShell - Profile credential management cmdlets for Azure Resource Manager 1.1.3 Azure.Storage PSGallery Microsoft Azure PowerShell - Storage service cmdlets. Manages blobs, queues, tables and files in Microsoft Azure storage accounts PS C:\> find-module -Tag "PSIncludes_Cmdlet" | select -first 2 Version Name Repository Description ------- ---- ---------- ----------- 1.0.9 AzureRM.profile PSGallery Microsoft Azure PowerShell - Profile credential management cmdlets for Azure Resource Manager 1.1.3 Azure.Storage PSGallery Microsoft Azure PowerShell - Storage service cmdlets. Manages blobs, queues, tables and files in Microsoft Azure storage accounts PS C:\> find-module -Includes Function | select -first 2 Version Name Repository Description ------- ---- ---------- ----------- 1.7.3 Posh-SSH PSGallery Provide SSH functionality for executing commands against remote hosts. 1.5.0 AzureRM PSGallery Azure Resource Manager Module PS C:\> find-module -Tag "PSIncludes_Function" | select -first 2 Version Name Repository Description ------- ---- ---------- ----------- 1.7.3 Posh-SSH PSGallery Provide SSH functionality for executing commands against remote hosts. 1.5.0 AzureRM PSGallery Azure Resource Manager Module
What should I do if Update-Module Azure fails?
It is reported that
Update-Module Azure fails on some machines. Based on our investigation,
it is something to do with the networking connection.
Recently we updated NuGet provider so that it can reliably download packages.
You can follow the steps below to install the latest build of NuGet provider and then update the Azure module.
- Install-PackageProvider NuGet -RequiredVersion 184.108.40.206 -Force - Launch new PowerShell Console - Update-Module Azure -Verbose
How can I clean up all OneGet providers?
- close all PowerShell console
- delete everything under $env:ProgramFiles\PackageManagement\ProviderAssemblies
- delete everything under $env:LOCALAPPDATA\PackageManagement\ProviderAssemblies
- re-launch PowerShell console
Samples working with authentication
# Register a repository with authenticated feed. # Here -Credential parameter is used for validating the specified SourceLocation # $Credential value is not persisted to the PSRepositories file Register-PSRepository -Name $RepositoryName ` -SourceLocation $SourceLocation ` -Credential $Credential # Find a module from an authenticated repository Find-Module -Name ContosoModule -Credential $Credential # Save a module from an authenticated repository Save-Module -Name FabrikamModule -Credential $Credential -Path C:\MyLocalModules # Install a module from an authenticated repository Find-Module -Name ContosoModule -Credential $Credential | Install-Module -Credential $Credential Install-Module -Name FabrikamModule -Credential $Credential # Update the installed modules Update-Module -Credential $Credential # Set repository with authenticated feed for publishing the modules # Here -Credential parameter is used for validating the specified PublishLocation # $Credential value is not persisted to the PSRepositories file # For publishing to an authenticated feed, you must add the $SourceLocation as a source with the NuGe.exe. Set-PSRepository -Name $RepositoryName ` -PublishLocation $PublishLocation ` -Credential $Credential # Publish a module to the authenticated feed Publish-Module -Name FabrikamServerModule -Repository $RepositoryName -Credential $Credential -NuGetApiKey VSTS # Similar UX for authenticated feeds in script cmdlets as well # PackageManagement cmdlets Register-PackageSource -ProviderName PowerShellGet -Credential $Credential -Name $RepositoryName -Location $SourceLocation Find-Package -ProviderName powershellget -Credential $Credential -Source $RepositoryName -verbose Install-Package -ProviderName powershellget -Credential $Credential -Source $RepositoryName -verbose -name contoso
Sample usage with proxy
OneGet now takes proxy parameters: -ProxyCredential and -Proxy. Using these parameters, you can specify proxy url and proxy credential to OneGet cmdlets (by default, we use the system proxy settings). For example:
Find-Package -Source http://www.nuget.org/api/v2/ -Proxy http://www.myproxyserver.com -ProxyCredential (Get-Credential)
Here is the list of target servers to be whitelisted in the proxy server for installing the modules from www.powershellgallery.com.