Help - Cannot Debug Csla 3.6 - Debugger just ends

Help - Cannot Debug Csla 3.6 - Debugger just ends

Old forum URL: forums.lhotka.net/forums/t/5442.aspx


stefan posted on Monday, September 22, 2008

I am struggling with this issue for nearly two weeks now, with no result Sad [:(]
I am using clsa 3.6.x, compiled from the svn checkout.
I am having trouble with fetching an object that uses the new PropertyInfo features.
I have a mixture of  properties that have a local backing field, as well as properties thast are
completely managed.
I also use the ChildDataPortal.

When I run the application, I am getting an (expected) IndexOutOfRangeException from one of Child_Fetch methods,
because there is a DataReader that is looking for a fieldname that is not included in the stored procedures' result set.

As soon as I set a breakpoint, the application (the debugger) crashes when processing Csla framework code with no messages!

SimpleDataPortal.cs
   
    public DataPortalResult Fetch(Type objectType, object criteria, DataPortalContext context)
    {
      LateBoundObject obj = null;
      IDataPortalTarget target = null;
      var eventArgs = new DataPortalEventArgs(context, objectType, DataPortalOperations.Fetch);
      try
      {
        // create an instance of the business object.
        obj = new LateBoundObject(objectType);

        target = obj.Instance as IDataPortalTarget;
      ...

When I debug step by step, I can reach the line indicated above.
But after a short period of about 3-4 seconds, the debugger just ends.
Stepping in results in a message saying that the debugger can not continue debugging.

What is this?
Having no breakpoints, the code just 'runs through' ...
Is this a result of the new dynamic code invocation, that is replacing reflection?

Stefan

rsbaker0 replied on Monday, September 22, 2008

This usually happens when you have a stack overflow.

Try changing the Exception handling setting in the debugger to "Thrown" versus just "Unhandled" for .NET runtime exceptions.

Sometimes, the debugger will try to evaluate your properties even though you didn't call them explicitly in your code. If you get a stack overflow in that case, it's hard to debug.

stefan replied on Tuesday, September 23, 2008

Thanks, but that didn't bring me any further, same behaviour.

I configured the debugger to show the disassembly when no source is available.
When I let the debugger run through (F5), he appears to reach a point where he is unable to
locate the underlying source code. What is strange is that he is telling me that he is missing the source
for my own class...

Disassembly:
MyApp.Library.MyBusinessClass.DataPortal_Fetch
"Cannot show disassembly. This expression has not yet been translated into system-specific computercode"

I translated the text in bold style from german, I hope it resembles the English version...
That really sounds strange to me Surprise [:O]


I am considering a reinstall of Visual Studio this afternoon... Sad [:(]


Stefan

RockfordLhotka replied on Tuesday, September 23, 2008

Can you try this on a different computer – maybe your VS install is corrupt?

 

Rocky

 

RockfordLhotka replied on Monday, September 22, 2008

I don't know why that would be happening. I've had similar issues in Silverlight, but not on the .NET side. The Silverlight issues are almost certainly due to the beta quality of Silverlight - but you'd hope that .NET 3.5 SP1 (released) would be more stable...

stefan replied on Friday, September 26, 2008

I finally got rid of that annoying debugger thing!
My Visual Studio install was not corrupt -
Tried it on another machine with a virgin VS 2008 SP1 install,
checked out the solution, had to reestablish the corect build order,
refreshed some references, and encountered the same issues there.

The problem was:  I had followed the ProjectTracker(3.6) syntax for all the
GetProperty/SetProperty invocations! This resulted in nearly three weeks of project stagnation Crying [:'(]

Rocky:
I THOUGHT I resolved my problems by just pedantically adding the type parameters to each GetProperty and SetProperty call, just as Intellisense was showing all the time!
Because I could debug again on the new machine!

I don't know why you chose to omit the generic type parameter (Of ....)
 ... maybe just because VS let's us do it.
I assume, once a solution gets more complex (than PTracker anyway), the debugger cannot handle this any more...

My recommendation is as follows: As long as your are calling the strongly typed versions, always invoke GetProperty and SetProperty the generic way!

Going back to my old dev machine, I updated the solution from the repository, and STILL have the issue! What the...

By the way, did you change the default NoAccessBehaviour for the setters to throw an exception?
Maybe it is unchanged from the beginning and I didn't notice.

Stefan

PS: Neat side effect of all this trouble: got rid of my old VS2005 installation, and I have a really good new folder structure for my solution now...

RockfordLhotka replied on Friday, September 26, 2008

I am glad you discovered the source of the issue, though it is unfortunate that you lost so much time.

 

There is a specific and intentional coding change to CSLA .NET in 3.6 that allows the dropping of the generic type parameters on those calls. You can’t drop them in 3.5, but in 3.6 you can allow the compiler to use type inference to determine the type parameter values.

 

Rocky

 

Copyright (c) Marimer LLC