I have a bunch of DLL’s made with Oxygene, up to 30 larger oxygen source files per DLL, each wearing its own hierarchical name space based on directory strcture and naming like found in Java.
Now I have DLL’s configured for Debugging Any CPU , where I can step into my code routines.
The nromal wanted case.
But sometines doing a step into brings me to wrong places as my break points are not recognised.
Why?
Turning of TOOL / OPTION / DEBUG / Just My Code
allows to break not only at my code and break points set but at break points left in system librarries.
If I disable Just My Code, a step into works my code works fine, but if this is set it does not step into.
That tells me that Oxyge compiler somehow manages to make some of my DLL’s looking like system libraries not wearing the Just My Code attribute.
I have found the articels in MSDN.
It checks for the PDB and sysmbols and vice versa to declare it “Just My Code”
OK
But even with this flag disabled, it does not step into mycode at thes erver. That is to say, for certain routines in certain DLL’s it does and for others it does not.
I have added to all the 4 relevant AssemblyInfo.pas files the following.
{$IFDEF DEBUG}
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations or DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
{$ENDIF}
So in my mind the compiler must now compile for Any CPU and not using optimization and allow for EditAndcontinue; And because this DLL’s are not compiled by a JIT compiler at the server but are delivered as reday to run DLL?s it is only a matter of the debugger used at the server stepping into or not.
And here I have my biggest concerns to what I see so far and that makes me real sad:
a) debugging stepping into, is only part time working
b) hovering over a variable shows a value depending on scope,
c) values for variables defined inside the procedure/functions are shown
d) values for variables of type record/structure at global scope are not shown at all;
e) using this [assembly: . . . as shown above prevents the TypeInitializationException
f) this TypeInitializationException is only seen when the DLL is used at the server and
g) not for all DLL’s but only for DLL’s with to be initialized global variables (ILSpy e all)
ck
thank you.
refering to your statement for my concern
b) hovering over a variable shows a value depending on scope,
your answer:
That makes sense? It only shows variables currently in scope.
So I ask: in which scope are global variables ?
It is about what you say; having a local variable such as defined in a procedure/function and this shows sometimes nil and sometimes a value;
hovering over a global variable, one that is defined in the interface section of a module ending up in a dll, does never show up using a debugger.
However, the code as such works. When I have code accessing this global variable, even complex structures, it deliveris lest say into a collection and when my web service code moves that collection back to the client and unpacking the collection then I can see the value and it is correct.
I ask my self: how can I debug under such circumstances.
I have an IIS running on my lab top but when my client starts up it launches always an ASP.NET Development Server with a random port; and all works fine. Only debugging not as I expect it.
This ASP.NET Deveopment Server is one of 4 posibillities VS offers. And I want to know for shure how I can debug our large web service web site application (which is different from a web application in many regards (i.e. mixed code, vb, c# and oxygene ec.) before I move to an even more complex environment.
(something I did not have much troubles using NetBeans attaching to a remote running JVM, running apache tomcat, running axis2, running our web service java part.
Any hints and clues how to overcome this probabbly MS or setup problem is very welcome.
your last reply: I doubt it’s related to globals themselves.
my asnwer: it is, because when I take out global variable demanding initialization all works and no such exception is raised.
But we have plenty of global variables defined in the interface section of a dll modul, and they demand initialization.
And we need to debug hence we have a problem of the exception raised.
That problem is overcome now when I apply the assembly attribute as you recommended and I changed to
{$IFDEF DEBUG}
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.DisableOptimizations or DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]
{$ENDIF}
because . . .
.DEFAULT enables code optimization of the JIT compiler and disables Edit and Continue. That’s why I used a sligthly different set of attribute bits and or’ed them together as shown.
The unpleasant thing is I have to do that for each assembly and we have quite a few of them. The good thing is it is embedded into a condition active when I build for a debug configuration and gets still deactivated when I do a release build.
So what remains our most hot potato is: hovering over global variables of very complex record structure with the debugger in our web site web service projects global dll code.
Oke we’re redoing the debug evaluator for all platforms to have the same level of support there, but obviously that’s going to take a bit of time. As a workaround you could for now use the full name in the watches screen:
Say the global abc in the Toolbox namespace, you’d write:
Toolbox.__Global.abc
that should work (if not I’ll look into a quick fix for that)