Feed Icon  

Contact

  • Bryant Likes
  • Send mail to the author(s) E-mail
  • twitter
  • View Bryant Likes's profile on LinkedIn
  • del.icio.us
Get Microsoft Silverlight
by clicking "Install Microsoft Silverlight" you accept the
Silverlight license agreement

Hosting By

Hot Topics

Tags

Open Source Projects

Archives

Ads

Debugging a Remotely Hosted Silverlight App

Posted in Silverlight | Visual Studio at Tuesday, 10 March 2009 03:32 Pacific Standard Time

This question has come up in the forums a few times so I thought it would be worth a blog post. Most people are pretty familiar with debugging a Silverlight application running locally during development, but what people many times don’t realize is that you can also attach your debugger to a xap file that is hosted remotely. This MSDN article touches on this briefly, but doesn’t really go into details on how it works.

The important thing to understand about Silverlight is that it runs the .NET code on the client machine, not on the server. The code runs in the browser process, so if you’re going to debug it you need to attach to that process. The one caveat is that the xap on the server must be the same as the compiled xap on your development machine. In other words, you can’t debug the remote xap after you’ve made changes locally and haven’t deployed them.

As an example I will demonstrate remotely debugging the Twilight badge on my blog.

First I open the Twilight.sln and since I’ve made a few changes in the last week I’ll deploy the latest xap file from my project to my server at http://blogs.sqlxml.org/wpfe/twilight.xap.

Next, now that I am sure the xap file on the server has the same code as my solution, I can set a breakpoint on Line 36 (using version 1.5.2) where the Twitter javascript callback calls into Silverlight with the latest list of tweets:

image 

Now instead of hitting F5 to start debugging my application, I’ll open a new instance of Internet Explorer (or you could use Firefox to debug that as well) and navigate to my blog since that is where the xap shows up. Back in Visual Studio I click Debug –> Attach to Process and select the iexplore.exe process which is Internet Explorer (or firefox.exe if you’re debugging Firefox).

NOTE: Make sure you click highlight iexplore.exe or firefox.exe and then click the Select button and choose Silverlight as the type of code you wish to debug.

image

 

 

Once I click attach I can go back to my Internet Explorer window and hit refresh to force the breakpoint to get hit. If everything was setup correctly you should get taken back to Visual Studio where your breakpoint is highlighted and you can now step through your Silverlight code.

image

So why is this useful? Well a lot can change in your application when you start hosting it on a real server instead of in your localhost. For one, you now have to access services running on the server and you are subject to a lot more security checks that were ignored on your localhost. So I find this to be a useful tool for troubleshooting things when they work locally but break once I deploy out to a server.

One last thing, you can also set this up to remotely debug code running on the Mac.

Wednesday, 11 March 2009 22:26:42 (Pacific Standard Time, UTC-08:00)
Another way I have found which I believe to be very useful when simulating a more lifelike deployment is the following:

Install Apache
in the htdocs directory put your TestPage.html or whatever you use to instantiate your silverlight app.

Set up your visual studio application to have a post build step to copy the xap file to the Apache htdocs directory.

Create a simple .html file in your project called Redirect.html that contains something like the following:

<html >
<head>
<meta http-equiv="REFRESH" content="0;url=http://your hostname/TestPage.html">
</head>
<body>
</body>
</html>

Change the debug settings of your project to Start a specific page of Redirect.html.

After a build your .xap file will be deployed to Apache. Redirect.html will be loaded and will then redirect straight to your real test page. You can then debug as required and run in an environment similiar to a real web deployment.

Andy


Andrew Westacott
Comments are closed.