Assemblies deployed with IE are downloaded multiple times ?

[Ben]

Deploying assemblies via Internet Explorer works quite well.

Though, there seems to be some strange comportements : after I gave a look
at the IIS log files,
I have a couple of questions.

When I work with assemblies that are not strong-named, here is what it looks
like in the log files :

#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port
cs-method cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes
cs-bytes time-taken
2002-10-13 11:46:16 127.0.0.1 - W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 401 5 4644 816 50
2002-10-13 11:46:18 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 200 0 953 627 150
2002-10-13 11:46:18 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 200 0 13816 339 10
2002-10-13 11:46:37 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll.config - 200 0 399 255 17785
2002-10-13 11:46:41 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 304 0 202 336 0
2002-10-13 11:46:41 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.DLL - 200 0 13816 248 110
2002-10-13 11:46:48 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MySecondAssembly.DLL - 200 0 11768 254 140

As you can see, the MyAssembly.dll, which contains the user control that is
rendered on the HTML page, is downloaded twice (13816 bytes). Why ? Worst,
if I close IE launch a new instance and re-try, it gives exactly the same
trace, meaning that the assembly is downloaded twice again, though it is
already in the downloaded assembly cache !? On the other hand, the
referenced assembly MySecondAssembly.dll is downloaded only once, but it is
downloaded again during the second try.

When I do the same with strong-named assemblies, it gets a little bit
different :

2002-10-13 11:41:17 127.0.0.1 - W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 401 5 4644 816 30
2002-10-13 11:41:19 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 200 0 953 627 170
2002-10-13 11:41:19 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 200 0 23543 339 50
2002-10-13 11:41:25 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll.config - 200 0 399 255 5188
2002-10-13 11:41:28 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 304 0 201 335 20
2002-10-13 11:41:35 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MySecondAssembly.DLL - 200 0 12280 254 90
2002-10-13 11:41:41 127.0.0.1 - W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll.config - 401 5 4644 198 20

As you can see, during the first try, the MyAssembly.dll is downloaded only
once (which is good), and the referenced assembly also. But as strange as it
may looks, there is a GET request with a 401 status on the .config file at
the end of the try.

For the second try, MyAssembly.dll is downloaded again (which is not good),
but the referenced assembly is not accessed anymore (I suppose the cached
version is used), which seems strange to me because there should be at least
an HTTP request to check the version of the file :

2002-10-13 11:42:38 127.0.0.1 - W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 401 5 4644 816 0
2002-10-13 11:42:39 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/Default.htm - 200 0 953 627 0
2002-10-13 11:42:39 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 200 0 23543 339 60
2002-10-13 11:42:39 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll.config - 200 0 399 255 20
2002-10-13 11:42:42 127.0.0.1 trasys\plb W3SVC1 TRA1166 127.0.0.1 80 GET
/CodeAccessSecurity/MyAssembly.dll - 304 0 201 335 0

In short, I don't quite understand what is going on behind the scene, and I
hope there is a way to avoid those redondant downloads ?

Any idea ?

Thanks,

Ben.

[Rajasi Saha]

The duplicate downloads is a result of how LoadFrom is implemented in the
CLR.
When you download an assembly via OBJECT tag, it translates into a
LoadFrom(http://server/MyAssembly.dll) call. Each time there is a LoadFrom,
the CLR also issues a Load call, using the fully qualified assembly name.
The reason for this is somewhat convoluted, but basically Load and LoadFrom,
each loads assemblies into its own context. If the same assembly can be
loaded into both LoadFrom and Load contexts, then the one in LoadFrom
context is thrown away and the copy in Load context is kept.

Referenced assemblies (e.g MySecondAssembly) are loaded using Load, not
LoadFrom and hence they are downloaded only once. The first assembly in OBJ
tag will always be downloaded, regardless of whether it is cached or not,
since it is got using LoadFrom.

In the case of strongly named assemblies, the first assembly is downloaded
only once because the second Load call finds a match in the cache. If a
matching strongly named assembly (matching name, culture, strong name,
version) is found in the cache, then the cached copy is used.

In the case of simply named assemblies, the timestamp of the server & cached
copies are compared and the newer one is used.

hope this helps.
rajasi

"Ben" <benoit....@trasys.be> wrote in message
news:aoe3la$lb9de$1...@ID-162823.news.dfncis.de...

[Ben]

Rajasi,

Thank you for your help : it is now clearer.

Still one point that I don't understand : in the case of simply named
assemblies, MyAssembly.dll is re-downloaded each time, which is normal
following your explanation on LoadFrom, but the referenced assembly is also
re-downloaded each time though the timestamp on the server has not been
changed ?

Any idea ?

Ben

"Rajasi Saha" <raj...@hotmail.com> wrote in message
news:OQT8XxHdCHA.1864@tkmsftngp11...

[Rajasi Saha]

Here is what one of the developers in this area has to say:

"Regarding the re-download issue - Fusion can't resolve it without download
because of simple name and for some reason wininet thinks the file might
have been updated.
Without seeing full server responses it's hard to guess why wininet doesn't
have enough info to see that the file hasn't really changed. It might be
bad/lack of Expiration date, or different ETag, or some value in
"Cache-Control", or lack of Last-Modified in response, or some Auth stuff (I
saw HTTP 401 in the customer's logs), or IE cache settings, or something
else."

"Ben" <benoit....@trasys.be> wrote in message

news:aom48k$nnrt4$1...@ID-162823.news.dfncis.de...