Are there plans to support a plain text output file? Do you accept PRs? As I’d be happy to contribute a PR to add this functionality.

Hi,

I'm using dotnet outdated for my local dev loop where I make adjustments in one repo that publishes nugets into a local directory (in my case c:\tmp\localNuget) which is set up as a source for nugets, and then in the other repo use dotnet outdated to update.

Now it would be nice if I could tell dotnet outdated to exclusively look at the local source because sometimes on our internal private nuget stream there will be a package update that I do not want to get while in my local loop (and filtering by name doesn't help me there because both the local packages and the ones from the private stream have, not surprisingly, the same prefix).

Is that realistic or is there any fundamental architectural obstacle? If someone familiar with the code base wants to give me a few pointers I can also give it a try and implement this myself in a PR, if this would be welcome...

Cheers,
MR

Hi,
This works great in CI (azure) but i did not see any mentions of Github Actions in the readme..

I want to be able to lock Microsoft.EntityFrameworkCore to a major version and continue to update to minor|patch versions. But also update Serilog to the latest major version.

If i am running efcore 3.1.8 and run dotnet outdated it will suggest updating to 5.0.3, when more realistically i want to update to 3.1.12.

this could be implemented as an additional param to the version-lock argument, where multiple instances of the argument could be added with different patterns

dotnet outdated  \
    --version-lock major microsoft \
    --version-lock major newtonsoft \
    --output outdated.json

Hi,

We work entirely internally, using private package servers, and not having access from our servers to access the public NuGet servers.

This is making it pretty-much impossible to build NuKeeper, or to install it.

Is there any chance of a packaged-up version of the application being made available?

My Mac's firewall software is fairly picky, and it's not allowing outbound connections by dotnet-outdated since the executable isn't code-signed.

Unfortunately, this is the sort of thing that should only be set up by the developer who is pushing to nuget, or I'd look into submitting a PR to help :(.

For some reason dotnet-outdated (v3.2.1) can't resolve latest version of
Microsoft.VisualStudio.Azure.Containers.Tools.Targets
so even though I am on latest I get a suggestion to upgrade the package to a missing version.
[net6.0] Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.14.0 ->

Generating the report using dotnet-outdated -o packages.json shows the following for each project that has a reference to this package:

"TargetFrameworks": [
	{
	  "Name": "net6.0",
	  "Dependencies": [
		{
		  "Name": "Microsoft.VisualStudio.Azure.Containers.Tools.Targets",
		  "ResolvedVersion": "1.14.0",
		  "LatestVersion": null,
		  "UpgradeSeverity": "Unknown"
		}
	  ]
	}
]

I am using Microsoft.Build.CentralPackageVersions MSBuild Sdk, but I can't see how that could cause this as the failure seems to be to get the latest version from nuget.org for this package.

some packages like :
AspNetCore.HealthChecks.Publisher.Datadog
AspNetCore.HealthChecks.UI.Client
AspNetCore.HealthChecks.UI
AspNetCore.HealthChecks.UI.InMemory.Storage

only supports net60, while others ( AspNetCore.HealthChecks.MongoDb, AspNetCore.HealthChecks.AzureStorage ) supports also netstandard20, would be nice to have netstandard20 back in...

How does this differ from dotnet list package --outdated?

Hi,
Thanks for the great package!

I recently tried to automate nuget updates to a solution that contains a database project. This fails with the standard

Analyzing project(s)...Unable to process the project `D:\a\1\s\Project.sln. Are you sure this is a valid .NET Core or .NET Standard project type?

Here is the full error message returned from the Microsoft Build Engine:

Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

D:\a\1\s\src\Infrastructure\SeSuDB\SeSuDB.sqlproj(58,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\6.0.302\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\6.0.302\\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" is correct, and that the file exists on disk.
 -  - exit code: 1

More information on the issue:
dotnet/sdk#10441
dotnet/sdk#16587

Possible solution:
Allow us to give -configuration "Release" as parameter for the restore/build commands. Then we could ignore the project from Release config builds which I think would be enough

Currently, does not support the central package management feature https://docs.microsoft.com/en-us/nuget/consume-packages/central-package-management

When I try to upgrade my packages, it did not update the package version defined in Directory.Packages.props, but updated the package in the project with a new version

My project is here: https://github.com/WeihanLi/dotnet-httpie/tree/1898489d23a36b0764961e02e5a14929895fcbef

Hi.
I try migrate my solution to Centralized Package Management, but dotnet-outdated seems to not support it yet.
dotnet outdated -u add version to csproj instead update version in Directory.Packages.props

I have solution files which include SSDT sqlproj files. And dotnet outdated failed on these projects

error MSB4019: The imported project "C:\Program Files\dotnet\sdk\6.0.100-preview.1.21103.13\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\6.0.100-preview.1.21103.13\\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" is correct, and that the file exists on disk.

does service fabric project supported?

Tools such as npm-check-updates allow for a config file to contain configurations to be used by the tool. See https://www.npmjs.com/package/npm-check-updates

A typical use case is a package version that may contain a breaking change (or a bug) and you do not want to upgrade that particular package just yet.

While this option is available at the command line, it's quite inconvenient to have to type this each time. While a workaround could be written using a script (PS, sh, etc.), providing a feature that is available in similar tools would be a great addition.

This doesn't have to be limited to just include/exclude. It could include (all) other command line optins as well. A file .dotnet-outdated.yaml could look similar to the following, which specifies a couple of packages to be locked at specific versions:

options:
   ignore:
      - ExRam.Gremlinq.Providers.JanusGraph: 8.6.0
      - Foobar:

If a version number is specified, then dotnet-outdated could upgrade/downgrade to that specific version, i.e., will not upgrade beyond the version specified. Without a version number, the package will ignored, regardless of which version is actually used. This essentially is the equivalent of using manual upgrading for that particular package.

dotnet-outdated would find this file which by convention could be named .dotnet-outdated.yaml by looking for this file in the same folder where it starts its search for either the solution or the project file.

The config file would be optional, so if absent, dotnet-outdated would not fail.

As an extension, this could allow for different copies of this file next to each project file, e.g. foo.csproj => foo.csproj.dotnet-outdated.yaml or something like that. However, in my experience once a package should be ignored for upgrading, it is ignored for all projects within a solution.

Hi there,

Unless I'm doing something wrong, "dotnet outdated" does not appear to take into account nuget package sources

I'm attempting to test a dotnet template package as part of a CI build - the template depends on other package built as part of the same build.

1. build nuget packages (which includes a template package)
2. add local package folder as nuget source
3. disable nuget.org as a package source
4. install new templates
5. use dotnet new to create project using the new templates
6. use dotnet outdated -u -pre Always to upgrade the template package using the new nuget packages

For example:

dotnet new -i MyProject.Templates::1.6.0-update-templates0001 --nuget-source /home/runner/work/packages
dotnet tool install --global dotnet-outdated-tool

nuget sources add -Name local -Source /home/runner/work/packages
nuget sources Disable -Name nuget.org
nuget sources list

dotnet new templateName -o Test.ProjectName 
dotnet outdated -vl Major -pre Always -u -inc MyProject Test.ProjectName

This fails to find any updates for MyProject but does for, eg, Microsoft.Extensions.DependencyInjection. I'd expect it to find MyProject::1.6.0-update-templates0001 etc

nuget sources list confirms that nuget.org is disabled.

Is this a known issue or is my understanding incorrect!?

many thanks.

Pete

Add new args to allow automatically update outdated packages
-u|--upgrade -> update all packages to the latest version (stable) - already exists
--update-major -> update all packages to the latest major version (stable)
--update-preview - > update all packages to the latest version (preview)

In most of my unit test projects, I take a dependency on MSTest.TestAdapter 2.1.2. Some of these projects target netcoreapp3.1 and others net472. The former pose no problem when analyzed by dotnet outdated; however, the latter produce this kind of output and the tool exits with a non-0 return code:

Discovering projects...
Analyzing project(s)...
Analyzing dependencies...
» UnitTests.AddUp.TwincatAds
  [.NETFramework,Version=v4.7.2]
  MSTest.TestAdapter  2.1.2 ->      
Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?
Unable to find DOTNET_HOST_PATH environment variable. If you use credential providers for your NuGet sources you need to have this set to the path to the `dotnet` executable.
Version color legend:
<red>   : Major version update or pre-release version. Possible breaking changes.
<yellow>: Minor version update. Backwards-compatible features added.
<green> : Patch version update. Backwards-compatible bug fixes.
You can upgrade packages to the latest version by passing the -u or -u:prompt option.

As a minimal repro, it's enough to create a csproj like the one below and have dotnet outdated run against it:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net472</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="MSTest.TestAdapter" Version="2.1.2" />
  </ItemGroup>
</Project>

Now for the beginning of an explanation...

By digging a bit in the source code, I think I've spotted the place where things go wrong. It happens in this loop.

Because I'm targeting .NET 4.7.2 and this package explicitly defines dependencies for .NET Core 1.0 (See here), I end up with no 'compatible metadata' for this package/TFM pair (because of whatever logic is implemented in Nuget Framework's FrameworkReducer).

This is weird because the package can surely be consumed from classic .NET framework...

Note that by examining Fuget's details I could see it lists a _common framework in the set of supported targets (along with uap10 and netcoreapp1.0). I don't know how it determines that especially when compared to what it says about MSTest.TestFramework that lists no dependencies in its nuspec but appears as compatible with net45. Maybe having a look (which I may do if I find some time) at how Fuget builds its framework compatibility list could help here.

Whenever I run dotnet outdated (version 3.2.1) in a folder that contains more than 1 .proj file, it fails with the following error:

C:\temp\tests> dir

    Directory: C:\temp\tests

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          22/10/2021    14:03                src
-a---          22/10/2021    10:08           3849 build.proj
-a---          22/10/2021    10:08           4618 run-unit-tests.proj

C:\temp\tests> dotnet outdated --version
Specify which project file to use because this 'C:\temp\tests' contains more than one project file.
C:\temp\tests> dotnet outdated ./src/MyProject.sln --version-lock Minor --fail-on-updates
Specify which project file to use because this 'C:\temp\tests' contains more than one project file.
C:\temp\tests>

Note that those files are not the ones I want dotnet outdated to run against. But even when specifying a target solution it fails.
My only way out was to move these .proj files somewhere else.

Running this one

dotnet-outdated -u "c:\mysolution\mysolution.sln"

works correctly when all projects in the solution are .NET Core projects (or .NET Standard).

it fails even when only one single .NET Full Framework or other types like a VSTO project is included in the solution with something like this:

Unable to process the project `c:\mysolution\mysolution.sln. Are you sure this is a valid .NET Core or .NET Standard project type?

Here is the full error message returned from the Microsoft Build Engine:

Microsoft (R)-Build-Engine, Version 17.0.0+c9eb9dd64 für .NET
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

c:\mysolution\MyWordAddIn\MyWordAddIn.csproj(235,3): error MSB4019: Das importierte Projekt "C:\Program Files\dotnet\sdk\6.0.102\Microsoft\VisualStudio\v17.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" wurde nicht gefunden. Stellen Sie sicher, dass der Ausdruck in der Import-Deklaration "C:\Program Files\dotnet\sdk\6.0.102\Microsoft\VisualStudio\v17.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" richtig ist und dass die Datei auf dem Datenträger vorhanden ist.
exit code: 1

My question

How is it possible to tell dotnet-outdated to ignore certain CSPROJ projects from the solution?

Or is it at least possible to tell dotnet-outdated to automatically skip CSPROJ projects where errors occur? Currently the whole run of dotnet-outdated exists at the very first erroneous project.

As of now I'm doing some scripting to iterate all CSPROJ files in my folder by myself, and passing each one to a dotnet-outdated call, skipping a self-maintained ignore list:

dotnet-outdated -u "c:\mysolution\myproject1\myproject1.csproj"
dotnet-outdated -u "c:\mysolution\myproject2\myproject2.csproj"
...

In my case I do have 40+ projects in the solution and only have to ignore two .NET Framework projects.

on macOS, homebrew only leaves the latest SDK/runtime combo for .NET installed and so I was getting the following error when trying to run dotnet outdated

▲ project [master] dotnet outdated -u:prompt
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' (x64) was not found.
  - The following frameworks were found:
      6.0.0 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=osx.11.0-x64

I've created a pull request that might fix this, please see pr #215

Add option to support --ignore-failed-sources

It would be great if this tool could check tools for outdated versions (local and global)

TLDR;
Tool doesn't cover version ranges such as [3.*,4.*), which are considered valid versions on the Nuget PackageReference Documentation

Ran into this today when I realized one of the licensed third party libraries we use got a major update. For example, our license only covers version 3.x but not the newer 4.x one. So to prevent the new version from showing up as an available upgrade in both Visual Studio and from this tool via command line, I added a version range to exclude showing version 4.x. Visual Studio worked fine, but the dotnet outdated command gets an error saying that it was unable to process the project, stating that

'[3.*,4.*)' is not a valid version string

Steps to reproduce

1. docker pull mcr.microsoft.com/dotnet/sdk:3.1
2. docker run -it mcr.microsoft.com/dotnet/sdk:3.1 /bin/bash
3. dotnet tool install --global dotnet-outdated-tool
4. mkdir -p /opt/update-testing
5. cd /opt/update-testing
6. dotnet new console
7. dotnet add update-testing.csproj package StackExchange.Redis (current version is 2.2.62)
8. /root/.dotnet/tools/dotnet-outdated

Result

# /root/.dotnet/tools/dotnet-outdated
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            » update-testing
  [.NETCoreApp,Version=v3.1]
  StackExchange.Redis  2.2.62 ->

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?

Unable to find DOTNET_HOST_PATH environment variable. If you use credential providers for your NuGet sources you need to have this set to the path to the `dotnet` executable.

Version color legend:
<red>   : Major version update or pre-release version. Possible breaking changes.
<yellow>: Minor version update. Backwards-compatible features added.
<green> : Patch version update. Backwards-compatible bug fixes.

You can upgrade packages to the latest version by passing the -u or -u:prompt option.
Elapsed: 00:00:03.0989542

Expected Result

No-op, as package is already the latest version.

StackExchange.Redis is the only package that we use that produces this error, thus I created this minimal reproduction.

Thanks for a great tool.

I recently added an esproj (EcmaScript Project) file to my sln and dotnet outdated fails.

I assume it would be good to just ignore all unknown or unsupported project types.

Should have a mechanism to report nuget packages that have been marked as deprecated.

Hey there!

First of all, thank you very much for this project and your continued support. I've been unfortunately experiencing some issues where the security policies from my organization are blocking the usage of the tool.

Terminal ouput

Windows Defender

Would it be possible to find a way around this? Maybe by also adding signing to keep Windows Defender happy? Unfortunately there's not much more details I could provide due to security concerns, but if I can lend a hand in any other way, please do let me know.

Thanks in advance!

Unable to process the project `Test.sln. Are you sure this is a valid .NET Core or .NET Standard project type?
Here is the full error message returned from the Microsoft Build Engine:

Microsoft (R) Build Engine version 16.8.0-preview-20464-02+0220c5eae for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

Android.csproj(124,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\6.0.100-alpha.1.20467.1\Xamarin\Android\Xamarin.Android.CSharp.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\6.0.100-alpha.1.20467.1\Xamarin\Android\Xamarin.Android.CSharp.targets" is correct, and that the file exists on disk.
iOS.csproj(137,3): error MSB4019: The imported project "C:\Program Files\dotnet\sdk\6.0.100-alpha.1.20467.1\Xamarin\iOS\Xamarin.iOS.CSharp.targets" was not found. Confirm that the expression in the Import declaration "C:\Program Files\dotnet\sdk\6.0.100-alpha.1.20467.1\Xamarin\iOS\Xamarin.iOS.CSharp.targets" is correct, and that the file exists on disk.

• • exit code: 1

I'm looking to convert over from NuKeeper to using dotnet-outdated, but have a missing requirement.

Nukeeper had the functionality that if a Directory.Build.props file existed and provided a package version, it would correctly update that package version in that file.

The current version of dotnet-outdated seems to instead just fail with An error occurred while upgrading MyProject instead.

An example Directory.Build.props file like we might use at the root of our repository.

<?xml version="1.0" encoding="utf-8"?>
<Project>
  <ItemGroup>
    <PackageReference Include="My.Org.CodeStandards" Version="1.2.3" />
  </ItemGroup>
</Project>

Our CI fails to update dependencies from time to time.
Seems like that 20 seconds timeout is not enough for a large project with empty NuGet cache.
Currently, I don't see any reason to run MSBuild with timeout. Any chance to remove it completely?

As a temporary workaround it is possible to run dotnet restore in advance.

Version used: 3.0.2

Steps to reproduce:

1. Clear NuGet cache dotnet nuget locals all --clear
2. Run the tool dotnet outdated

Expected behavior:
No errors.

Actual behavior:
Are you sure this is a valid .NET Core or .NET Standard project type?

I have tried to run dotnet outdated but it does not work on my computer.
I have dotnet SDK 5.0.100 and the latest version of the tool 3.1.0. I also have the latest version of Microsoft.NuGet.CredentialProvider

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?
Unable to find DOTNET_HOST_PATH environment variable. If you use credential providers for your NuGet sources you need to have this set to the path to the dotnet executable.

I can set manually DOTNET_HOST_PATH but it still cannot connect to my private nuget source server :

$Env:DOTNET_HOST_PATH = "$env:ProgramFiles\dotnet\dotnet.exe"

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?

Nuget server was added with the dotnet nuget add source command (with username and PAT token as password).
The dotnet command dotnet list package --outdated works well.

Issue description

If I have a reference to Xamarin.Forms in a project fails the following error occurs:

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?

Reproduction steps:

Use the following .csproj file and do a dotnet outdated

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Xamarin.Forms" Version="5.0.0.2337" />
  </ItemGroup>
</Project>

Wtih a F# project with a fsproj file opening with <Project Sdk="Microsoft.NET.Sdk"> and targeting netcoreapp3.1, running "dotnet outdated -u" gives this error:

» RestApi                                                                                                                                       
  [.NETCoreApp,Version=v3.1]
  FSharp.Core  5.0.0 -> 5.0.1
...
Upgrading package FSharp.Core...
An error occurred while upgrading RestApi

FSharp.Core isn't referenced by the fsproj file.

Hello, I'm trying to use dotnet-outdated for a project. I'm trying to use the --no-restore option. However, it appears the project is still attempting to do a restore before updating the file.

When it attempts the restore I get errors about package downgrades. However, I need this to go through so I can update the packages. I've tried using --no-restore, but it appears that the behavior does not change.

Thoughts?

Thanks for having maintained this tool up to now! It has been very useful. When it stops working, it will be missed.

Thanks for your effort, a great tool.

Could we add support for updating by type, like update only minor and patch, exclude major updates

Thanks

It would be awesome if this tool check if project target framework and language version are the latest.

I'm using dotnet-outdated v2.11.0 and after updating the TFM of my projects to net5.0 and running dotnet outdated to analyze the packages to migrate, I'm getting the errors below:

Errors occurred while analyzing dependencies for some of your projects. Are you sure you can connect to all your configured NuGet servers?

Unable to find DOTNET_HOST_PATH environment variable. If you use credential providers for your NuGet sources you need to have this set to the path to the `dotnet` executable.

I have a nuget.config at the root the repo pointing to nuget.org exclusively thus I don't think it's the case of not being able to connect to nuget servers.

DOTNET_HOST_PATH is indeed not defined (not sure why... Probably something missing in the .NET 5 SDK install process).

My nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <disabledPackageSources>
    <clear />
  </disabledPackageSources>
  <fallbackPackageFolders>
    <clear />
  </fallbackPackageFolders>
</configuration>

As far as I can tell this tool has a hard time finding the SDK's installed on my machine. It's asking me to download 5.0.0 when I have 5.0.4 installed. Are there any ways to help this tool find my runtime?

dotnet outdated

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' was not found.
  - The following frameworks were found:
      3.1.1 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=5.0.0&arch=x64&rid=osx.10.15-x64

dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.104
 Commit:    ca6b6acadb

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.15
 OS Platform: Darwin
 RID:         osx.10.15-x64
 Base Path:   /Users/sgourley/.dotnet/sdk/5.0.104/

Host (useful for support):
  Version: 5.0.4
  Commit:  f27d337295

.NET SDKs installed:
  5.0.104 [/Users/sgourley/.dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.4 [/Users/sgourley/.dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.4 [/Users/sgourley/.dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

Description

I have a github project: Minicloner that is set up to build in Azure Pipelines using YAML that runs dotnet outdated --fail-on-updates to make the build fail if there are packages that needs to be updated.
It is using strategy: matrix: to run parallel builds with different OS.

In the following run: https://dev.azure.com/carlosmunozrodriguez/Minicloner/_build/results?buildId=409&view=results there are 3 parallel builds with the following OS: windows-2019, ubuntu-18.04 and macOS-10.15.

From them only macOS-10.15 seems to be failing as expected with error code: 2 and showing which packages need to be updated as can be seen in the log: https://dev.azure.com/carlosmunozrodriguez/Minicloner/_build/results?buildId=409&view=logs&j=9dfcfd74-a2de-5bf2-9e58-61496624eb87&t=97b4bd01-7b13-5e1f-aec9-981abf187912

The other two OSs fail to run dotnet outdated --fail-on-updates and fail (wrongly) with error code: 1 (or -1 I'm not sure), complaining about the .sln file format and not showing any package to be updated as can be seen in https://dev.azure.com/carlosmunozrodriguez/Minicloner/_build/results?buildId=409&view=logs&j=a5ebbe75-5229-5b14-a2b3-c71e02a6da90&t=66e992de-13e4-504c-5081-8f9683287dd0 and https://dev.azure.com/carlosmunozrodriguez/Minicloner/_build/results?buildId=409&view=logs&j=630ea742-76aa-511f-2933-7f478559492b&t=b9a36882-b809-52fe-18e3-8dfc925d8ff5

The relevant portion of azure-pipelines.yaml is here:

jobs:
- job: Build

# Image names can be get from: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software
  strategy:
    matrix:
      Windows:
        imageName: 'windows-2019'
      Ubuntu-18.04:
        imageName: 'ubuntu-18.04' # ubuntu-20.04 doesn't support net core sdk 1.1'
      macOS:
        imageName: 'macOS-10.15'

  pool:
    vmImage: $(imageName)

  steps:
  - task: UseDotNet@2
    displayName: 'Install older dotnet 1.1 runtime'
    inputs:
      packageType: 'runtime'
      version: '1.1.13'

  - task: UseDotNet@2
    displayName: 'Install older dotnet 2.2 runtime'
    inputs:
      packageType: 'runtime'
      version: '2.2.8'

  - task: UseDotNet@2
    displayName: 'Install older dotnet 3.1 runtime'
    inputs:
      packageType: 'runtime'
      version: '3.1.10'

  - task: UseDotNet@2
    displayName: 'Install current dotnet SDK'
    inputs:
      packageType: 'sdk'
      useGlobalJson: true

  - task: DotNetCoreCLI@2
    displayName: 'dotnet --info'
    inputs:
      command: 'custom'
      custom: '--info'

  - task: DotNetCoreCLI@2
    displayName: 'Install dotnet-outdated'
    inputs:
      command: 'custom'
      custom: 'tool'
      arguments: 'install --global dotnet-outdated-tool'

  - task: DotNetCoreCLI@2
    displayName: 'dotnet outdated'
    inputs:
      command: 'custom'
      custom: 'outdated'
      arguments: '--fail-on-updates'

Other things to consider

The solution contains multitargeting projects
There are many runtimes installed and one latest SDK

Between the -u and -u:prompt options, there seems to be space for an automated process to upgrade all packages if they are below a certain threshold of severity. For example, upgrade all packages if the upgrade is only a patch release, or only a minor release.

Essentially, we have a thin brush and a wide brush, but no medium sized brushes.

Ideally, this would look something like this:

dotnet outdated -u:minor

This would automatically upgrade all packages which have minor or patch releases, but not any major versions.

dotnet outdated -u:patch

This would only upgrade if it is a patch release, and leave any minor or major upgrades alone.

It would be nice to optionally prompt after this for any upgrades that aren't included under the threshold, but having to run the command again with -u:prompt isn't that big a deal.

Complementary to issue #181. But to cover when a package hasn't been marked as deprecated, but the source repo is no longer available or has been archived by the maintainers.

Runnin dotnet-outdated against the following project generates no updates:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <OutputType>Exe</OutputType>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
  </ItemGroup>
</Project>

Changing the TargetFramework to simply net5.0 causes an update to be found.

I have the following steps in my pipeline

- task: DotNetCoreCLI@2
    displayName: Restore dependencies
    inputs:
      command: restore
      projects: '$(codebase)/**/*.sln'
      selectOrConfig: config
      nugetConfigPath: ${{ parameters.code.sources }}/nuget.config
      verbosityRestore: Minimal
      workingDirectory: ${{ parameters.code.sources }}

  - task: DotNetCoreCLI@2
    displayName: Install dotnet-outdated
    inputs:
      command: custom
      custom: tool
      arguments: 'install dotnet-outdated-tool -g'

  - task: DotNetCoreCLI@2
    displayName: Update dependencies
    inputs:
      command: custom
      custom: outdated
      arguments: '--upgrade --version-lock Major'      
      workingDirectory: ${{ parameters.code.sources }}

I restore packages explicitly, otherwise I'm receiving "Are you sure this is a valid .NET Core or .NET Standard project type?" error,
with the Restore dependencies step. But when my build reaches Update dependencies it hangs. It hangs on updating packages rather randomly, sometimes at the first package update, sometimes after successfully updating several of them.

/usr/bin/dotnet outdated --upgrade --version-lock Major
Discovering projects...
Analyzing project(s)...
Analyzing dependencies...
» Foo.Bar
  [.NETCoreApp,Version=v3.1]
  Hellang.Middleware.ProblemDetails         5.1.0  -> 5.4.0 
  Microsoft.ApplicationInsights.AspNetCore  2.14.0 -> 2.17.0
  Microsoft.AspNetCore.Mvc.NewtonsoftJson   3.1.5  -> 3.1.16
  Microsoft.AspNetCore.Mvc.Versioning       4.1.1  -> 4.2.0 

» Foo.Bar.Tests
  [.NETCoreApp,Version=v3.1]
  AutoFixture.AutoNSubstitute  4.12.0 -> 4.17.0 
  AutoFixture.Xunit2           4.12.0 -> 4.17.0 
  Microsoft.NET.Test.Sdk       16.6.1 -> 16.10.0

Version color legend:
<red>   : Major version update or pre-release version. Possible breaking changes.
<yellow>: Minor version update. Backwards-compatible features added.
<green> : Patch version update. Backwards-compatible bug fixes.

Upgrading package Microsoft.AspNetCore.Mvc.Versioning...
Project Foo.Bar [.NETCoreApp,Version=v3.1] upgraded successfully

Upgrading package Hellang.Middleware.ProblemDetails...
##[error]The operation was canceled.
Finishing: Update dependencies

It would be nice if this could report on packages that are redundant.

For example, a metapackage A depends on package B. If the .csproj references both then you can remove B.

Concrete example:

<PackageReference Include="Serilog.AspNetCore" Version="3.4.0" />
<PackageReference Include="Serilog.Extensions.Hosting" Version="3.1.0" />

Serilog.AspNetCore 3.4.0 depends on Serilog.Extensions.Hosting 3.1.0. Since the latter is already referenced (transitively), it's redundant and can be removed.

When running this against some of my solutions I'm getting an error message:

An error occurred while upgrading [Project Name here]

There is not information to help me diagnose why I'm getting this error. Is it possible to log out RunStatus.Output to provide some hope of solving this?

Possibly, this could be behind a --verbose flag to prevent it littering the logs for everyone?

Great tool, thanks!

This is a feature suggestion/discussion. There is another similar tool at https://github.com/fabiano/dotnet-ossindex which checks the sonatype API (which is free) for packagaes which have known security issues published but I think it would be great if it was incorporated into dotnet-outdated so users can do outdated packages and security issues in one sweep. How about adding a flag like --security which also checks all packages with for known CVEs security issues listed in sonatype as well and flags these prominently in the output/return code?

For solutions using the new NuGet Central Packagement feature, trying the --upgrade option will cause dotnet-outdated to add the package versions to the csproj package references, rather than updating the package versions in Directory.Packages.props, and consequently break the build. A simplified example of how this manifests is shown below.

Updating the tool to support this NuGet feature would allow such projects to leverage the --upgrade option, rather than just needing to manually update using the console's output as a guide on what to update.

Happy to help-out with getting this supported!

Before

Directory.Packages.Props

<Project>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="12.0.2" />
  </ItemGroup>
</Project>

Project.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

After

Directory.Packages.Props

<Project>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="12.0.2" />
  </ItemGroup>
</Project>

Project.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json">
      <Version>12.0.3</Version>
    <PackageReference>
  </ItemGroup>
</Project>