For the front end of our application (a javascript web application), we can generate a list of all of the licenses used by our dependencies. Is there a way to do this for our server side nuget packages?
The reason this works for the front end, is that we have a node_modules directory containing a complete set of version resolved dependencies. With old style nuget (using packages.config and a packages folder) we could use a similar solution, but dotnet core projects use the global package store.
Our current direction of travel is to use the metadata from the nuget API and traverse the tree that way, but this throws up a whole list of other problems to solve (resolving partial version numbers, dealing with missing / incorrect license data).
It's actually not about .NET Core vs "old"-style csproj. SDK projects can build .NET Framework projects, so not limited to .NET Core. It's also not about SDK projects vs "old" projects, as "old" projects can use PackageReference.
So, if you have a solution with multiple packages.config files, the packages will be restored to a single packages folder, but packages.config doesn't support transitive dependencies, and it fails if the exact version requested isn't available. So it's easy to loop over each project, read the packages.config and find the exact package in the solution packages folder. The package should also exist in the global packages folder, but there are scenarios where that won't be true.
PackageReference will pull in transitive dependencies and will select different versions when there are either conflicts, or the requested version is not available. However, when restore is successful, it writes a file obj\project.assets.json, which you can read. It lists the full restore graph and the exact version of each package used. Using this information you can find the exact version of each package used in the global package folder.
My understanding is that in npm, it's common, if not required, to put the licence file in the package that gets saved on the user's machine. Unfortunately this isn't the case with nuget packages. But at least using the assets file you don't need to figure out the dependency tree or worry that your version selection logic is different to nuget's.