Ambiguous call in dbg.inject<ID>

[maettu-this]

While trying to compose a test script environment related to #71 I ran into this issue:

<Workspace>\CSScript\Issue #79\Redirect>cscs.exe -cd RedirectRefLib.cs
C# Script execution engine. Version 3.27.0.0.
Copyright (C) 2004-2017 Oleg Shilo.

Error: Specified file could not be compiled.

csscript.CompilerException: c:\Users\klaey-1\AppData\Local\Temp\CSSCRIPT\Cache\dbg.inject.-110101375
1.cs(13,16): error CS0121: The call is ambiguous between the following methods or properties: 'dbg_e
xtensions.print<T>(T, params object[])' and 'dbg_extensions.print<T>(T, params object[])'

   at csscript.CSExecutor.ProcessCompilingResult(CompilerResults results, CompilerParameters compile
rParams, ScriptParser parser, String scriptFileName, String assemblyFileName, String[] additionalDep
endencies)
   at csscript.CSExecutor.Compile(String scriptFileName)
   at csscript.CSExecutor.ExecuteImpl()

<Workspace>\CSScript\Issue #79\Redirect>

Can be reproduced by extracting the attached files into a temporary location, place cscs.exe into the \Redirect folder and run cscs.exe -cd RedirectRefLib.cs.

Issue #79.zip

[oleg-shilo]

The cause of the problem is the fact that in your test the referenced assemblies are compiled with the EnableDbgPrint set to true (default). This in turn creates an assembly collision that typically needs to be resolved with asm aliases or by disabling DbgPrint.

This is expected compiling behavior but not expected user experience. I have already identified the measures to fix in the the next release:

• Reworking injectable dbg.cs to avoid premature reference to dbg.print(). This will solve 95% of problems.
• Ability to switch off DbgPrint per script. It is currently global.
• Dedicated error message with the explanation how to fix from user code for the cases when user invoks dbg.print().

Until it's done please disable debug printing system wide:

cscs -config:set:EnableDbgPrint=false

[maettu-this]

I see. Wouldn't it be safer if DbgPrint was disabled by default? After all, a user could implement his own DbgPrint leading to a naming conflict. And also, .NET already provides Debug.Write* and Trace.Write* so I'd rather expect that users primarily make use of the .NET integrated functionality.

[oleg-shilo]

And also, .NET already provides Debug.Write* and Trace.Write* so I'd rather expect that users primarily make use of the .NET integrated functionality.

DbgPrint is not that superficial as one may think. It is miles ahead of Debug.Write* and Trace.Write*. It is more like Python's print(). It serializes objects into JSON like string and prints it out in as well formatted text.

Wouldn't it be safer if DbgPrint was disabled by default?

I was tossing for quite some time about this one. :) No it wouldn't be safer. It would be exactly as safe. The code below illustrates the issue:

// scriptA.dll
static class Extensions
{
    public static void print(this object obj) {...}
}

// scriptB.dll
static class Extensions
{
    public static void print(this object obj) {...}
} 

// master_script.cs
void main()
{
    "test".print();
}

If the master script does not make print() call then it is 100% safe and no naming conflict is possible even theoretically.

For example with the fix that I committed 2 days ago your code sample will not need any change at all. You don't need to touch DbgPrint despite the fact that it will be enabled.

However if the master script calls print() then having DbgPrint disabled would 100% fail to address the naming conflict and instead produce compiling error. The user will need to implement his own extensions in either case (compiling error or naming conflict). Or completely give up the print() extensions. Thus changing DbgPrint default value will not bring any practical benefit. This is why I decided to keep DbgPrint enabled so it is convenient for at least simple scripting cases.

[oleg-shilo]

One point I forgot to make...

The earlier release you used for testing caused the conflict not because DbgPrint was enabled but because of the mistake in dbg.cs, which is fixed now. And I advised you to disable DbgPrint only as a temporary measure until you get the new cscs.exe

[maettu-this]

Verified with 3.27.1, no error message anymore.

[oleg-shilo]

Thank you. Closing it now.