Option to no longer suppress TargetInvocationException in AsmBrowser

[maettu-this]

As discussed by mail:

Matthias:

Note that the exception actually is a TargetInvocationException. But for some reason, AsmBrowser.Invoke() (implemented in AsmHelper.cs ~line 1507ff) suppresses this TargetInvocationException and only re-throws the inner TypeLoadException.

Oleg:

As for the second problem "re-throwing an inner exception" it is a deliberate choice. The first exception is a Remoting transport container and it never reflect the nature of the runtime error (thrown by the script). However if it creates problems with troubleshooting then please log a feature request to make it optional.

Rationale for this change request:
Only the original TargetInvocationException contains the stack frame (i.e. code location) where the problem occurs the first time. This piece of information can be very helpful in debugging such issue.

[oleg-shilo]

I think if the objective is to preserve stack trace then probably a better solution would be to keep the current approach but to inject the stack trace into the re-thrown System.Reflection.TargetInvocationException.InnerException.

It seems like it is technically possible.

Working on it...

[oleg-shilo]

Can you please provide a simple test case that shows this problem.

My comment about "re-throwing an inner exception" was about non-hosted script execution and it looks like in hosting scenarios the execution flow is going a different way.

This is the test that I tried:

static void Issue108()
{
    CSScript.CacheEnabled = false;
    CSScript.GlobalSettings.InMemoryAssembly = false;

    try
    {
        var asm = CSScript.CompileCode(@"
                        using System;
                        class Script
                        {
                            static public void Main() { throw new Exception(""test error""); }
                        }");

        using (var scr = new AsmHelper(asm, null, true))
        {
            scr.Invoke("Script.Main", new object[0]);
        }
    }
    catch (Exception e)
    {
        Debug.WriteLine(e);
    }
}

The test above exhibits the behavior that is inconsistent with the one you described:

• The exception is not TargetInvocationException
• The stack trace is fully available

System.Exception: test error

Server stack trace: 
   at (Object , Object[] )
   at CSScriptLibrary.FastInvoker.Invoke(Object instance, Object[] paramters) in E:\...\cs-script\Source\CSScriptLibrary\AsmHelper.cs:line 1738
   at CSScriptLibrary.AsmBrowser.Invoke(Object obj, String methodName, Object[] list) in E:\...\cs-script\Source\CSScriptLibrary\AsmHelper.cs:line 1503
   at CSScriptLibrary.AsmBrowser.Invoke(String methodName, Object[] list) in E:\...\cs-script\Source\CSScriptLibrary\AsmHelper.cs:line 1413
   at CSScriptLibrary.AsmRemoteBrowser.Invoke(String methodName, Object[] list) in E:\...\cs-script\Source\CSScriptLibrary\AsmHelper.cs:line 1265
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at CSScriptLibrary.IAsmBrowser.Invoke(String methodName, Object[] list)
   at CSScriptLibrary.AsmHelper.Invoke(String methodName, Object[] list) in E:\G...\cs-script\Source\CSScriptLibrary\AsmHelper.cs:line 934
   at dynamictest3.Program.Issue108() in E:\...\cs-script\Source\TestPad\Program.cs:line 659

[maettu-this]

See test project attached to #109. It crashes with a TargetInvocationException. Wasn't that easy to condense the issue, but the test project might by quite useful for other/future issues so I have committed the test project to my source code and will make sure it stays available.

[oleg-shilo]

Implemented in b929ed5

[maettu-this]

Thanks for the fix. I quickly looked at it, two typos and a suggestion:

• "accessed form the different AppDomain" --> "...from..."
• SupressUnpackingTargetInvocationExceptions --> "Suppre..."
• Suggesting to prepend "CSScript_" to the environment variable name, as kind of env var namespace indication.

[oleg-shilo]

Of course. Txs. :)
I was in a real hurry.
Though I am not going to re-release as functionality is not affected by these typos.

[maettu-this]

Of course, no need to re-release. Works fine now and changing it for the next release will not break anything.

[oleg-shilo]

Fixed in https://github.com/oleg-shilo/cs-script/releases/tag/v3.28.3.0