RE: Refreshing an SL4 app (client problem?)
I have used this approach too. I actually have a Build.txt in the root of the application, and set the build number in the web.config and I use: App.xap?v=2.0.0.1 The query string difference is also enough to invalidate the cache, and it can be put into the build process easily and only invalidates on a new build. Regards, Jake Ginnivan Readify | Senior Developer | MVP (VSTO) M: +61 403 846 400 | E: jake.ginni...@readify.netmailto:jake.ginni...@readify.net | W: www.readify.nethttp://www.readify.net/ From: ozsilverlight-boun...@ozsilverlight.com [mailto:ozsilverlight-boun...@ozsilverlight.com] On Behalf Of Simon Hammer Sent: Thursday, 8 September 2011 12:07 PM To: ozSilverlight Subject: RE: Refreshing an SL4 app (client problem?) Hi Greg, Funny, I was dealing with this today We handle this by having a version number in the xap filename (eg. SLAppName1.5.2.xap). This way whenever a new build goes on production, we know browsers will referencing the correct one. Simon. From: Chris Anderson [mailto:christheco...@gmail.com]mailto:[mailto:christheco...@gmail.com] Sent: Thursday, 8 September 2011 2:02 PM To: ozSilverlight Subject: Re: Refreshing an SL4 app (client problem?) It's because the browser is caching the app, and your IIS probably doesn't set any cache expiry headers. Here's some info: http://stackoverflow.com/questions/2281919/expiry-silverlight-xap-file-from-browser-cache-programmatically Chris On 8 September 2011 13:58, Greg Keogh g...@mira.netmailto:g...@mira.net wrote: Well I should have asked my cat, because I browsed to the SL4 app from the outside world and it was the latest version. When browsing from my work machine I see the old version. So I restart my localhost IIS and delete temporary files in the browser, but it makes no difference. As an administrator I delete all local v2 and v4 ASP.NEThttp://ASP.NET temporary files and restart IIS, now it's fixed. So it looks like the problem was on my client side, not on the server machine side. I'm not sure which step fixed the problem, but it *might* have been deleting the local temporary files. Greg ___ ozsilverlight mailing list ozsilverlight@ozsilverlight.commailto:ozsilverlight@ozsilverlight.com http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ ozsilverlight mailing list ozsilverlight@ozsilverlight.com http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
RE: A typical few hours
I know exactly the problem you are having because I have had the same issues before, see my blog post at http://jake.ginnivan.net/radiobuttonbindings The problem is the implementation of the radio buttons. When I check one of them, it will search for other radiobuttons in the same group (inside parent containers visual tree I think), and will clear the value. This clears your binding =( My blog post has the workaround that I have used. Regards, Jake Ginnivan Readify | Senior Developer | MVP (VSTO) M: +61 403 846 400 | E: jake.ginni...@readify.netmailto:jake.ginni...@readify.net | W: www.readify.nethttp://www.readify.net/ From: ozsilverlight-boun...@ozsilverlight.com [mailto:ozsilverlight-boun...@ozsilverlight.com] On Behalf Of Greg Keogh Sent: Friday, 22 July 2011 3:00 PM To: 'ozSilverlight' Subject: A typical few hours So I have a plain class object as the DataContext for a UserControl with a variety of controls on it. All of the two-way binding works perfectly except for a group of 3 radio buttons which seem to change their checked states in an incomprehensible random way. For over 3 hours I stick debug displays into every crack I can find, I swap code in and out, I try it on different controls, I fiddle with the bool-enum converter, but absolutely nothing makes any difference. Similar radio buttons on another similar control work perfectly, only this one is stuffed. I eventually deleted all binding code for the radio buttons and used an old WinForms style get/set property and it works. I think this is a really typical case of what I've been complaining about for two years now, and it's getting worse. As my working days pass, more and more roadblocks, workarounds, gotchas and bugs degrade my work satisfaction and income. Most of this suffering continues to come from Silverlight, WPF and WCF. NRN, I'm just venting my boiling spleen. Greg ___ ozsilverlight mailing list ozsilverlight@ozsilverlight.com http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
