Command-line-api: ArgumentNullException when running sample without args

[pieter-venter]

I get an System.ArgumentNullException: Value cannot be null exception when trying out the sample and calling it with no arguments.

I.e. just calling dotnet run

I was expecting to see some help if I just run the program without providing any args. If I provide some arguments, it works fine.

I'm using .Net Core 2.2 (latest) and running on Ubuntu.

Is this expected behavior or a bug?

The full exception below.

c# Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentNullException: Value cannot be null. Parameter name: fileName at System.IO.FileInfo..ctor(String originalPath, String fullPath, String fileName, Boolean isNormalized) at System.IO.FileInfo..ctor(String fileName) --- End of inner exception stack trace --- at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions) at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.CommandLine.Binding.ModelBinder.CreateInstance(BindingContext context) in /_/src/System.CommandLine/Binding/ModelBinder.cs:line 81 at System.Linq.Enumerable.SelectListIterator`2.ToArray() at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source) at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context) in /_/src/System.CommandLine/Invocation/ModelBindingCommandHandler.cs:line 41 at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass2_0.<<InvokeAsync>b__0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationPipeline.cs:line 37 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseErrorReporting>b__16_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 320 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass8_0.<<UseTypoCorrections>b__0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 214 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseSuggestDirective>b__7_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 195 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseDebugDirective>b__4_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 128 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseParseDirective>b__6_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 177 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<UseHelp>b__14_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 288 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass3_0.<<UseVersionOption>b__0>d.MoveNext() in /_/src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs:line 66 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c.<<RegisterWithDotnetSuggest>b__17_0>d.MoveNext() in /_/src/System.CommandLine/Invocation/InvocationExtensions.cs:line 359 --- End of stack trace from previous location where exception was thrown --- at System.CommandLine.Invocation.InvocationExtensions.<>c__DisplayClass5_0.<<UseExceptionHandler>b__0>d.MoveNext() in /_/src/System.CommandLine/Invocation

[pieter-venter]

I've done some digging around and will comment here in case someone else runs into the same issue. The --file-option maps to a FileInfo. FileInfo has a constructor that takes one string parameter. This is automatically bound without any custom code. So without providing any parameters, a FileInfo object with a null parameter in the constructor is passed.

Seeing that this is the most basic example provided, perhaps a suggestion is to remove the FileInfo into a different sample so people don't run into this when they first try it out.

Closing this case.

[jonsequitur]

Thanks, @pieter-venter. This is a bug that was introduced by the latest binding changes. I'm looking into it.