Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enumerating package folders for .Net Core project #11773

Open
paveliak opened this issue May 26, 2020 · 7 comments
Open

Enumerating package folders for .Net Core project #11773

paveliak opened this issue May 26, 2020 · 7 comments
Milestone

Comments

@paveliak
Copy link

Hi

I need to enumerate all package folders for a project basing on the project.assets.json file. The purpose is to extract licensing information about all project dependencies.

I couldn't find schema definition for that file but looking at the typical contents there seems to be two options. Could you help me understanding which of them is the preferred one:

  • Use project->restore->packagesPath property and combine it with project->restore->fallbackFolder
"project": {
      "packagesPath": "/Users/someuser/.nuget/packages/",
      "projectStyle": "PackageReference",
      "fallbackFolders": [
        "/Users/someuser/MyProject/.dotnet/sdk/NuGetFallbackFolder"
      ],
  • Use packageFolders property
"packageFolders": {
    "/Users/someuser/.nuget/packages/": {},
    "/Users/soimuser/MyProject/.dotnet/sdk/NuGetFallbackFolder": {}
  },

Thank you,
Pavel

@zarenner
Copy link

zarenner commented Jun 1, 2020

@nkolev92 any chance you're able to answer this?

@nkolev92
Copy link
Contributor

nkolev92 commented Jun 1, 2020

The NuGet.g.props defines these in an MSBuild property, NuGetPackageFolders.

For example looking in my NuGet.Client projects nuget.g.props, I see:

    <NuGetPackageFolders Condition=" '$(NuGetPackageFolders)' == '' ">C:\Users\nikolev\.nuget\packages\;C:\Program Files\dotnet\sdk\NuGetFallbackFolder</NuGetPackageFolders>

Does that help/answer the question?

@zarenner
Copy link

zarenner commented Jun 2, 2020

@nkolev92 Not quite - in our scenario, we're only able to parse the project.assets.json (we cannot parse MSBuild). To locate a package on disk, we're trying to determine if it's more appropriate to search:

  1. In order, the folders specified by packageFolders
    or
  2. In order, the folders specified by both project->packagesPath and project->fallbackFolders

For example, a potential answer might be "you shouldn't use packageFolders since it's an object and the keys aren't guaranteed to be ordered", or alternatively "using only packagesPath+fallbackFolders will miss X that packageFolders would have". Or perhaps they're equivalent and doesn't matter which we use - we haven't seen a case where they differ, hence the question.

In short, which does NuGet itself actually use to resolve the package location?

@nkolev92
Copy link
Contributor

nkolev92 commented Jun 2, 2020

I think you need to do the 1st one.
I think that's what the SDK does. Basically the SDK uses:

_packageResolver = NuGetPackageResolver.CreateResolver(_lockFile);

which in turn uses https://github.com/dotnet/sdk/blob/8288f55cf35fb642bf2838bd11b6e17d884f019f/src/Tasks/Microsoft.NET.Build.Tasks/NuGetPackageResolver.cs.

The priority order that matter is global packages folder, then fallback folders.

@nkolev92
Copy link
Contributor

nkolev92 commented Jun 2, 2020

How are you reading the assets file btw?

@paveliak
Copy link
Author

paveliak commented Jun 2, 2020

Thank you @nkolev92. We use standard Ruby JSON parser to read it after restoring the projects with dotnet restore.

@dsplaisted
Copy link
Member

If you were to look at the package folders on disk, you would typically be looking at all the packages that had been restored for all projects on that machine, rather than just the packages that the current project is using.

@dsplaisted dsplaisted removed the untriaged Request triage from a team member label Jun 3, 2020
@dsplaisted dsplaisted removed their assignment Jun 3, 2020
@dsplaisted dsplaisted added this to the Discussion milestone Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants