I have downloaded the CSLA source (latest version) and I can debug through the SimpleApp sample on the Silverlight side, but I can't get the debugger to break in the WcfPortal code or the CustomerEdit DataPortal_Insert() method. I know that code is being executed because if I add an exception throw in DataPortal_Insert, the exception is displayed in the UI (with an incomplete stack trace - I can't determine how the stack trace is getting truncated).
In general, I am having trouble understanding what magic happens between the SaveButton in Page.xaml on the Silverlight side and the DataPortal_Insert method on the WCF side. The deepest I can get in the debugger is the BeginUpdate method in WcfPortalClientChannel in the autogenerated Reference.cs proxy code.
I have written other XAML code that is not hitting the DataPortal_* methods on the WCF side and I'd like to at least be able to debug through and see how the "resolver" determines which DataPortal_* method to call and why if the proper method doesn't exist it appears as if no error gets thrown to understand what is going wrong.
If you have the SL and web projects in the same solution, the debugger should "just work".
It is possible the client call never reaches the server though (maybe a mis-matched URL in the client config?), and of course then the server code would never break in the debugger because it would never run at all.
That's the most likely reason the debugger doesn't break in the server code.
If the save fails, the error should roll up to the OnError method in the viewmodel though, so you should see the exception.
I figured this out, mostly by finding a different CSLA sample where I could debug the WCF code and then guessing at what was different between the two projects.
I re-extracted SimpleApp from the sample zip and started over. The startup project was set to SimpleApp by default (the Silverlight project). Running that gives this error:
---------------------------
An error occurred while trying to make a request to URI 'http://localhost:1993/WcfPortal.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
---------------------------
I "fixed" this issue originally by creating CrossDomain.xml and ClientAccessPolicy.xml files. Apparently, that is not the correct way to solve the problem.
The correct way is to set the startup project to SimpleApp.Web and the startup page to SimpleAppTestPage.html. Then debugging works as I want it to.
The truncated stack trace in the exception issue remains, but now that I can debug properly, I may be able to figure that one out.
Thanks for saying that it should work so I was motivated to beat my head against it some more.
Yes, this is perhaps the most common issue with Silverlight apps, and I'm sorry I didnt' think to suggest it.
For some reason, Silverlight solutions don't remember the correct startup project - apparently that isn't stored in the sln file or something.
So when a SL solution is opened by each new VS environment, the default startup app switches to the SL project, not the web project.
The crossdomain file will get the app working, but won't force the debugger to attach correctly to the web app.
Copyright (c) Marimer LLC