nukeeperdotnet / nukeeper Goto Github PK

Failing project: https://github.com/tathamoddie/System.IO.Abstractions

Exception:

   at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at NuKeeper.Inspection.NuGetApi.BulkPackageLookup.ProcessLookupResult(PackageLookupResult packageLookup, Dictionary`2 result) in C:\Code\NuKeeper\NuKeeper.Inspection\NuGetApi\BulkPackageLookup.cs:line 56
   at NuKeeper.Inspection.NuGetApi.BulkPackageLookup.FindVersionUpdates(IEnumerable`1 packages, NuGetSources sources, VersionChange allowedChange) in C:\Code\NuKeeper\NuKeeper.Inspection\NuGetApi\BulkPackageLookup.cs:line 42
   at NuKeeper.Inspection.NuGetApi.PackageUpdatesLookup.FindUpdatesForPackages(IReadOnlyCollection`1 packages, NuGetSources sources, VersionChange allowedChange) in C:\Code\NuKeeper\NuKeeper.Inspection\NuGetApi\PackageUpdatesLookup.cs:line 27
   at NuKeeper.Inspection.UpdateFinder.FindPackageUpdateSets(IFolder workingFolder, NuGetSources sources, VersionChange allowedChange) in C:\Code\NuKeeper\NuKeeper.Inspection\UpdateFinder.cs:line 40
   at NuKeeper.Local.LocalEngine.GetSortedUpdates(IFolder folder, NuGetSources sources, VersionChange allowedChange) in C:\Code\NuKeeper\NuKeeper\Local\LocalEngine.cs:line 64
   at NuKeeper.Local.LocalEngine.Run(SettingsContainer settings) in C:\Code\NuKeeper\NuKeeper\Local\LocalEngine.cs:line 45
   at NuKeeper.Program.Main(String[] args) in C:\Code\NuKeeper\NuKeeper\Program.cs:line 28
   at NuKeeper.Program.<Main>(String[] args)```

Feature request:
A mode where it doesn't do major version updates, only minor and patch. On the internal feed especially, major version updates are best not automated, but patches are always useful.

A Feature request:

We have an internal component, call it Acme.Widgets. We have just fixed bugs in it, and released a new version, 4.5.6. We want to scan all repos in the internal github and identify those that use Acme.Widgets at a lower version and update them to version 4.5.6. This will help us make our production system reliable quickly.

Notes:

• When 4.5.6 is the latest 4.x version and all consumers are using a version 4.x, this is the same as #126 to apply minor updates. However neither of those constraints is guaranteed.

• If some code is using Acme.Widgets version 1.0 which has breaking changes to 4.0, the code may not compile or work correctly after the update to 4.0. Fixing up the code that breaks is definitely out of scope for NuKeeper. The Nukeeper model is to make a PR, and then a build and tests and human inspection should tell you if the PR is good or not.

ABRs etc

The most common issue that I see inside the business with NuKeeper Prs is that an Assembly Binding Redirect is made incorrect by the update.

e.g. the config file contains:

      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" ... />
        <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
      </dependentAssembly>

And Newtonsoft.Json is updated to v 11. Afterwards the code will compile, tests will pass, and after merge the code is deployed to test server, wherupon it fails totally - it won't even start, since it insists on Newtonsoft.Json v10.0.0 being present and it is not, Newtonsoft.Json V11.0.0 is present instead.

Fixing this is painstaking and automatable.

When applying an update of package Foo from V1 to V2, find all config files, find in them all Assembly Binding Redirects of Foo to Foo V1, and change it to be a binding redirect to Foo V2, since we know that after this change Foo V1 will not be present, and Foo V2 will.

Do not add or remove Binding Redirects, as this may not be necessary, just update them in place.

This should be enabled by command-line option.

Should also apply to config templates, since neglecting these is another common source of error that can be automated away.

A similar thing should be done to declared dependencies in .nuspec files.

1. Only take updates that have been around for a while.

In order to be cautious and not live on the bleeding edge, it is often useful to ignore an updated package for a while after it has been published- basically there is "infant mortality" when serious flaws can be discovered in a new package, and it is either withdrawn or replaced by a new version. So critical systems will want to ignore updates that have not been around for a specified period of time, and let a non-critical system trial it instead.

2. Scoring by age

This age information can also be useful for scorecarding reports - e.g. no penalty for not having taken a package update that has existed for 3 hours, but a penalty for not taking a patch that has existed for months.

For internal reporting, we would like to add number and degree of package updates available to some of our internal code scorecards. NuKeeper generates this info in detail, and then selects some updates to perform, and discards the info about the rest.

I would not like to integrate these systems closely, but NuKeeper could optionally emit this data as a report (maybe CSV) listing all the potential updates with package name, current and available versions, number of affected projects etc.

The scorecard software can parse this and generate a score from it, based in it's own weighting of criteria such as number of potential package updates, number of major version updates etc.

We have an internal project wherein a package has version 1.0.0*. This can't be parsed and the whole run stops dead. On a failure like this, nukeeper should warn, ignore the line and carry on

Error is:

'1.0.0*' is not a valid version string.
Parameter name: value

Thanks for the tool.

Are there any plans to be able to update a local project/solution instead of just inspect it? We don't use Github for our repositories, we use an on premise TFS git repo. It would be nice to be able to just update the local project and then push that myself.

I get this output from an unattended job intended to self-update

dotnet update package SimpleInjector in path /tmp/NuKeeper/15c39f8d83d149e8bc52eddfe3870764/NuKeeper NuKeeper/NuKeeper.csproj
Update failed Exception : Exit code: 1

MSBUILD : error MSB1009: Project file does not exist.
Switch: NuKeeper/NuKeeper.csproj

so it looks like

• it' using the temp folder /tmp/NuKeeper/15c39f8d83d149e8bc52eddfe3870764/
• it's trying to update ./NuKeeper/NuKeeper.csproj but
• there's an extra NuKeeper in the middle when these paths are joined? or maybe a missing ./

I want the option to use a more conventional Pull-request model across 2 github users.

e.g. I point Nukeeper at https://github.com/NuKeeperDotNet/JustEat.StatsD and it forks it to https://github.com/NuKeeperBot/JustEat.StatsD (if this fork does not already exist).

We can call these upstream and workarea respectively. It should then pull from upstream, make changes and push a new branch to workarea, and PR that branch back to upstream .

This is the workflow that we are used to. It has the advantage that you don't need to be able to push to upstream as no new branches are created there.

Oddly unable to update my two project razor solution (Test->Website). I'm getting an odd MSBUILD error which usually means there's a path/trailing slash issue?

111→ C:\github\hanselminutes-core\hanselminutes.core [main ≡ +1 ~0 -0 !]> nukeeper mode=update dir="c:/github/hanselmin
utes-core/hanselminutes.core/"
Using 'update' for 'mode'
Using 'https://api.github.com' for 'github_api_endpoint'
Using '3' for 'max_pull_requests_per_repository'
Using '10' for 'max_repositories_changed'
Using 'Info' for 'log_level'
Using 'Major' for 'allowed_version_change'
Using '7d' for 'min_package_age'
Using 'PreferFork' for 'fork_mode'
Using 'Off' for 'report_mode'
Using 'nukeeper' for 'github_labels'
Using 'c:/github/hanselminutes-core/hanselminutes.core/' for 'dir'
Running NuKeeper in update mode
Found 8 packages in use, 8 distinct, in 1 projects.
BuildBundlerMinifier, LazyCache, LazyCache.AspNetCore, Markdig, Microsoft.ApplicationInsights.AspNetCore, Microsoft.AspNetCore.App, Microsoft.Extensions.Http.Polly, Microsoft.NET.Test.Sdk
Found 6 possible updates
BuildBundlerMinifier from 2.7.385 to 2.8.391 in hanselminutes-core.csproj
Markdig from 0.15.0 to 0.15.1 in hanselminutes-core.csproj
Microsoft.ApplicationInsights.AspNetCore from 2.3.0-beta2 to 2.3.0 in hanselminutes-core.csproj
Microsoft.NET.Test.Sdk from 15.7.0 to 15.7.2 in hanselminutes-core.csproj
Microsoft.Extensions.Http.Polly from 2.1.0 to 2.1.1 in hanselminutes-core.csproj
Microsoft.AspNetCore.App from 2.1.0 to 2.1.2 in hanselminutes-core.csproj

Selection of package updates: 6 candiates, filtered to 4, capped at 3
Updating Microsoft.ApplicationInsights.AspNetCore to 2.3.0 from 2.3.0-beta2 in 1 place since 2 months ago.

Unhandled Exception: System.Exception: Exit code: 1

MSBUILD : error MSB1008: Only one project can be specified.
Switch: Files

For switch syntax, type "MSBuild /help"



   at NuKeeper.Update.ProcessRunner.ExternalProcess.Run(String workingDirectory, String command, String arguments, Boolean ensureSuccess) in C:\Code\NuKeeper\NuKeeper.Update\ProcessRunner\ExternalProcess.cs:line 46
   at NuKeeper.Update.Process.DotNetUpdatePackageCommand.Invoke(PackageInProject currentPackage, NuGetVersion newVersion, PackageSource packageSource, NuGetSources allSources) in C:\Code\NuKeeper\NuKeeper.Update\Process\DotNetUpdatePackageCommand.cs:line 34
   at NuKeeper.Update.UpdateRunner.Update(PackageUpdateSet updateSet, NuGetSources sources) in C:\Code\NuKeeper\NuKeeper.Update\UpdateRunner.cs:line 27
   at NuKeeper.Local.LocalUpdater.ApplyAnUpdate(IReadOnlyCollection`1 updates, NuGetSources sources) in C:\Code\NuKeeper\NuKeeper\Local\LocalUpdater.cs:line 52
   at NuKeeper.Local.LocalEngine.Run(SettingsContainer settings) in C:\Code\NuKeeper\NuKeeper\Local\LocalEngine.cs:line 54
   at NuKeeper.Program.Main(String[] args) in C:\Code\NuKeeper\NuKeeper\Program.cs:line 28
   at NuKeeper.Program.<Main>(String[] args)

With ASP.NET Core 2.1, the main package reference for the core projects is changed from

<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.8" />

to

<PackageReference Include="Microsoft.AspNetCore.App" />

I think the actual version is determined by the SDK. Running NuKeeper on a csproj that contains this PackageReference displays an ArgumentNullException. This package could be skipped, so that the error is not shown.

Could not read package from <PackageReference Include="Microsoft.AspNetCore.App" /> in file C:\Users\me\Source\Repos\Foo\Bar\Bar.csproj ArgumentException : Value cannot be null or an empty string.
Parameter name: value

Probably caused by the NuGetVersion constructor at

Currently we rely on the user having nuget installed and installed in the correct place

https://www.nuget.org/packages/NuGet.CommandLine/

We can break that dependency by including nuget as a nuget package in true nugetception

Potentially slack or whatever - potentially we can just use github's infrastructure to communicate but it could be handy to have discussions through slack or gitter or something like that

The way that dotnet does it is that a main command verb has no dash at all, e.g. dotnet build so NuKeeper inspect would work like that.
Then the options have a short form with one dash and a long form with 2 dashes, e.g. -v, --verbosity
And no equals signs
e.g. dotnet build -v q and dotnet build --verbosity quiet

CommandLineUtils at https://github.com/natemcmaster/CommandLineUtils is a fork of the (no longer published) dotnetcore command line library and would allow us to get much closer to being consistent with other tools.

This should probably be split into multiple PRs, but published in a single new release, so as to not have multiple releases one after the other, each breaking compatibility.

Status:

• inspect starts
• inspect accepts options and help
• logging levels can be set
• update command works
• repository command works
• organisation command works
• various smaller configuration settings
• version output correct
• review by native speakers / feedback on option names
• documentation update
• configuration file support (perhaps response file? that's built in)
• code cleanup (final removal of old settings handling

Update a particular package across all repositories on the github server.

I had this scenario presented at work:

We have an internal github at "https://github.mycompany.com".
It has multiple "organisations" in github's term, used for teams or departments.
Organisations can have multiple repositories each. Most of them, but not all, contain .NET code.
We have an internal nuget feed server at "https://packages.mycompany.com".
We have an internal nuget package, e.g. GeneralFunctions version 1.2.3 on this nuget feed.
A bug is discovered in GeneralFunctions, it poses a risk to all production systems.
The bug is fixed in GeneralFunctions version 1.2.4, but now this fix must be rolled out across the enterprise to all projects that use this nuget package version.
This is not easy.

Can NuKeeper automate this problem? Right now, no. The most that we can do is one org at a time. But it's in the adjacent possible - enumerate the orgs on the github server and apply NuKeeper org mode to all of them, which will in turn apply repo mode to all the repos therein.

This could go wrong. To stop it being a "nuclear" mode, I would impose some restrictions on it, e.g.

• must be against a server other than github.com
• used have a -i package pattern to filter in only particular updates
• A limit, max repos to process

As you can see, there is a csproj, fsproj, and vbproj present in the directory but NuKeeper only reports "Found 15 packages in use, 15 distinct, in 1 projects."

Updating package references in a csproj file can changes the order of the referenced projects which in turn can lead to merge conflicts and additional line noise. For example:

<ItemGroup>
  <PackageReference Include="A" />
  <PackageReference Include="B" />
  
  <!-- a comment -->
  <PackageReference Include="ThePackageToUpgrade" />
</ItemGroup>

will result in:

<ItemGroup>
  <PackageReference Include="A" />
  <PackageReference Include="B" />
  <PackageReference Include="ThePackageToUpgrade" />
  
  <!-- a comment -->
</ItemGroup>

I believe this is a side effect of removing the package reference and re-adding it (in DotNetUpdatePackageCommand). I think you should be able to use add to update if the version is specified, however I'm not an expert on doing this programatically.

Let me know if you need any more info.

I'm not entirely sure this is a valid scenario in dotnet core, but don't really see why it wouldn't be.

People have suggested pulling out the following parts as something easily invokable, maybe in separate projects in the NuKeeper solution.

Two scenarios:

I have code already checked out of git on my local hard drive. I want to inspect it and generate the list of potential nuget package upgrades.

No interaction with git or github is needed, the files as they exist on the file system will be used. No nuget updates will be applied, so no files will be changed locally, just a report generated.

I have code already checked out of git on my local hard drive. I want to apply a package update locally across the solution.

No interaction with git or github is needed, the files as they exist on the file system will be used. Nuget updates will be applied to change files locally, but no git commit or github PRs will be raised.

Currently, Repository Mode accepts a repository URI and extracts the owner, repo name and github api endpoint from that.

Organisation mode however accepts organisation name and github api endpoint.

We want to standardise these

On a run on an internal repo I get the following

Git url: https://github.je-myco.com/team/foo.git
request failed with status code: 401

Seems to be since the change to lib2gitsharp

Implement a libyear functionality
When reporting
simply sum the ages of all possible updates, and report that.

Hi, I'm a graphic designer and I like to collaborate with open source projects. Do you know that the graphic image of a project is very important? thinking about it I would like to design a logo for your Project NuKeeper.

I will be pleased to collaborate with you.

If you run NuKeeper in a default user folder, it can abort with an exception:

Unhandled Exception: System.UnauthorizedAccessException: Access to the path 'C:\Users\anthony.steele\Application Data' is denied.
   at System.IO.Enumeration.FileSystemEnumerator`1.CreateRelativeDirectoryHandle(ReadOnlySpan`1 relativePath, String fullPath)
   at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
   at System.Linq.Enumerable.TryGetFirst[TSource](IEnumerable`1 source, Boolean& found)
   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source)
   at NuKeeper.Inspection.Sources.NugetConfigFileReader.ReadNugetSources(IFolder workingFolder) in C:\Code\NuKeeper\NuKeeper.Inspection\Sources\NugetConfigFileReader.cs:line 23

It should not crash in this case. Can skip the protected folder and carry on.

I cannot update a beta package to a later beta package, as all beta updates are always filtered out.
Need a flag to make betas visible? Only apply beta updates when it's already using a beta?

Example: xunit released new version 2.4. NuKeeper generates PackageReference updates, but no DotNetCliToolReference is created.

Sample from the project file:
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.1" />

Problem with adding support for this: neither dotnet nor NuGet nor Visual Studio support maintaining those entries. There's been some discussion, looks like dotnet tool is supposed to eventually handle them (when non-global mode is added), but currently those require manually editing the project file.

Related issues:
https://github.com/dotnet/cli/issues/917
NuGet/Home#4901

When running in org mode if you find yourself sharing an org with other teams who may not want to necessarily have nukeeper run on their repositories (shame on them!) or if you have a legacy code base for which nukeeper should be excluded because otherwise Chaos™️ then it would be nice if you could have a repository "opt-in" to having nukeeper applied perhaps by using a github repository label.

Some packages are best updated together, e.g. NLog and NLog.Schema, or all the AWSSDK.* packages.
Roll them into 1 PR.

Currently running a homespun github client which is untested and hard to maintain. Swap out for https://github.com/octokit/octokit.net

On appveyor and/or travis
as per https://github.com/justeat/NLog.StructuredLogging.Json/ appveyor.yml / .travis.yml

On a VS2015 project, this line gives an error message: Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.

It works if you run nuget restore in the same folder as the .sln file instead. Doing this once may be a better option.

The all-netcore scenario should work:
Updating netcore solutions should work on Linux and mac machines

It would be great to have VSTS support. This should be pretty similar to implement like GitHub.

There's a GitHttpClient to do this:
https://msdn.microsoft.com/library/microsoft.teamfoundation.sourcecontrol.webapi.githttpclient.aspx

it's published as a nuget package:
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.Client/16.136.1-preview

I noticed the following in your documentation:

Also, not all linux distributions are supported by LibGit2Sharp, which is a c# wrapper for the platform-specific binaries of LibGit2.

I just wanted to point out that as of LibGit2Sharp 0.26.0-preview-0027, we should now support all the linux distros that .NET Core 2.1 is supported on.

If you do find a distro that doesn't work, please file an issue, because I now have the infrastructure in place to easily add another native library to LibGit2Sharp.NativeBinaries.

Hi!
Is it possible to add a link to the pull requests where an api diff can be inspected?
Fuget is a service to inspect nuget packages and they provide api diffs, something like this:
https://www.fuget.org/packages/Newtonsoft.Json/11.0.2/lib/netstandard2.0/diff/9.0.1/
What's your opinion about it?

ATM there is only a GitHub Integration.

Having an GitLab MR Integration would open the door for many more users

Maybe https://github.com/libgit2/libgit2sharp

I have found that certain config variables (e.g. max_pull_requests_per_repository) do not get applied when run in repository mode. They do, however, work when using the short version - maxpr in this case.

Delete of temporary folders always fails.
Even on old folders that aren't in use anymore.
But you can do this through file explorer.
How do we make it happen programmatically?

In the AWS Watchman runs, NuKeeper has been failing with errors as below.

I'm not sure what's causing it. It is correct to attempt to update AWSSDK.Core first, as it is upstream of the other AWSSDK.* packages.

But it might be that when the projects relate to each other and with the new package model have tree of project and package dependencies, it matter which project is updated first - i.e. it should be the upstream project first?

Selection of package updates: 12 candiates, filtered to 10, capped at 3
Selected package update of AWSSDK.Core to 3.3.24.3
Selected package update of AWSSDK.DynamoDBv2 to 3.3.10.3
Selected package update of AWSSDK.CloudWatch to 3.3.6.6
Nuget restore on /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab AwsWatchman.sln
Cannot run NuGet.exe file restore as OS Platform is not Windows
Updating 'AWSSDK.Core' from 3.3.22.5 to 3.3.24.3 in 3 projects
Update failed Exception : Exit code: 1

  Restoring packages for /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.AwsResources/Watchman.AwsResources.csproj...
  Restore completed in 290.79 ms for /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.AwsResources/Watchman.AwsResources.csproj.
  Restore completed in 0.84 ms for /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Configuration/Watchman.Configuration.csproj.
  Restoring packages for /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/Watchman.Engine.csproj...
/tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/Watchman.Engine.csproj : error NU1605: Detected package downgrade: AWSSDK.Core from 3.3.24.3 to 3.3.22.5. Reference the package directly from the project to select a different version.
/tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/Watchman.Engine.csproj : error NU1605:  Watchman.Engine -> Watchman.AwsResources -> AWSSDK.Core (>= 3.3.24.3)
/tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/Watchman.Engine.csproj : error NU1605:  Watchman.Engine -> AWSSDK.Core (>= 3.3.22.5)
  Generating MSBuild file /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/obj/Watchman.Engine.csproj.nuget.g.props.
  Generating MSBuild file /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/obj/Watchman.Engine.csproj.nuget.g.targets.
  Restore failed in 102.21 ms for /tmp/NuKeeper/c40c2eb6aaa746038d80b150d713d6ab/Watchman.Engine/Watchman.Engine.csproj.
```

Hi,
Is this possible to have local config.json in the directory I'm running nukeeper?

Also, please rename config.json to something more specific (e.g. nukeeper.json or nukeeper.config.json).

P.S. Thanks for a great work done on nukeeper!

For some build server scenarios, being able to run NuKeeper inside a simple Docker container would be quite useful. Currently this seems to fail on trying to use LibGit2Sharp - possibly a libc mismatch?

Minimal Dockerfile:

FROM microsoft/dotnet:2.1-sdk
RUN dotnet tool install --global NuKeeper
CMD ["/root/.dotnet/tools/NuKeeper", "mode=repository", "t=github-token", "github_repository_uri=https://github.com/my/repo", "log=Verbose"]

Building:
docker build -t nukeeper .
Running:
docker run nukeeper

Current output:

Failed on repo mysamplerepo TypeInitializationException : The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw an exception.
   at LibGit2Sharp.Core.NativeMethods.git_clone(git_repository*& repo, String origin_url, FilePath workdir_path, GitCloneOptions& opts)
   at LibGit2Sharp.Core.Proxy.git_clone(String url, String workdir, GitCloneOptions& opts)
   at LibGit2Sharp.Repository.Clone(String sourceUrl, String workdirPath, CloneOptions options)
   at NuKeeper.Git.LibGit2SharpDriver.Clone(Uri pullEndpoint) in C:\Code\NuKeeper\NuKeeper\Git\LibGit2SharpDriver.cs:line 40
   at NuKeeper.Engine.RepositoryUpdater.GitInit(IGitDriver git, RepositoryData repository) in C:\Code\NuKeeper\NuKeeper\Engine\RepositoryUpdater.cs:line 100
   at NuKeeper.Engine.RepositoryUpdater.Run(IGitDriver git, RepositoryData repository) in C:\Code\NuKeeper\NuKeeper\Engine\RepositoryUpdater.cs:line 49
   at NuKeeper.Engine.GithubRepositoryEngine.Run(RepositorySettings repository, UsernamePasswordCredentials gitCreds, Identity userIdentity) in C:\Code\NuKeeper\NuKeeper\Engine\GithubRepositoryEngine.cs:line 45

Which one?

I'd like a bit of a rethink with the output of the inspect command, and logging, and the csv report which should be folded in there.

Currently all output goes via the logger to the console; except for reports, which are csv to file. I'm thinking that the inspect command is run in order to get this output, and it's something different to the debug logging. You will want to split into two outputs that can be managed independantly.

The non-logging output might have a choice of output formats (e.g. readable text, csv report, json, just the libyear score), and a choice of output destinations (stdout, named file). or possibly configure so that the inspect output goes to stdout and the logging to file.

I am getting an error:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.0-rc1' was not found.

I installed from Nuget.

When NuKeepeer uses private nuget feeds or multiple feeds, we specify nuget package sources in config or commandline via sources=http://packages.sourceA.com/feed;http://packages.sourceB.com/feed This is one of the longest parts of the commandline.

However in many cases there is a nuget.config file containing packageSources data for the repo, listing these sources.

This is a good practice which should be encouraged, as it makes the build more self-contained - it works due to package source settings in the repo rather than global package source settings that may not be present on a new machine.

In this case NuKeepeer can read the sources out of this file instead of having to specify them, either by default or with a switch e.g. sources=configfile

#61

Look at the detail and you'll see two travis builds - one /push and one /pr

Need to go into the travis build settings and modify it so that it will only build a PR or only build a branch push

Update run fails with the following:

error MSB4019: The imported project "C:\Program Files\dotnet\sdk\2.1.104\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Other projects in the solution update correctly, this seems like a possible bug in dotnetcore? Need to check if it happens with a new AspNet WebApi .NET (classic) or is this something from my historical project leftovers.

This program should be easy to find and easy to use. It should be well-known and have approachable docs to get you started.

Output (in the default setting) should be useful but not verbose.

The global tools package and "inspect" mode by default is a start at ease of use.