Generate nuget license summary for dotnet core
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).
.net-core nuget
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
add a comment |
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).
.net-core nuget
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
add a comment |
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).
.net-core nuget
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
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).
.net-core nuget
.net-core nuget
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
asked Nov 14 '18 at 10:29
richzillarichzilla
13k124174
13k124174
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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 objproject.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.
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53298015%2fgenerate-nuget-license-summary-for-dotnet-core%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 objproject.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.
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
add a comment |
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 objproject.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.
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
add a comment |
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 objproject.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.
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
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 objproject.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.
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
answered Nov 14 '18 at 21:54
zivkanzivkan
1,329917
1,329917
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53298015%2fgenerate-nuget-license-summary-for-dotnet-core%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
