No-Touch Samrt-Client Deployment and IE cache

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have no-touch smart-client application deploying from our IIS Intranet Web
server. The application executable and assemblies get downloaded into the
user's IE cache on their PC automatically as part of the framework process.
The problem is that in some offices, they automatically clean-out the IE
cache every morning. Which means that the executable and assemblies get
re-downloaded everyday.

Is there a way to maintain the files in the IE cache area? in essence
preventing un-neccessary re-downloading of the files everyday when nothing
has changed. The files total about 5Mbs. Nothing is strongly named at this
time.

Thanks for any input.
 
Mr. Maui,

I'm sure your users are some really heavy browsers since it's relevant to
clean the cache this often, but could it be, that the cleaning could be done
a bit less frequently?


Best regards,

Henrik Dahl
 
Rob Maui said:
We have no-touch smart-client application deploying from our IIS Intranet Web
server. The application executable and assemblies get downloaded into the
user's IE cache on their PC automatically as part of the framework process.
The problem is that in some offices, they automatically clean-out the IE
cache every morning. Which means that the executable and assemblies get
re-downloaded everyday.

Is there a way to maintain the files in the IE cache area? in essence
preventing un-neccessary re-downloading of the files everyday when nothing
has changed. The files total about 5Mbs. Nothing is strongly named at this
time.

Thanks for any input.
Click to expand...

You might need to take more control of the deployment process. Since IE
caching is the problem, and you do not have direct control over your users'
IE habits, you might need to switch over to using a deployment technique
such as the Updater Application Block
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html
/updater.asp). This makes the process a little more complicated, but it
gives you more control and flexibility. And once it has been implemented,
you still get all the benefits of deploying to a central server.
 
It is a "policy" of the office we are deploying too. They have tentatively
agreed to once a week, at the very least. This does provide some relief, but
an alternative would be preferrable.
 
Back
Top