Hosting Windows Forms Controls in IE & Compression

  • Thread starter Thread starter Wells Caughey
  • Start date Start date
W

Wells Caughey

Hello everyone,

I am writing an application where I am hosting a control I created in IE.
Everything seems to work ok (aside from the minor security glitches here and
there) but it seems to take a very long time to navigate to and from the
page containing the custom control, even after it has been cached in the
downloads section of the GAC. From this I have several questions:

1) Is the control being downloaded everytime I navigate to the webpage
hosting it? If so is there anyway I can keep that from happening without
resorting to hosting the control via the COM interop?

2) Shouldn't the control exist in memory even though the page it is on is
not the current page? It seems like a new instance is create every time I
navigate forward or back.

3) Is there anyway I can tell IE to host my control but to load it out of a
*.cab file or some other compressed medium instead of have to load it out of
an uncompressed medium. Currently my assembly is 320K and I can only see it
getting bigger.

Thanks for any advise,
Wells
 
Hi Wells,

I apologize for the delay.

1), the assemblies will not be download every time you access the webpage,
the download cache will cache the webpage, so if there is no update on
server side, no file download will occur, you may verify this by analyzing
the log of your WebServer. However, when fusion load the assembly, it dooes
need to send get request to the Web Server and wait for the server reply,
(server will reply 304 in case the client cache is valid). the process will
increase the loading time.

2). I'm not clear about it, but it looks to me an internal implementation
detail, IE must have done many optimization here.

3) I'm still researching if there is a way to load .NET Winform control
from a .CAB file, but have you considered using multi-file assembly to
speed up the download concurrency and speed?
The following the document in the .NET Framework developer guide will give
more explaination about the multi-file assembly and how to build a
multi-file assemly.
<Building a Multifile Assembly>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconbuildingmulti-fileassembly.asp

You may also try the workaround in Robert's blog to see if will help

http://blogs.msdn.com/robgruen/archive/2004/07/21/190600.aspx

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Ying-Shen,

Thank you for the response. I have not considered a multi-file assembly; I
will follow the links and research it further to see if it will help, but
really, if the assembly is only downloaded once and from there on out cached
on the client, I don't really care how long it takes to download it the
first time (within reason of course). I will check the IIS logs to make
sure that everything is being cached correctly. It could be the case that I
have set up the cache headers incorrectly, and that may be why it appears to
take so long to load the assembly. As for the CAB file, I do not think that
the IE host supports it. I have tried several variations using the CAB file
and each failed, which is unfortunate because I got a 5:1 compression ratio.

Thanks again,
Wells
 
Ying-Shen,

Thank you for the response. I have not considered a multi-file assembly; I
will follow the links and research it further to see if it will help, but
really, if the assembly is only downloaded once and from there on out cached
on the client, I don't really care how long it takes to download it the
first time (within reason of course). I will check the IIS logs to make
sure that everything is being cached correctly. It could be the case that I
have set up the cache headers incorrectly, and that may be why it appears to
take so long to load the assembly. As for the CAB file, I do not think that
the IE host supports it. I have tried several variations using the CAB file
and each failed, which is unfortunate because I got a 5:1 compression ratio.

Thanks again,
Wells
 
Hmm, that is weird, my last post is showing up twice...

I looked at my IIS log file and it does appear to be using the cached
version of my assembly, but I found something else that is even stranger.
Even though the runtime finds my assembly on the first try it continues
looking for it in different virtual folders. It even looks for a resource
assembly which I am not using. If this were just a few attempts, I wouldn't
worry about it too much, but depending on the request, the runtime tries
somewhere between 47 and 57 different urls, even though it has already found
the assembly. This probably isn't a bottleneck but it is still 47-57 round
trips to the server for nothing. Is this normal and expected behaviour?

Thanks,
Wells

Wells Caughey said:
Ying-Shen,

Thank you for the response. I have not considered a multi-file assembly; I
will follow the links and research it further to see if it will help, but
really, if the assembly is only downloaded once and from there on out cached
on the client, I don't really care how long it takes to download it the
first time (within reason of course). I will check the IIS logs to make
sure that everything is being cached correctly. It could be the case that I
have set up the cache headers incorrectly, and that may be why it appears to
take so long to load the assembly. As for the CAB file, I do not think that
the IE host supports it. I have tried several variations using the CAB file
and each failed, which is unfortunate because I got a 5:1 compression ratio.

Thanks again,
Wells

Ying-Shen Yu said:
Hi Wells,

I apologize for the delay.

1), the assemblies will not be download every time you access the webpage,
the download cache will cache the webpage, so if there is no update on
server side, no file download will occur, you may verify this by analyzing
the log of your WebServer. However, when fusion load the assembly, it dooes
need to send get request to the Web Server and wait for the server reply,
(server will reply 304 in case the client cache is valid). the process will
increase the loading time.

2). I'm not clear about it, but it looks to me an internal implementation
detail, IE must have done many optimization here.

3) I'm still researching if there is a way to load .NET Winform control
from a .CAB file, but have you considered using multi-file assembly to
speed up the downo load concurrency and speed?
The following the document in the .NET Framework developer guide will give
more explaination about the multi-file assembly and how to build a
multi-file assemly.
<Building a Multifile Assembly>
Click to expand...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconbuildingmulti-fileassembly.asp

You may also try the workaround in Robert's blog to see if will help

http://blogs.msdn.com/robgruen/archive/2004/07/21/190600.aspx

Thanks!

Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
Click to expand...
Click to expand...
 
Hi Wells,

Unfortunately, this is the expected behavior, fusion automatically probes
for the possible file names of the assembly and the resource assembly for
that assembly. You may write a config file for your application and set up
the assembly binding to avoid the automatic probing. For more information
about the assembly binding settings you may read the follow docs in MSDN:
<How the Runtime Locates Assemblies>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconhowruntimelocatesassemblies.asp
and the <assemblyBinding> element in configuration file:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht
ml/gngrfassemblybinding.asp

For resource assembly probing, you may try adding
NeutralResourcesLanguageAttribute to the main assembly to improve the
lookup performance for certain resource. You may refer to the document for
more information:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemresourcesneutralresourceslanguageattributeclasstopic.asp

Thanks!


Best regards,

Ying-Shen Yu [MSFT]
Microsoft Community Support
Get Secure! - www.microsoft.com/security

This posting is provided "AS IS" with no warranties and confers no rights.
This mail should not be replied directly, please remove the word "online"
before sending mail.
 
Thanks, Ying-Shen. I will investigate those links. I am surprised that
fusion continues to probe even after it has found the requested dll, but the
overhead probably isn't all that great. I'm just glad it was caused by
something I'm doing.

Wells
 
Back
Top