How to debug in VS instead of JIT Debugger?

UPDATE: navigating to the process via menu:DEBUG / Attach Process / iexplore.exe shows "Automatic: Silverlight code". i.e. VS 2010 already attached to the process. Why doesn't it go to debug view?

I have a frustrating debug behaviour going on on my laptop which I'd like to fix. I was following along with the demo called Silverlight TV 46: What's Wrong with my WCF Service?

On my computer, I noticed that putting throw new ArithmeticException() in the RIA service causes the just-in-time debugger to get involved (a bad thing -- I want VS). I can put a break point on the the throw new ArithmeticExpression() line, and VS stops as it normally does. Press F10, and I still get the just-in-time debugger kicking in.

On Yvor's computer (the presenter in the Ch 8 link above), the visual studio debugger kicks in instead of the just-in-time one. What am I doing wrong? Could having Redgate Reflector installed previously have caused this (it is gone now).

ERROR: Visual Studio Just-In-Time Debugger Code: 4004 Category: ManagedRuntimeError Message: System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.

开发者_运维技巧

Check ...

Possible Debuggers:

New instance of MS VS 2010, 
New instance of VS 2008.  

• [checked] Set currently selected debugger as the default.

• [unchecked] Manually choose the debugging engines

• Action: Hit Yes.

2nd ERROR:

Unable to attach to the crashing process. A debugger is already attached.

I've spent several hours looking for a way to solve this.

Browser is IE9 / Silverlight 4.

Previously, I started starting the silverlight app directly via the VS2010 environment... but then decided to get more deployment compliant (again).

http://msdn.microsoft.com/en-us/library/cc838267(VS.95).aspx

Down the bottom they mention repairing from control panel / VS2010. Did that. Waited for ages, made coffee, did something else. Finally complete. Problem sill there. Included this step just-in-case the fix is cumulative (you get superstitious after a while with these things).

I then deleted zap files, switched startup page from html to the aspx one. Wired aspx to the xap (it wasn't pointing to the /debug/ folder). [note: looks like you can remove the debug via Silverlight Project / build / Output path: Replace Bin\Debug\ with Bin. With Silverlight I feel that the relative Uri path should match up to your html / aspx files no matter what -- wheather you are in Debug or Release.

project properties / Web / Specific Page

debugging works again!

Did .html stop debugging? Casual inspection reveals the same javascript stuff firing up Silverlight. On the surface it looks the same. hmmm. I guess it isn't.

... here are a few extra things to look at for those who still have issues (I may as well list them while they are fresh in my mind).

1. project / properties / Web / Debuggers: I now only have Silverlight checked. ASP.Net is not checked any more. (Not sure if this influences my result at this stage)

2. make sure your web project points to the silverlight project in project / properties / Silverlight Applications. This ensures that the silverlight project's binary "xap" is copied to a folder within the Web Site / Web App. Note: hitting the add button reveals a destination folder (should be ClientBin).

Your build configuration will add an additional sub foler e.g. debug.
Make sure your .aspx or .html files have the right path. For me, I just included the .ClientBin/debug/ folder. I don't think this is deploy friendly, so I will search for a better way later.

1. IE9 settings.

[X] Disable script debugging.

[X] Disable script debugging (Other)

[ ] Display notification about a script error

[ ] Show friendly HTTP error message

Again, unsure if these later setting have an impact.

Lastly, there's something that I forget about sometimes. Be sure to check Debug VS2010 / Exceptions / Common language Runtime. This ups the ability to catch exceptions.

I had a similar problem, but the above did not resolve it. However, starting the application without debugging (Ctrl-F5) and triggering the exception would allow me to select the Visual Studio instance that I started the application from. Amazingly, I got a sensible stack trace and resolve the problem within a few minutes.