Stopping caching prevents a clickonce installer from installing?

We have a WCF click-once install application being served from an IIS website over HTTPS. It is in a subdirectory of another site which does have authenticaton (Mixed mode, both windows and form) but not applied to this folder. It also has a very high duration static cache configured, which caused us issues with our WCF app so we disabled caching in that foloder and all of a sudden the setup.exe stopped working correctly (If you went straight to the .application it worked).

We've found a work-around, setting a 5-second cache seems to fix the issue, but I was wondering if anyone could shed some light on why this would happen? The config change that fixed it was swapping the web.config in the subfolder from:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
    <staticContent>
      <clientCache cacheControlMode="DisableCache" />
    </staticContent>  
 </system.webServer>
</configuration>

To:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServe开发者_如何学Pythonr>
    <staticContent>
      <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="00.00:00:05" />
    </staticContent>  
 </system.webServer>
</configuration> 

And we tried changing back and the issue reappeared, so it's not as simple as an app pool recycle fixing it. The really weird thing is it's not happening to our staging environment, where the only difference is that it's not served over HTTPS...

Edit: Just to clarify this, I know there's not really any way to fully diagnose this. I'm quite happy to accept any rational explanation that could cause the affect described cause I don't think I could produce this effect even if I tried...

---

You mentioned that this issue isn't seen in your staging environment. Is it possible that your staging environment has some other proxy differences that might impact caching of files?

One possible reason that you might see this is if ClickOnce uses the cache control headers in the HTTP response to then determine how (or if) it should cache the application and other files associated with the ClickOnce app. Your first config tells the client to not cache the file. That goes against what ClickOnce wants to do. By allowing the file to be cached - even for 5 seconds - you allow ClickOnce to keep the file locally and then, from that point on, ClickOnce's caching logic is used to determine whether updates are required.

---

The work around seems reasonible but if I wanted to understand more I'd profile the ClickOnce installer with FileMon and see what it's runtime dependencies are. I'm guessing it makes certain assumptions that files will be persisted in the client's cache and can't find them.