Skip to main content
Home Forums Silverlight Programming Visual Studio & Silverlight Development Tools Breakpoints can not be reached at random times
16 replies. Latest Post by gixmi on June 28, 2009.
(0)
Grahf
Member
13 points
21 Posts
06-07-2009 8:54 PM |
I am having a lot of trouble with not always being able to reach breakpoints in my Silverlight application. I will run the app and the breakpoints will be reached, the next time they won't, the next 2 times they will, the next 5 times they won't, ect. I have no idea what is going on. I notice my Silverlight app is not in the modules when it cannot reach the breakpoint, but why is it sometimes not in the modules? My Silverlight app is hosted in an asp.net application project which is set as the startup project. When I first ran the project I clicked enable debugging.
mrjvdveen
Participant
1749 points
331 Posts
06-08-2009 3:04 AM |
Maybe a dumb question, but do you switch between debug and release modes?
06-08-2009 8:27 AM |
Nope I am using debug the whole time.
06-08-2009 9:41 AM |
Do you use the ASP.NET Development Server as your debugging webserver or do you use IIS?
ksleung
Contributor
5198 points
993 Posts
06-08-2009 1:00 PM |
One possibility... please make sure that the version in the debugger is EXACTLY the same as the one deployed. It could have been cached by the browser or the server or the wrong version was uploaded. At one point of my development I got fed up with this (debugging phantom bugs or breakpoints never hit) I added a post-build action to put the build timestamp into the XAP (write a simple script to get the timestamp, use 7zip to stuff the timestamp as a file into the XAP) and display it prominently in the SL application.
06-08-2009 8:29 PM |
I am using the asp.net development server. Not IIS. I thought that perhaps the version in the debugger was not the right version, but I deleted the browsers temporary files and that did not help. I build my solution before I run the debugger so I thought that would make my asp.net application get a new XAP. can run it, make a change, then run it again. The change will be shown, but I still can't hit a breakpoint.
06-09-2009 1:46 AM |
One question, when you say your breakpoint is never hit, do you mean:
(1) you were able to set breakpoint (solid red in VS2008), but you never get there?
(2) when you set breakpoint, the breakpoint shows up as a hollow red circle, meaning that the debugger makes a note that you want a breakpoint at this location, but it was not able to find the corresponding point in the code?
06-09-2009 2:32 AM |
One thing I made into a habbit sinse .NET 1.1 is to always use the Rebuild options instead of the build options. I never have issues with brakepoints in Silverlight 2. I do sometimes have them in my services, but I deploy these to IIS, to make my life a lot easier in other areas. Whenever I run into an issue there, I simply run Clean Solution and then Rebuild Solution and redeploy my service to IIS and everything workes as expected.
06-09-2009 8:31 AM |
Number 2 the breakpoint is a hollow red circle. Rebuild did work. After working with it today I will let you know if it works all the time.
06-09-2009 1:09 PM |
My experience has been that whenever I get the hollow red circle, there is a discrepancy between the version seen by Visual Studio and the XAP you are trying to debug.
06-13-2009 1:47 PM |
Sadly rebuild does not always work. The .xap file in my client bin has a modified date of 2 min ago and I have not made any changes since, yet it still has hollow red circles. Building doesn't seem to change anything. It seems no matter what I do I can't get the breakpoints to be hit, then randomly once in a while it actually works. Anybody have any other ideas?
06-22-2009 10:46 PM |
I changed to using Internet Explorer to test instead of Google chrome and I can now hit my break points. Something with Google Chrome was causing me to not be able to do so sometimes. I do not yet know what the problem with Google chrome was.
alok572
334 points
63 Posts
06-23-2009 12:49 AM |
Hi Grahf,
It is a silverlight problem or bug(as most people prefer). It is due to some errors in your current code. I used to face the same problem and my guess is that it is caused due to the fact that silverlight stores its solution in the cache and hence it refers to the previous solution in case of any errors in the current solution.
The solution is to clean the solution or Rebuild the solution/project.
Mark as answer if i've helped you...
06-23-2009 2:26 AM |
Sounds to me like there is a bug in the Chrome / Silverlight interaction (maybe a deliberate Google action?).
06-23-2009 8:44 AM |
Alok I rebuilt/cleaned the code many times, but it did not help. I am curious if anyone else has tried using Google Chrome and what their results are.
06-24-2009 2:09 AM |
I have been burnt by this issue enough times that I came up with a solution so that I'll never had to second guess the built time of the Xap. It comprises of the following steps:
(1) in the post-build action (run under the condition "When the build updates the project output"), I wrote a script to read the timestamp of the Xap and save it to a temp file called Timestamp.txt, and then use 7zip to add the file to the Xap. The 7zip command is
7zip -tzip a App.xap Timestamp.txt
(2) at the startup of the Xap, I read the content of Timestamp.txt by:
System.Windows.Resources.StreamResourceInfo sri = Application.GetResourceStream( new Uri(url, UriKind.Relative));System.IO.StreamReader stream_reader = new System.IO.StreamReader(sri.Stream);string timestamp = stream_reader.ReadToEnd();
(3) In debug mode, display such timestamp prominently at the upper-right corner of my Silverlight application.
This way, there is no way you'd get confused whether you are really debugging the same Xap that you just compiled. You'd just know, by looking at the timestamp.
Seems like a lot of work, but it's worth it.
gixmi
2 points
1 Posts
06-28-2009 3:41 AM |
I deploy these to IIS, to make my life a lot easier in other areas. Whenever I run into an issue there, I simply run Clean Solution and then Rebuild.
Breakpoints can not be reached at random times