Go Back

Why Does GENNET40 (.NET to Synergy Interop Generator) Generate a .NODEBUG for Interop Code?

When utilizing GENNET40 (https://www.synergex.com/docs/index.htm#tools/toolsChap4Gennet40utility.htm) 3 distinct files are generally generated as per the documentation (assuming you use interop.dbl as your output name):

  1. interop.dbl
  2. interop.inc
  3. interop1.dbl
interop.dbl is very simple and contains only this:
.include interop1.dbl

According to the documentation for .NODEBUG (https://www.synergex.com/docs/#lrm/lrmChap5NODEBUG.htm) this instructs the compiler to emit code that causes the runtime to be unable to set breakpoints within this code.

What is the design rationale for doing this?

Internally at Computers Unlimited we have several scripts that at a high level simply discards this tool generated interop.dbl and instead opts to use interop1.dbl (renaming it to interop.dbl).

While it is understandable that this is a significant amount of generated code internally when debugging we find it very useful to set breakpoints within the generated code. For example we usually set a breakpoint on the "new DotNetAssembly(string)" call as this (for us) is usually the first time the interop assembly is being invoked. It is often helpful to attach a CLR Debugger right before/shortly after this call. Other times we have set debugging points just prior to the execution of the interop call to ensure that the proper variables are being sent or evaluating their return for error conditions.

Is this bad? If so why?

How are other developers utilizing this API?

Is there a better way?


3 Answers
0   | Posted by Ace Olszowka to Synergy DBL on 8/30/2019 7:50 PM
We added .NODEBUG as you describe because we feel that provides a better debug/stepping experience for the majority of our users. The generated module never has debug information (because it's compiled with -qrelaxed:interop, and we don't include debug info when that's used). We feel that stepping into it doesn’t provide a good user experience (e.g., it’ll say no symbol information) and doesn’t enable you to do much that would be useful. Although you’ve found it useful, we feel most users would not want to step into it.  

We’re definitely open to feedback on this, so if others have input, please share it here or with our Developer Support team. (FYI, the .NODEBUG was added in Synergy/DE 10.3.3d.)


9/19/2019 8:14 PM   1  
Ace Olszowka
Thank you for taking the time to document the design decision!

9/19/2019 8:16 PM   0  
Ace Olszowka
Cross posting an example where setting .NODEBUG in this interop file swallows useful exceptions; not sure whose bug it is but this should be fixed one way or another: https://synergexresourcecenter.force.com/SiteIdea?id=0870d000000bppFAAQ see the comment "I should also note that if you remove the .nodebug statement that is helpfully inserted you'll get the actual exception"

6/8/2020 11:51 PM   0  
Please log in to comment or answer this question.