Adding basic nuget package download API #16443
Conversation
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
@wli3 is this along the lines of what you were thinking? Do you know if there's a API for extracting a nupkg once it's on disk? |
| var findPackageByIdResource = await source.GetResourceAsync<FindPackageByIdResource>(); | ||
| var nupkgPath = Path.Combine(_packageInstallDir, packageId, packageVersion.ToNormalizedString(), $"{packageId}.{packageVersion.ToNormalizedString()}.nupkg"); | ||
| Directory.CreateDirectory(Path.GetDirectoryName(nupkgPath)); | ||
| using (FileStream destinationStream = File.Create(nupkgPath)) |
There was a problem hiding this comment.
| using (FileStream destinationStream = File.Create(nupkgPath)) | |
| using var destinationStream = File.Create(nupkgPath); |
There was a problem hiding this comment.
Could you add an analyzer for this issue? It is not too useful to correct it one place without further enforce
|
|
@zivkan could we use this API in production? |
|
Also create an issue and link to the Epic, so that we know there are a lot of things are not done. At least add multiple feeds support (nuget.config), authentication, signing verification, proper error handling and cancelation token |
|
@wli3 I added a method to extract the package as well, if you want to take a look. |
VS setup is using it, so you wouldn't be the first. NuGet doesn't have a list of "supported public APIs" separate from "unsupported public APIs". Anyway, it is the only API we have to extract a nupkg, so we should be thoughtful that every single customer who wants to use our SDK to extract packages will be using this API. Therefore, I hope that if someone makes changes to the API that they create a backwards compatible overload, rather than breaking the API. Unfortunately this is best reassurance I can offer, but since NuGet started using the public API analyzers, other people in my team are starting to question changes to any public API, so wouldn't expect that we break it. The dotnet SDK has the advantage that NuGet inserts into it. Therefore, as long as your code fails to compile, or tests fail, we'll catch breaking APIs in NuGet early, and then can revert the changes. I can't imagine why we'd make a breaking change to |
No description provided.