Error when methods are in-lined about powerargs HOT 11 CLOSED

Thanks for the detailed investigation here.

I am familiar with CallerMemberName, but I don't want to upgrade to 4.5 unless I really have to so that more programs can use the library.

I might have to go with the compiler hint attribute as you've described.

from powerargs.

fixed

from powerargs.

Hi adamabdelhamed,

The current master branch (2.0.6.1) doesn't seem to have this fix. Where I can get latest sources (2.1.2-pre) for compiling it myself?

Kind regards,
Olli-Pekka Isola

from powerargs.

Hi Olli-Pekka,

The very latest sources are in a branch called usage, but the main branch should have this fix. I just took a look and I can see the MethodImpl attributes (see line 108 here https://github.com/adamabdelhamed/PowerArgs/blob/master/PowerArgs/ArgDefinition/CommandLineArgument.cs as an example).

Can you please share more details on what unexpected behavior you are seeing? That may help me figure out what's going wrong.

Thanks,
Adam

from powerargs.

Adam,

This is the short version:

A) Compilation

1. Downloaded version 2.0.6.1 from GitHub with "Download ZIP" button
2. Opened PowerArgs.sln with Microsoft Visual Studio 2013 Premium (RTM)
3. Changed PowerArgs project properties
   • Target framework: .NET Framework 4 --> .NET Framework 4 Client Profile
   • Platform target: Any CPU --> x64
4. Hit BUILD | Build PowerArgs

B) Deployment

1. Created VB.NET Console Application
2. Added reference to PowerArgs.dll
3. Wrote Main function and argument classes
4. Compiled application
5. Tested with some arguments

If you prefer the longer version, I can provide zip files containing the changed (as described above) .csproj file and the whole test project I made for the evaluation (part B).

Kind regards,
Olli-Pekka

from powerargs.

I just removed the feature that uses the stack frame so this should not happen anymore. It's in the master branch.

from powerargs.

I just ran into this when I added an 'arguments' class for a new action method for my CLI program.

I cloned the PowerArgs Git repo and built the Visual Studio solution successfully.

In the Visual Studio solution for my CLI program, I removed the PowerArgs NuGet package (the latest version on NuGet), and then added a copy of the PowerArgs build output assembly as a project reference.

I'm trying to run a Debug build of my CLI program.

The exceptions I'm observing do seem to be being thrown from a different location – PowerArgs.CommandLineArgumentsDefinition.ValidateArguments(IEnumerable<CommandLineArgument> arguments).

Any ideas on I how I can workaround this?

I'm also happy to help debug this as well as submit a patch or PR if you can point me in the direction of a fix.

from powerargs.

The issue you've commented on was completely fixed. The code no longer relies on a stack trace to do what it needs to do.

What specific error are you seeing?

from powerargs.

@adamabdelhamed Here are the details of the exception that's being thrown now:

System.Reflection.TargetInvocationException was unhandled
  HResult=-2146232828
  Message=Exception has been thrown by the target of an invocation.
  Source=mscorlib
  StackTrace:
       at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
       at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
       at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
       at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
       at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
       at PowerArgs.CommandLineArgumentsDefinition.ValidateArguments(IEnumerable`1 arguments) in C:\@GitHub\PowerArgs\PowerArgs\ArgDefinition\CommandLineArgumentsDefinition.cs:line 672
       at PowerArgs.CommandLineArgumentsDefinition.Validate(HookContext context) in C:\@GitHub\PowerArgs\PowerArgs\ArgDefinition\CommandLineArgumentsDefinition.cs:line 543
       at PowerArgs.Args.ParseInternal(CommandLineArgumentsDefinition definition, String[] input) in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 554
       at PowerArgs.Args.<>c__DisplayClass15_1.<InvokeAction>b__3() in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 245
       at PowerArgs.Args.Execute[T](Func`1 argsProcessingCode) in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 461
       at PowerArgs.Args.<>c__DisplayClass15_0.<InvokeAction>b__2(String[] a) in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 242
       at PowerArgs.REPL.DriveREPL[T](TabCompletion t, Func`2 eval, String[] args) in C:\@GitHub\PowerArgs\PowerArgs\HelperTypesInternal\REPL.cs:line 28
       at PowerArgs.Args.InvokeAction(CommandLineArgumentsDefinition definition, String[] args) in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 240
       at PowerArgs.Args.InvokeAction[T](String[] args) in C:\@GitHub\PowerArgs\PowerArgs\Args.cs:line 417
       at DbNecromancer.Cli.Program.Main(String[] args) in c:\@Kiln\DB Necromancer - CLI\DbNecromancer.Cli\Program.cs:line 18
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: System.NullReferenceException
       HResult=-2147467261
       Message=Object reference not set to an instance of an object.
       Source=PowerArgs
       StackTrace:
            at PowerArgs.AttrOverride.Get[T1,T2](String propertyName, IEnumerable`1 attriibutes, Func`2 getter, T2 defaultValue) in C:\@GitHub\PowerArgs\PowerArgs\HelperTypesInternal\AttrOverride.cs:line 50
            at PowerArgs.CommandLineArgument.get_DefaultValue() in C:\@GitHub\PowerArgs\PowerArgs\ArgDefinition\CommandLineArgument.cs:line 265
            at PowerArgs.CommandLineArgument.get_HasDefaultValue() in C:\@GitHub\PowerArgs\PowerArgs\ArgDefinition\CommandLineArgument.cs:line 254
       InnerException: 

I'm using the output of a local build of the master branch of this repo as-of Friday. I built the Debug configuration for the Mixed Platforms 'solution platform'.

Here's the line that's throwing the exception.

from powerargs.

This appears to be a different issue than the one this thread was originally referring to.

The line that actually throws is this one. I think the only way that line can throw is if your application code tried to programatically override something like a description or default value property with a null. That should not be allowed, and in an upcoming check in I'll throw sooner when that happens.

I know I've been slow to respond (sorry), but can you recall if you did set an override to null somewhere?

It would be something like someArgument.Description = null; where someArgument is of type CommandLineArgumentDefinition.

Thanks,
Adam

from powerargs.

@adamabdelhamed Thanks for following-up! Unfortunately, I don't have a copy of the code for which the exception was being thrown. But that code very well may have been assigning null to the default value of one of the arguments.

from powerargs.