i.e.:

• LICENSE_URL_HERE_OR_DELETE_THIS_LINE
• example.org
• codeplex.com

provide the ability to set it from the outside

Description of the bug

In a recent project that got analyzed I saw that liz recognized both NUnit and nunit as separate packages, which is not correct, as the package names are all case-insensitive and should be treated that way by liz as well.

Steps to reproduce

1. Add NUnit to a project
2. Add nunit to a project reference with the same version
3. Run liz on project from 1.
4. Observe that NUnit and nunit are both recognized

Additional Information

No response

The current approach relies on the presence of a Unity-DI-Container which is created and used in the .Tool project

1. Creating and using the DI-Container in the .Tool project does not really make sense, it should rather be used in the .Core project (as this is the central point everyone else will be using (such as Cake, Nuke, Tool, ...)
2. The project will have a large size yes, when it's finished, but there should be no need for a DI Container. Plus, this Dependency would be leaked to the consumers, which is also not ideal

According to the stuff said above, we should consider using a factory (which is also good way of providing the functionality to consumers (our Tool, Nuke, Cake Project and other users through NuGet) with a Settings and/or Options object as input

Yeah, that Factory will be the one central fuck-up point. But you gotta have that somewhere.

If stuff gets outta hand we can consider using a "self-made" Service Provider or something, but I don't think it's going to be necessary

Description of the bug

Executing liz on a german (or any other language than english) machine leads into an Exception being thrown when liz gatheres the dependencies of a project

Steps to reproduce

1. have a non-english operating system
2. execute liz
3. observe Exception when dependencies are determined

Additional Information

This is due to the output of dotnet list package ... being in the OS language - here it's german:

This leads to issues, because the parser depends on finding strings like Resolved and Transitive Dependencies

it bugs me that the current common behavior is to not use {} for if/else/foreach and such, when only one statement is used. A change her would be nice

• Cake.Addin.Analyzer
• CakeContrib.Guidelines

Cake 3.0.0 has been released 🎉

• old project format
• most likely "just" parsing the package.info file
• warning when "include transitive" = false, because it is transitive by design
• whats with development dependencies?

Description of the feature/enhancement

When using the License-Expression when publishing a NuGet-Package, the licenseUrl will most likely point to https://licenses.nuget.org/{expression}.

Downloading the raw license-text from that page however, will result in a HTML-Web-Page being returned, which contains the raw license-text for, i.e. the MIT license. It would be nice when the raw license-text would also just contain that license text, and not the full blown HTML-Site

Additional Information

A similar site that is often used is https://choosealicense.com/, github.com, https://opensource.org/ and others

Using https://github.com/Mpdreamz/shellprogressbar broken up in:

• General Progressbar
  • GetProjects
  • Download Packages
    • project 1
    • project 2
    • ...
  • Get Package References
    • project 1
    • project 2
    • ...
  • Enrich with License-Information
    • reference 1
    • reference 2
    • ...

Some sort of ProgressManager would be needed for this - which can hold the total amount of ticks (4 - each main task) and can manage each sub-task with it's ticks (depending on the amount of projects, references, ...). The logger should not interfere with this procedure (except for showing the details and issues and messages >= Error) therefore should be disabled. But to be able to debug something, there should be a way to disable the progress-bar stuff, and display the regular logs.

because it currently is "baked-in" in the GetPackageReferencesFacade, but it'll be probably used in more occasions (i.e. downloading nuget-package information)

• dotnet-tool
  • how to install
  • how to use
  • options
  • examples
• cake-addin
  • how to install cake-script --nuget-loaddependencies!
  • how to install cake-frosting
  • how to use cake-script
  • how to use cake-frosting
  • settings
  • examples
• nuke-addin
  • how to install
  • how to use
  • settings
  • examples

Sometimes License Types might not be easily recognized. If that's the case one might need to analyze the License Text (if found), by looking for certain snippets?

Description of the bug

When determining the license-type for packages of the Accord family the resulting type is incorrect.

Expected: LGPL
Got: LGPL AND GPL

Steps to reproduce

1. create a project containing the Accord nuget package
2. extract licenses for that project
3. Observe that the license-type is determined to be LPGPL, GPL

Additional Information

Link to the license: http://accord-framework.net/license.txt

Cake 2.0.0 has been released 🎉

• new project format
• use dotnet list package (--include-transitive) and parse it's output (Documentation)
• whats with development dependencies?

To be able to show how (hopefully) good this tool works, a benchmark showcase in the README would be nice

Is there a difference between "Vanilla" Cake and Cake.Frosting?

the user should be able to filter the found projects, i think of something like:

• Concrete.Project.Name
• *.Tests
• Foo**Bar**Tests
• Is something like the above with a simple wildcard enough?
• I want to filter what projects have to be EXCLUDED
• the user should be able to provide more than one exclude (separate by comma or semicolon or something)
• Option name maybe --project-excludes?

I'd actually prefer an output by license type, like:

MIT:
- a
- b
- c

BSD-3:
- d
- f
- g
- h

Apache2.0:
- i
- j
- k
- l

marking license-types that are not allowed with an "!" or "*" or something

When getting dependencies for multiple projects it might happen that the same dependency might be used multiple times. Those occasions should be accounted for, by making dependencies unique / grouping dependencies.
This may be done by:

• Grouping by Dependency Name
• Grouping by Dependency Name, Version
• Making unique by Dependency Name, Version, Target-Framework

The user might want to add manual dependencies. Name, Version, License-Text, License-URL, License-Type should be added for this manual thing

Description of the bug

When a solution has the CPM enabled and during the analyzation some packages are not in the cache (which rarely happens) the remaining packages cannot be downloaded, because the current approach does not work when CPM is enabled

Steps to reproduce

1. Create a solution where CPM is enabled
2. Analyze using liz
3. trigger "download packages that are not in cache"
4. Observe error

Additional Information

the current download approach uses a dummy project using Version. When CPM is enabled one could use VersionOverride.
We'd have to see if we have to check if CPM is enabled for the current solution and switch the approach according or if VersionOverride can be used for everything.

And there is also an option EnableVersionOverride which can be disabled, which would break above mentioned approach too.

Description of the bug

some System.* packages are not being downloaded (using dotnet restore) and with that information for that packages cannot be gathered...

Steps to reproduce

1. Create a csproj which depends on i.e. System.Xml.XmlDocument
2. Fire up liz
3. --> no information for System.Xml.XmlDocument are gathered

Additional Information

No response

With checks for actual licenses being gathered. Can be used on the new TestingGround stuff

Need Integration Tests for:

• Liz.Core (verify return-value)
• Liz.Tool (verify console output)
• Liz.Cake
  • used in code
  • as Cake-Script (verify console output?)
  • as Cake-Frosting (verify console output?)
• Liz.Nuke (verify console output?)
  • used in code
  • as Nuke-Script (verify console output?)

Description of the feature/enhancement

... as it is being used with the ILogger interface in Microsoft.Extensions.Logging

Additional Information

No response

to be sure that everything is doing great

• License Type
• License Text

idk how this might work, i know of these locations where Licenses might be:

• NuGet-Property: PackageLicenseExpression
• NuGet-Property: PackageLicenseUrl
• LICENSE file embedded in NuGet

Description of the feature/enhancement

A WebAPI where you can upload your (project) files, which are then being processed, would be nice. So you're independent of any tool or environment.

Additional Information

A queueing approach would be needed, because analyzing files can take quite some time. Queue-Item-IDs should have uuids, so that no-one can look at the items from another person.

Sometimes licenses need to be gathered lots of times i.e. in scenarios like build pipelines.

Most of the time though, the versions don't change and the licenses don't need to be downloaded again.

So a cache would be nice, which has a key (which can be the Package + Version) and contains all the data we need (such as raw license text).

Maybe a second cache with the URL as the key would be nice too.

Maybe a Cache Version is needed, so that future version upgrades don't break anything (I.e. the next version adds a new property to the model, a cache item with a lower version than the current wouldn't have this property and so it wouldn't be valid)

Look at NCache what that library can do

The cache should be persisted to disk.

Add an option like --no-cache so that one can run the extraction without getting data from and writing data to the cache

Hello Martin,

I want to contribute to your project, but I cannot find any contribution process to follow.

Or I could help you directly on opened issues?

Dependency-Name + Version as the File-Name

maybe this can be done by using #5 ? Idk how to do this yet though, because we'd need the information which projects are actually in the solution and should be excluded... 🤔

The current implementation of Liz.Tool is not quite finished yet and needs some finishing touches, such as:

<PackAsTool>true</PackAsTool>
<ToolCommandName>build</ToolCommandName>

... and the general metadata needed for NuGet-Packages

Description of the bug

When analyzing the licenses starting from an sdk-style project, which has a project-reference on an old-style project, the packages defined in the old-style project (in the packages.config file) are not being included.

Steps to reproduce

1. create an sdk-style project
2. create an old-style project
3. reference the old-style project from the sdk-style project
4. add some packages to the old-style project
5. run liz on the sdk-style project including transitive dependencies
6. observe that the packages of the old-style project are not included

Additional Information

No response

Description of the feature/enhancement

there are probably some cases where information cannot be determined, but an URL could be extracted. For those cases a simple URL -> license-information would be helpful, to at least give the user the ability to ge the license-type for those cases

Additional Information

No response

Description of the feature/enhancement

Currently the default timeout of 100s is used. Which can lead to long waiting times when i.e. nuget.org is down and someone tries to extract licenses with packages that point towards licenses.nuget.org.

This timeout should be lowered to something like maybe 10s, or even less.

Additional Information

No response

Description of the feature/enhancement

The license Element can contain more than one license-expressions (see links below). This also needs to be supported and should also work when validating licenses:

• OR/AND/... should be considered
• when all OR-linked licenses are not allowed, fail the validation
• when one or more AND-linked licenses are not allowed, fail the validation
• when one or more OR-linked licenses are not allowed - but not all - give a warning

All given licenses should be exported and shown, given the provided settings.

Additional Information

• Microsoft Documentation regarding license-element: https://docs.microsoft.com/en-us/nuget/reference/nuspec#license
• SPDX expression syntax version 2.0: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
• What happens with multiple licenses in combination with the licenseUrl Element?

See #9 for more information

We need a neat icon for NuGet-Packages and stuff!

For whatever reason a user might want to filter some dependencies that he does not want to be considered, i think of something like

• Concrete.Dependency.Name
• Caliburn*
• Microsoft**Abstractions
• I want to filter what dependencies have to be EXCLUDED
• the user should be able to provide more than one exclude (separate by comma or semicolon or something
• Option name maybe --dependency-excludes?

The user might want to provide a mapping as well.

If the external one has the same key as one of the internal ones, the external one wins