Generate nuget license summary for dotnet core










0















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).










share|improve this question


























    0















    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).










    share|improve this question
























      0












      0








      0








      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).










      share|improve this question














      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 14 '18 at 10:29









      richzillarichzilla

      13k124174




      13k124174






















          1 Answer
          1






          active

          oldest

          votes


















          1














          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.






          share|improve this answer






















            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
            );



            );













            draft saved

            draft discarded


















            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









            1














            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.






            share|improve this answer



























              1














              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.






              share|improve this answer

























                1












                1








                1







                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.






                share|improve this answer













                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.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 14 '18 at 21:54









                zivkanzivkan

                1,329917




                1,329917



























                    draft saved

                    draft discarded
















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    Top Tejano songwriter Luis Silva dead of heart attack at 64

                    政党

                    天津地下鉄3号線