title: Silverlight 5 - OOB install/update broken when using anti-cache trick
body: <p>I was using the timestamp trick on the Silverlight &lt;object&gt; (see <code>GetLastWriteTime()</code> using answers in <a href="https://stackoverflow.com/questions/307709/how-do-you-force-firefox-to-not-cache-or-re-download-a-silverlight-xap-file">How do you force Firefox to not cache or re-download a Silverlight XAP file?</a>) successfully with Silverlight 4.</p>
  
  <p>Using a Silverlight 5 runtime<sup>*</sup>, the OOB install/auto-update feature now seems broken. I have two issues: </p>
  
  <ul>
  <li>when launching in browser, the current install state is always 'not installed' (in code: <code>Application.Current.InstallState == System.Windows.InstallState.NotInstalled</code> is always <code>true</code>)</li>
  <li>when launching in OOB mode, it's always saying that a new version is available (in code: <code>CheckAndDownloadUpdateAsync()</code> always returns with <code>e.Error == null</code> and <code>e.UpdateAvailable == true</code>).</li>
  </ul>
  
  <p>Has anyone else encountered this, and better yet, has a workaround?</p>
  
  <hr>
  
  <p><strong><sup>*</sup> Precision:</strong> currently my app is built using the Silverlight 5 Tools, but is targeting Silverlight 4, and works fine on a Silverlight 4 Developer Runtime. The problem occurs on (at least) my dev machine using the Silverlight 5 Developer Runtime.</p>
  
  <hr>
  
  <p><strong>Update:</strong> I've checked with Fiddler what happens on my dev box. When the update process is invoked, I see:</p>
  
  <pre><code>GET /ClientBin/Client.xap?timestamp=23%2f01%2f2012+17%3a42%3a14 HTTP/1.1
  If-Modified-Since: Tue, 24 Jan 2012 09:10:07 GMT
  </code></pre>
  
  <p>That's fine for me, except that the server (Server: ASP.NET Development Server/10.0.0.0, X-AspNet-Version: 4.0.30319) returns a new version, with the following cache headers:</p>
  
  <pre><code>HTTP/1.1 200 OK
  Cache-Control: private
  Date: Tue, 24 Jan 2012 09:11:28 GMT
  </code></pre>
  
  <p>Each time I run the app, the check request has the right date (the one previously returned by the server), and each time, the server says it has a new version, with the current date. I will try to tweak the server config.</p>
  
  <p><strong>Update2:</strong> I had a cache control directive in my Web.config file, but removing it only solved half the problem. Now the in browser app detects that the OOB install is ok, but the update cycle continues, with the same Fiddler trace.</p>
  
  <p><strike><strong>Update3:</strong> The problem is definitely related to the debug web server. The same application deployed to a proper IIS with the same Web.config doesn't have this issue. But this is still annoying, as it considerably slows down my OOB debug process.</strike></p>
  
  <p><strong>Update4:</strong> In fact, the problem is still present even on my main IIS deployment, and has happened on other servers too (and using PHP to generate the timestamp instead of ASP.NET). So any help is appreciated.</p>
  
  <p><strong>Update5:</strong> As requested, here is my code, fairly straightforward:</p>
  
  <pre><code>private void CheckAndDownloadUpdateCompleted(object sender, System.Windows.CheckAndDownloadUpdateCompletedEventArgs e)
  {
      if (e.Error != null)
      {
          if (e.Error is PlatformNotSupportedException)
          {
              UpdateType = UpdateTypes.PlatformUpdate;
              //(...)
              return;
          }
          else if (e.Error is SecurityException)
          {
              UpdateType = UpdateTypes.ElevationRequired;
              //(...)
              return;
          }
          else
          {
              // Error handling code
              //(...)
          }
      }
      else if (e.UpdateAvailable)
      {
          UpdateType = UpdateTypes.Available;
          //(...)
          return;
      }
  
      UpdateType = UpdateTypes.NoUpdate;
  
      //(...)
  }
  </code></pre>
  
  <p><code>UpdateType</code> is an enum type property that allow me to pick the right localized string somewhere else.</p>
  
  <p><strong>Update6:</strong> The various <code>//(...)</code> parts are (indirectly) changing the view of the application, <code>UpdateType</code> is not.</p>