Can you explain why piping is problematic? I don't see any good reason this would be a problem...

We want to run it as a DotNetCoreCLI@2 task in Azure DevOps Pipelines. I had no luck adding a pipe to file to that command (perhaps due to how it is executed or what OS it is being run on)

Any reason not to use https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/cmd-line-v2?view=azure-pipelines?

You could also use https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/powershell-v2?view=azure-pipelines to be platform independent...

Just to explain why I'm not too fond of adding file output to nuget-license:

• This adds a whole category of things that need to be handled. Files could be locked. The user could lack permission to access the file. The disk could fill up.
• There usually is a perfectly fine solution in general which is piping which allows the environment to take care of all those potential problems.

The TLDR is that adding file output could add quite some complexity to nuget-license which seems a little out of scope given that there is the possibility of piping....

I did try both cmd and PowerShell. I could not get it to work but that could be just me not doing it correctly.

I understand if you do not want to add file output, I will just give my "end user" reason to why I would like it. Do not take this as anything other then a suggestion (and feel free to ignore it, it is not like I am paying you or anything :)

• I came here from https://github.com/tomchavakis/nuget-license that stopped working in Net 8. I wanted to update the existing pipeline to this new project as simple as possible.
• I see this as a report creating command line tool and because of this I see the primary use would be to generate a report in a file to be stored or processed in a later stage. Viewing the information (or writing it to command line) seems to be less useful. Because of this I would think that a file output should be added.
• To me adding file output could be as simple as try to write file and if it fails (for any of the cases above) catch the exception and report error to end user. But I do not have much experience with this so it might be harder

I'll see what I can do. If you want to speed up the process of getting this feature, feel free to implement it yourself and create a Pull Request.

Definitely would like to see this too; we have to work on PS and bash and it's just going to be easier and more complete to have a -o or something to complement -i -- although to keep that common convention would require renaming -o (output type) to -ot or something...

I just opened #100. Can you please test whether this change will satisfy your needs?