NETCoreCheck usage guide

[Deilan]

Could you please provide NETCoreCheck usage guide or some other kind of documentation for it?

I downloaded release from NuGet, tried to launch both x86 and x64 NetCoreCheck.exe, but the tool process exits immediately without any output. Passing /?, -? or --help doesn't change a thing.

[MSLukeWest]

You're right, we should add this. For now I'll explain it here:

Arg 1 (Required): Runtime Name, meaning one of these three: "Microsoft.AspNetCore.App", "Microsoft.WindowsDesktop.App", "Microsoft.NETCore.App"
Arg 2 (Required): Version to check for in format x.y.z (Examples: 3.1.0, 5.0.2)
Arg 3 (Optional): Path to log file, defaults to %temp%\dd_NetCoreCheck_12345.log

If it returns 0 the runtime requirement is satisfied.

Examples:

NETCoreCheck.exe Microsoft.AspNetCore.App 3.1.0
NETCoreCheck.exe Microsoft.WindowsDesktop.App 5.0.2 c:\foo\bar.log

Important note: We will soon have an additional parameter to support specifying a roll forward policy, see #82

[MSLukeWest]

Fixed in the 6.0.0-preview.1.21179.1 version of the Microsoft.NET.Tools.NETCoreCheck NuGet packages

Now that there's two optional parameters we had to change the syntax to require names for each parameter. Here's the current usage guide from running NETCoreCheck /?:

NETCoreCheck [options]
-n, --runtimename -       Runtime name                    (Example: Microsoft.AspNetCore.App)
-v, --runtimeversion -    Runtime version in format x.y.z (Example: 1.2.3)
-r, --rollforwardpolicy - (Optional) Roll forward policy  (Example: LatestMajor)
-c, --runtimeconfigfile - Path to runtime config file     (Example: c:\Foo\Bar.runtimeconfig.json)
-l, --logfile -           (Optional) Path to log file

If runtimeconfigfile is specified then runtimename, runtimeversion and rollforwardpolicy shouldn't be.

If 0 is returned the runtime requirement is satisfied.

Examples:

NETCorecheck --runtimename Microsoft.AspNetCore.App --runtimeversion 3.1.0
NETCorecheck -n Microsoft.WindowsDesktop.App -v 5.0.1 -r LatestMajor
NETCorecheck -c c:\Foo\Bar.runtimeconfig.json -l c:\Foo\Bar.log

[sergeevabc]

Uh, guys, why isn't NETCoreCheck working?

$ ver
Microsoft Windows [Version 6.1.7601]

$ wget -O- https://www.nuget.org/api/v2/package/Microsoft.NET.Tools.NETCoreCheck.x64/5.0.0 | busybox unzip - -d C:\Test\Netcorecheck

$ cd C:\Test\Netcorecheck\win-x64

$ dir /b
NetCoreCheck.exe
NetCoreCheckCA.dll

$ NetCoreCheck.exe

Nothing happens at all.

[MSLukeWest]

Uh, guys, why isn't NETCoreCheck working?

$ ver
Microsoft Windows [Version 6.1.7601]

$ wget -O- https://www.nuget.org/api/v2/package/Microsoft.NET.Tools.NETCoreCheck.x64/5.0.0 | busybox unzip - -d C:\Test\Netcorecheck

$ cd C:\Test\Netcorecheck\win-x64

$ dir /b
NetCoreCheck.exe
NetCoreCheckCA.dll

$ NetCoreCheck.exe
Nothing happens at all.

I just tried the latest version on NuGet (7.0.0) and it works as expected. In this case, it shows the help:

_PS C:\Users\lukewest\Downloads\microsoft.net.tools.netcorecheck.x64.7.0.0.nupkg\win-x64> .\NetCoreCheck.exe
NETCoreCheck [options]
-n, --runtimename - Runtime name (Example: Microsoft.AspNetCore.App)
-v, --runtimeversion - Runtime version in format x.y.z (Example: 1.2.3)
-r, --rollforwardpolicy - (Optional) Roll forward policy (Example: LatestMajor)
-c, --runtimeconfigfile - Path to runtime config file (Example: c:\Foo\Bar.runtimeconfig.json)
-l, --logfile - (Optional) Path to log file

If runtimeconfigfile is specified then runtimename, runtimeversion and rollforwardpolicy shouldn't be.

If 0 is returned the runtime requirement is satisfied.

Examples:

NETCorecheck --runtimename Microsoft.AspNetCore.App --runtimeversion 3.1.0
NETCorecheck -n Microsoft.WindowsDesktop.App -v 5.0.1 -r LatestMajor
NETCorecheck -c c:\Foo\Bar.runtimeconfig.json -l c:\Foo\Bar.log_

[sergeevabc]

Like I said, nothing is displayed on my end. Maybe this program can't run on Windows 7, maybe it needs access to dotnet or nuget (which I don't have), but in this case it would be worth adding some kind of error message instead of a blank screen so that the user does not get confused.

Workaround is to use the third-party app called DotNetVer. It runs flawlessly.