Is it possible to debug both a Silverlight and WCF project at the same time?

Question

I have 3 projects in my solution: 1) A silverlight Application Project 2) ASP.Net Web Application Project 3) A WCF Service Application. Projects 1&2 have a service reference to project 3. The binding type is basicHTTPbinding.

If I set project 2 as the start-up project, I am break points set in both project 1 & 2 are hit, but not break points in project 3.

If I set project 3 as the start-up project, I can still use my client application and break points in project 3 are hit but not the breakpoints in projects 1 & 2.

I would like to be able to set breakpoints in all projects of my solution and have them hit no matter what the select start-up project is. I have tried enabling tracing on the WCF project and including details in the exception; neither have worked. Any advice?

Answer 1

You haven't mentioned unit testing, but if each individual project contains a suite of unit tests, you can be more confident of the individual behavior of each project, and your integration testing would, as a consequence, would be much simpler.

The kind of breakpoint-fix testing you are describing is very difficult in an application with so many moving parts, and it is not repeatable.

Answer 2

Have you checked in the Debug|Attach Processes dialog to see which processes VS has attached to?

I suspect that its not attaching to the development web server running the WCF service. If so having started with the ASP.NET Application try adding an attachment to the other development web service.

Answer 3

Based on your description (and I may be wrong), it sounds like you have at least two different application, i.e., processes. While it's apparently possible to debug multiple processes in a single instance of Visual Studio (see here), it's not something that I've ever done (or even comtemplated for that matter).

I typically run an instance of the debugger for each process I want to debug. An easy way to do this is to put the following line of code in the main startup function for each application:

System.Diagnostics.Debugger.Break();

When you run the application from Windows Explorer, you'll be prompted to select the debugger you want. Just create a new instance of the debugger for each application you want to debug and you can set your breakpoints from there.

Thanks to Peter Oehlert for correcting my original comment.

Answer 4

You can definitely attach to all 3 processes, I am however not certain that the transparent step-into of all 3 will happen.

Use your current setup and then choose Debug->Attach to Process to add your WCF project. At this point, you can try to step-into the WCF service host from either the ASP or Silverlight side and see if it will seamlessly transition. I think there might be a limit of 2 processes for this to work, so if it fails you can set a breakpoint at the interface of your WCF project and when you step-over in the ASP or SL projects your breakpoint will be hit.

Whenever a breakpoint is hit in any of the processes, the debugger will stop all of your processes concurrently. You can migrate through the locations of each process by using Debug-> Windows -> Processes and the Debug -> Windows -> Threads will let you switch threads in each process.

Answer 5

There are a couple ways of doing this.

1) Two instances of Visual Studio open at the same time. There are several other advantages to having your web service and data access in a separate solution. If you do this you can even edit one while the other is running which can help in certain situations.

2) If you have good reasons to have it all in one solution, you can start separate debugging sessions by right clicking on the web service and going to Debug -> Start new instance. Then you can do the same with the web application project. Both will now be running and debugging in the single Visual Studio solution.

However, if both are running inside IIS you will have a conflict when trying to attach two debugging sessions to IIS. Try running one (or both) of them in a local development server. You can fix the IP# of the development server if you need to preserve a service reference.