-
Notifications
You must be signed in to change notification settings - Fork 189
Q and A
OneGet 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.
-
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 inbox providers in Win10 and WMF5.0 RTM. And there 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.
You can download the sample PowerShell PackageManagement provider, MyAlbum, as a baseline and add your basic logic there.
Use the template of the provider as the baseline and add your basic logic there.
See the provider list here
See the provider submission guidelines here
See the debugging tips here
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.
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.
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
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.