NuGet.Core for version 3?

[ferventcoder]

When I'm looking for upgrading to nuget core v3+, am I supposed to be looking at https://www.nuget.org/packages/NuGet.Client ?

Or is it https://www.nuget.org/packages/NuGet.Protocol.Core.v3 ?

Alternatively, how much of v3 bits are in 2.10.1? https://www.nuget.org/packages/NuGet.Core/2.10.1 (I saw a little bit of compatibility bits in there on my initial diffing).

[yishaigalatzer]

it depends what you are looking into. NuGet 3 is a set of packages, you can start with nuget.packagemanagement the protocol packages.

None of the V3 bits are in 2.10.1 or 2.11 nuget.core, there are some vestigial dependencies on nuget.core (mostly for packing and some OPC v2 code paths) which we plan to remove completely in the coming versions

[ferventcoder]

Used as a library, that's what I'm looking at. NuGet.Core provided IPackage, PackageManager, etc. Since it is not clear anywhere here what the migration strategy is, you may want to leave this issue open until you have documentation in place that explains this.

[ferventcoder]

Related to #1839, I am looking to upgrade to a version of the library, or libraries, that handles Highest Dependency Version resolution worth a darn.

[ferventcoder]

I recommend leaving this open as a documentation task.

[ferventcoder]

Alternatively if you already have migration documentation somewhere, I'd love to know where that is, even if it is just a blog post somewhere.

cc @xavierdecoster @maartenba

[ferventcoder]

I'd also recommend a Gitter room if you don't already have one for questions like these. I would have preferred not creating an issue for a question but I don't see another avenue.

[ferventcoder]

Is NuGet.PackageManagement the package I'm looking for? Update: this doesn't look correct.

[daveaglick]

+1 for Gitter room - a place for ad-hoc support (including community-driven help) would probably help keep GitHub issues cleaner.

[daveaglick]

(Not that I didn't think this question was valuable - information like this about the internals is hard to come by right now, so I think it was very helpful, at least to me)

[ferventcoder]

I'm also curious if NuGet v3 takes into account the dependency requirements of already installed packages because I don't see NuGet v2.8.x (at least for 2.8.2) taking already installed packages into account when resolving new packages. The dependency resolver and walker only take into account the context of what is being installed. I have repros for this I can share.

[ferventcoder]

It looks like most of the code I'm looking for may be in https://github.com/NuGet/NuGet.Client.

[yishaigalatzer]

The question is what are you guys trying to do with the libraries. Things are broken down to a set of libraries instead of one monolithic libraries, however we are not planning building docs for them just yet. They are more of an implementation detail of the nuget clients and once they stabilize we could go there.

In the meantime ask specific questions here or on so.

[ferventcoder]

@yishaigalatzer I'm trying to move from using NuGet.Core to whatever there is in NuGet v3. This is for Chocolatey (choco.exe), which implements as a client tool using the NuGet packaging infrastructure with specific hooks for different functionality. I'm not really sure where I should be hooking in for

• IPackage / ZipPackage replacements
• IPackageManager replacement
• etc

If there was some documentation out there that would ease the transition going from v2 to v3, that would be most beneficial. You also have end users that use NuGet as a framework and right now we have no way of knowing how to move to v3 without figuring it all out ourselves. Granted there likely wasn't much in the way of documentation in using NuGet.Core in the first place, but at least it was all in one dll/package so one could explore until they figured it out.

[ferventcoder]

So specifically - it looks like I should be looking at all of the libraries related to https://www.nuget.org/packages/NuGet.Client/3.3.0 and then also the ones in https://www.nuget.org/packages/NuGet.Protocol.Core.v3 to get to the same functionality as I could see before with the monolithic package:

• NuGet.Versioning (client)
• NuGet.Packaging (client/protocol)
• NuGet.Repositories (client)
• NuGet.RuntimeModel (client)
• NuGet.ContentModel (client)
• NuGet.Logging (protocol)
• NuGet.Protocol.Core.Types (protocol)
• Newtonsoft.Json (protocol)

Do you see any of these packages as unnecessary coming from protocol only? I'm also noticing that it is 4.5 only. No plans to support v4.0 at all I take it?

[yishaigalatzer]

@ferventcoder no plans to support 4.0 with these packages, we heavily use async for example, and do not want to depend on the patch packages.

We do however build these packages to run on coreCLR (so they can be used in the .NET CLI) and regardless of what is installed on the machine, this will take a little more while before it is ready.

The packae list looks reasonable, but if you can tell me what actions you are trying to do me (or @emgarten) might be able to help with picking the right package/API. In general you can always use the client code in nuget.commandline project as a reference.

[ferventcoder]

@yishaigalatzer thanks, that's where I will go. :)

[emgarten]

@ferventcoder take a look at NuGet.PackageManagement and NuGet.Protocol.VisualStudio, they are the two high level packages that align with what NuGet.Core has. NuGet.Client sounds like the high level API, but it's actually a low level package.

[ferventcoder]

@emgarten I'll take another look. I definitely do not want anything related to VisualStudio.

[ferventcoder]

Also I asked this earlier but perhaps one of you ( @yishaigalatzer @emgarten ) can answer this question:
Does NuGet v3 takes into account the dependency requirements of already installed packages? Or does it continue to only account for dependencies based on the current operation like NuGet v2 does? Details at chocolatey/choco#116 - This is a really big problem for us.

[emgarten]

NuGet.exe install doesn't look at packages already in the folder, is that what you mean? When using a packages.config file the constraints from all packages are used.

[ferventcoder]

@emgarten NuGet the framework, not NuGet.exe. Does the NuGet framework look at packages already in the folder? Or maybe from the perspective of Visual Studio, does it handle that situation?

[ferventcoder]

@emgarten we don't use NuGet.exe in Chocolatey.

[ferventcoder]

I think I hear you possibly stating that in Visual Studio, it looks at both the request and the current packages.config file?

[emgarten]

That's correct. If you are calling the API directly to install a package then just make sure to provide the already installed packages.

With v3 I would expect that you would be creating a chocolately project similar to FolderNuGetProject and returning the already installed projects through GetInstalledPackagesAsync. This project would then be passed into NuGetPackageManager.InstallPackageAsync

[ferventcoder]

Thanks @emgarten for the information! I will follow up on these once I get into the code.

[ferventcoder]

That's correct. If you are calling the API directly to install a package then just make sure to provide the already installed packages.

No chance this works in NuGet.Core somewhere does it? I didn't see a place to provide this when calling the PackageManager operations.

[emgarten]

It works in NuGet.Core v2. See: https://github.com/NuGet/NuGet2/blob/dev/src/VisualStudio/VSPackageManager.cs#L113

You will want to create an IPackageConstraintProvider to provide requirements from the already installed packages, and then set that property on the PackageManager.

[ferventcoder]

@emgarten Thank you! I would have thought that both the command line and visual studio would have followed a similar path, so that is a different frustration altogether. Good to know that NuGet has maybe no issues if you use the proper path.

[deansher]

I am interested in building a NuGet Gallery client that reads metadata on the entire set of public NuGet packages and provides an alternative public search engine for it. My goal is to use reference-graph analysis akin to page-rank to make it easier to find the "best" open-source package for particular functionality.

My understanding so far (including from reading this thread) is that I should read code in the various NuGet github repos -- probably starting with the NuGet/NuGet.Client repo -- to figure out which not-yet-documented APIs I can reuse. I realize that for now I could use the NuGet v2 protocol instead and have an easier time finding documentation and other resources, but I would rather focus on the long term.

I would be delighted to have anyone correct my misunderstanding and provide any more specific guidance.

[daveaglick]

@deansher There were some great tips on how to do this sort of thing from @maartenba here: NuGet/NuGetGallery#2810 (comment)

[deansher]

Bingo -- thank you, @daveaglick . That's exactly what I needed.

[yishaigalatzer]

Hey folks, are we good to close this issue?

[ferventcoder]

@yishaigalatzer Depends, I think I was hoping for some transition documentation as mentioned in #1870 (comment) - if that is now available I think this is good to close.

[yishaigalatzer]

Fair enough, the docs won't happen for a while so lets do the following.

I've file a bug - #2243 to track the docs requirement, and suggest we close this guy.

[joelharkes]

Im missing the NuGet.PackageManagement package for NET standard library.

could you please build one?

[yishaigalatzer]

Will push libraries soon. You can find b in the nuget build feed on myget

[joelharkes]

Which feed URL is this? aspnetcore-ci-dev?

(Got that from here: https://github.com/aspnet/Home/wiki/NuGet-feeds )

[kendoka]

@yishaigalatzer could you be more specific on myget url? Any idea aprox when official release could be made?