3
votes

I work on a team building Silverlight apps (version 4). We use SVN and all work on separate parts of the code, and regularly update the project with latest code. The Silverlight app runs from an ASP.NET web app. We are having very frustrating issues when updating our code. It seems like old versions of the XAP are being cached.

Example: Francisco changes the wording of a popup dialog, and commits his changes. A very simple change, what could possibly go wrong? I get the latest code. I see the new code in my IDE (VS2010), and run it. When I view that dialog, it does not have the new wording, even though I can see the new wording in my files. I put a breakpoint on the code right where the change is, but when I run the app, the breakpoint is disabled!

I try Clean build of the Silverlight and the Web host. I kill my local ASP.NET development server. I run the app - same thing! I delete the xap from ClientBin. No good. Each of us on the team are experiencing this issue. Now we occasionally solve it, but are never sure what exactly fixed things, which is not satisfactory.

There must be some setting or something that we are missing. You would think that deleting the ClientBin xap file would solve it, as the new XAP must come from compiling the Silverlight app, right?

If you've seen this problem before and have a real solution, please let me know. (The solution of "format your hard drive and re-install everything" will NOT be accepted!)

Thank you,

Daniel Wiliams

5
What browser are you testing in? Is your web project an App or a Site? Are testing in IIS or with the development server?AnthonyWJones
testing in FireFox 4. Project is an App. Running on Dev server.Daniel Williams
Correction was firefox 3.6 Updated to 4.0 and now debugging works fine. Works in IE9 also, of course.Daniel Williams

5 Answers

6
votes

I recommend that you use IE for Silverlight development. See also this answer.

The problem with using Firefox for development is that Firefox runs plugins in a separate process (plugin-container.exe). When launching the debugger, VS doesn't know that Silverlight won't be running from the process it launched, so it doesn't attach to the correct process. The breakpoints in Silverlight code appear not to work because the VS debugger hasn't attached to any process running the Silverlight code.

I believe it's possible to disable the use of the plugin-container.exe process (see, for example, LIMPET235's post here), but that won't fix the apparent caching you're also experiencing.

I used to use Firefox for Silverlight development, but I found that things worked much more smoothly when I switched to using IE.

1
votes

First of all, could you please check is your .xap file also included into source control? it should not be included..., no need IMHO. Most likely your xap file is set to read only. go to that file location and make ClientBin folder not read only if is.

1
votes

I've seen this before the XAP file is cached. Try emptying your browsers cache and then putting a query string on the XAP. So your XAP reference would look something like Foo.xap?1234

1
votes

couple things to check.

  • Make sure your silverlight project's output path is correct.
  • Make sure your silverlight application has been added to your web app project.
  • Enable silverlight debugging in your web app project.
  • Set the silverlight project as a dependency in your web application's settings
0
votes

The solution of "format your hard drive and re-install everything" will NOT be accepted!

Format your hard drive and install Linux (:

More to the point, configure the Silverlight Applications tab in the SomeSilverlightApp.Web project to copy the xap file from the SomeSilverlightApp project to the ClientBin folder which shows there by default.

The ClientBin folder is also part of the SomeSilverlightApp.Web project in my case and the xap properties are set to CopyToOutputDirectory: Always so that it also gets deployed.

This is probably not the right solution but it works here and I have not time to try to investigate this weird logic.