Silverlight Breakpoint Debugging

Silverlight programs often encounter situations where they cannot be debugged, and the solution is summarized below.

First, the problem description

During the Silverlight development process, there are often problems with Silverlight that cannot be debugged. Here are a few things:

1. The Web Application+silverlight,f5 cannot follow the breakpoints in the Silverlight program after it enters the debug state;

2. There are two Silverlight projects in the project, and one of the Silverlight programs has a mouse click event that navigates the current page to the hosting page of another Silverlight program. The first Silverlight program breakpoint is normal, but a breakpoint in the second Silverlight program does not automatically stop;

3. Whether debugging in Testpage mode or on a Web project, as soon as the Silverlight debug switch is turned on, the boot will prompt "Unable to start debugging. Cannot locate Microsoft Internet Explorer. If you are running directly ctrl+f5, the same problem sometimes arises.

1. A single Silverlight project cannot be debugged

For the first question, verify that the following settings are correct:

(1) Verify that Silverlight debugging is enabled . Open the Property settings page, find "Web", find "debugger" at the bottom of this page, for example, confirm that "Silverlight" is checked:

　　

(2) ensure that the XAP package accessed by the browser is newly compiled . The simplest approach is to force rebuild the entire Silverlight project, emptying the cache. If not, then check that the XAP in ClientBin is not updated for some reason (such as the inability to overwrite because of a read-only attribute).

(3) Check that the ASP. NET project is bound to a Silverlight application . You can see whether the bindings were successful through the Silverlight application page in the Properties panel of the ASP. As follows:

　　

(4). Check that the startupobject of the Silverlight project is set correctly . renaming a project's namespace causes the entry object of the Silverlight application to fail, which can result in situations such as a failure to start.

　　

Two, IE8 can not debug multiple Silverlight projects at the same time

IE8 and the previous IE is not much the same, its multi-label is a multi-process approach to achieve. The entire window is a framework process, and each tab tab is a separate subprocess (in fact, IE8 dynamically controls the number of tab processes based on memory, so multiple tabs may coexist in the same process). When you try to open a different Silverlight application in multiple tabs, such as opening a new page from SilverlightApplication1 to the SilverlightApplication2 page, you will find that The SilverlightApplication2 application cannot be debugged.

This is becauseVisual Studio does not automatically help us attach other processes that contain Silverlight applications in addition to launching window processes. If we need to debug different Silverlight applications at the same time on multiple tabs (or multiple Windows), then we have to manually attach these processes ourselves .

For a simple example, I have two Silverlight projects, where SilverlightApplication1 contains links to SilverlightApplication2 pages, Clicking on the link will open the SilverlightApplication2 hosting page in the New tab page.

In order to attach the corresponding process, first we need to find SilverlightApplication2 hosting the corresponding process of the page. Open Processexplorer, we can see three processes.

The ID of 4528 is the parent process, the framework process, which manages transactions between different label processes. 5160 and 5248 correspond to two tab processes respectively. As to which one corresponds to which we cannot determine according to the process number.

Let's open the Attach window in Visual Studio (menu =>debug=>attach to process ...). ）

Here is a list of all the processes available to the system, and we can see three IE processes, one of which is grayed out, which means that the process has been attach to the debugger of Visual Studio. Excluding the framework process 4258, there are 5248 of this process, and this process is what we are looking for SilverlightApplication2 corresponding to the process of hosting the page. When selected, attach to the debugger, we find that the breakpoint in SilverlightApplication2 is still shown as a hollow red circle and still cannot be debugged.

This is because the process code we specified is not of the correct type. We notice that there is a attach to on the top, and that the automatic, which represents the debugger for Visual Studio, automatically helps us select the debug type of the process, such as managed code debugging, script debugging, and so on. We checked the 5248 process and found that the way Visual Studio chose us was script debugging.

In Visual Studio, script debugging and Silverlight debugging cannot coexist, which is why sometimes when you press F5, Visual Studio prompts you to debug the Silverlight program to temporarily turn off the functionality of script debugging. Therefore, under script debugging, we cannot follow the breakpoints of the Silverlight application.

Here's an extra point, IE8. Disabling script debugging settings in Advanced options does not affect Visual Studio at all, because Visual Studio 2008 automatically enables script debugging when the debugger starts (this feature can be disabled through the registry) unless the Web Silverlight debugging is turned on in the Application property.

Back to the question just now, because Visual Studio helped us choose the wrong debug type, which prevented us from debugging SilverlightApplication2, we need to manually specify the attach type. Click the Select button on the attach to back side.

In the pop-up Select Code Type window, tick on Silverlight. OK then again attach, we found that this time, the breakpoint really worked.

Of course, if this is a hassle, we can also make different tabs coexist in a process by changing the way IE8 tab processes are created. Under registry HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main, there is a Tabprocgrowth key value (DWORD type), and when it is set to 0 o'clock, IE frame and tab work in a Process, tab is created by thread, and IE's protected mode (Protect modes) is turned off. Tabprocgrowth=1 when IE frame and tab work in different processes. Tabprocgrowth>1, this value determines the maximum number of tab processes created by IE8. If Tabprocgrowth does not exist, the number of tab processes is determined based on the amount of physical memory available.

Problems with IE Windows cannot be opened while debugging

This is the problem I recently met, I do not know why suddenly, my Silverlight project Press F5 the time can not debug, pop up the following dialog box: Unable to start debugging. Cannot locate Microsoft Internet Explorer.

If you run directly, you can open it, but Visual Studio will pop up the same error after it is opened.

This question has been tossing me for a while, I tried restarting the computer, reloading Silverlight Tools, creating a clean test project, modifying the system and the default browser of Visual Studio (note that the system and Visual Studio default browsers are set independently) all failed. Google for a long time, the Silverlight official forum There are a lot of posts and this related, but I looked carefully and found that no reply can solve my problem. There's a guy on the post. The problem is solved, but not how to solve the said on the run, a strong BS this kind of people!

In the end, how do I solve this problem, is to use the Process Monitor this gadget (Microsoft Sysinternal honor!) ）。 One time ago, a "file does not exist" HttpException appeared in the Globalerror of ASP. Later, using this tool to monitor the WebDevServ.exe process, it was discovered that the process attempted to access a nonexistent file.

Process Monitor, which can monitor the activity of all the processes in the current system, including the operation of the file system, read and write the registry, network access and thread activity, etc., very useful debugging maintenance tools.

I opened this tool and chose to monitor the process for devenv.exe. In Visual Studio F5 start debugging, immediately pop up the error dialog box, OK, the PM paused, otherwise there are too many entries.

But the event entry is still too much, so I filtered the result to Success's entry because we only focused on the failed entries.

Then the log entries are carefully checked, and finally found the source of the problem:

It turns out that Visual Studio reads Hklm\software\microsoft\windows\currentversion\app Paths\ in the registry when debugging or running. The Iexplore.exe item is then not read and the error is reported. No wonder prompted cannot locate Microsoft Internet Explorer.

I open regedit Registry Editor, find this path, and then add the missing items up, back to Visual Studio F5, finally can, inside the cow face ~

Hope my solution can give you some inspiration, after encountering similar inexplicable problems, you can think of using PM this tool to troubleshoot problems.

Update: Updated the workaround for the new symptom (F5 cannot locate Microsoft Internet Explorer dialog box when debugging).

When you find that the browse mode in VS is set to IE, the Silverlight program can directly hit the breakpoint. If the browse mode in VS is set to Chorme, you must manually attach the debugger to the Chorme process when you debug the Silverlight program, or the breakpoint cannot be reached. Debug- > Attach to process--process list Select the Chorme process (the type is the Silverlight x86), click Attach, Refresh the Chorme page, the breakpoint can be hit.

Chorme each time you start debugging need to manually attach the debugger, more trouble, it is recommended to debug the Silverlight program when using IE browser.

Silverlight Breakpoint Debugging