Assembly Download Cache - Not Working "As Advertised"

[jonathan.beckett]

Hi all,

I am wondering if anybody has ever solved the problem with the Assembly
Download Cache not really caching things?

Here's what's happening...

I have a winforms based usercontrol that I am displaying in IE6. When
IE is launched, it fetches the new version of the usercontrol from the
web server, and it appears in the download cache. The user control
assembly IS version numbered, and IS signed with a strong name.

Internet Explorer seems to either re-build or fetch the user control
every time it displays it - which is making the entire web application
perform very slowly, as you can imagine.

Has anybody discovered how to *force* IE to use the assemblies in the
cache, and to use the "built" versions of them (or to just make the
cache work properly) ?


Jonathan

 

[jonathan.beckett]

Hi all,

I am wondering if anybody has ever solved the problem with the Assembly
Download Cache not really caching things?

Here's what's happening...

I have a winforms based usercontrol that I am displaying in IE6. When
IE is launched, it fetches the new version of the usercontrol from the
web server, and it appears in the download cache. The user control
assembly IS version numbered, and IS signed with a strong name.

Internet Explorer seems to either re-build or fetch the user control
every time it displays it - which is making the entire web application
perform very slowly, as you can imagine.

Has anybody discovered how to *force* IE to use the assemblies in the
cache, and to use the "built" versions of them (or to just make the
cache work properly) ?

I should perhaps have described this in more detail - the usercontrol
dll is appearing in the assembly download cache, but is not being used
by the browser in a new session. For example, if you close all
instances of Internet Explorer, and check gacutil, the assembly is
still there in the cache - but if you then re-open Internet Explorer,
it retrieves and compiles a new copy.

I'm guessing that it's either something internal to the assembly that
needs to be configured (beyong strong naming and versioning), or it's a
fault in the .NET framework.