Invalid http request for .NET control

[Mark Travis]

Hi,

I have a web page with a reference to a .NET control and I am getting a
number of extraneous requests occurred that are related to the control

To Digress
=======
The html page contains a object tag that references a .NET control.
<object id="mycontrol"
class="http://server/virtualdirectory/mycontrol.dll#mycontrol"></object>
The control is downloaded and displayed on the page. Please note: The
control is always successfully displayed.

The problem
=========
Over ADSL, the request for the page seems to take a long time. When I used
Ethereal to pack sniff the http traffic, I discovered that 10 invalid
requests had been made to find the control. these range from
http://server/mycontrol.dll
to
http://server/mycontrol/mycontrol.exe
to
http://server/bin/mycontrol/mycontrol.dll
The last request is usually the correct
http://server/virtualdirectory/mycontrol.dll


Each request takes x seconds and the response is usually over 1500 bytes
(file not found response). Hence the delay in downloading the page over
ADSL.

The Question
=========
Has anyone encountered this problem before and is there a way to stop it
from happenning


Thanks in Advance

Mark

 

[Peter Huang]

Hi Mark,

I think you may try to use the classid paramter of the Object tag instead
of the class.
e.g.
classid="http://127.0.0.1/MyAssembly.dll#MyCompanyName.MyProductName.WinForm
s.Controls.MyCtrl">

Debugging a WinForms control embedded in Internet Explorer
http://blogs.msdn.com/aoakley/archive/2003/06/20/49627.aspx

You may have a try and let me know the result.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark Travis]

I noticed that the html page is not downloadable so here it is zipped

 

[Peter Huang]

Hi Mark,

Now I am researching the problem, but to isolate the problem, you may try
to deploy the control on the localmachine to exclude the DNS and proxy side
effect. Also you may try to use the ip address to locate the assembly to
see if this help you.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark Travis]

Hi Peter,

Did some further testing as per your request. My initial testing was all
done via local host so I was able to bypass you request for local machine to
exclude DNS and proxies. I had the same problems off local host as servers.

Regarding the IP Address. I ran a couple of tests and found that the problem
still existed. However, the invalid requests were using the host name
instead of the IP Address. I believe this implies that the browser is
looking for the control on the server that the page was served from, and not
the server I specify in the object tag (I am currently running the control
and the referring page on the same server but in different virtual
directories).

After rereading the article which was a redirect from your first reply
http://msdn.microsoft.com/msdnmag/issues/02/01/userctrl/
I tried to put the control in the same virtual directory as the page.
Although this did not remove the invalid requests, a valid request did occur
and it occurred as the first request for the control (ie the first request
found the control and downloaded it. It was then followed by 'x' invalid
requests for the control).

Note: On further review of my original testing, when the invalid requests
occur, no valid request was made for the control. Successful display of the
page was due to a locally cached version of the control. In the scenario
where there is no locally cached version of the control, no invalid requests
were made (only valid, requests were made).

Now, I also noticed that my test came back with less invalid requests than
my actual application, so I started to reduce the name of the component and
control. Originally the classid of the object was

http://localhost/SKM.IE.Wrappers/SKM.IE.Wrappers.Systems.DLL#SKM.IE.Wrappers.Systems.Browser
At the end of my testing I had
Wrappers.DLL#Browser
as the component now resided in the same virtual directory as the page. This
again did not reduce the number of invalid requests but it did show up
something unusual. Because I had renamed the dll to Wrappers.DLL, all the
invalid requests referred to the original name of the dll (either internal
dll name or something else in the dll's meta data). When I recompiled the
component to Wrappers.DLL, the invalid requests referred to Wrappers not
SKM.IE.Wrappers.Systems.

My last test was to copy the component into the root directory of the Web
Server (as the first invalid request points there). This sort of fixes the
problem. When I check to the http traffic, there is now 2 requests for the
dll and both are valid and processed but it doesn't feel like the right
solution. I would have thought that I should be able to publish the
component in a virtual directory of my own choosing. Anyway, it still makes
2 requests and if the localcache is clear, it downloads both dll's, one from
the virtual directory and one from the root directory.

I hope this helps with your research

As a postscript, I have also noticed an invalid request for a file called
IEXPLORE.EXE.config. The following article

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/sidexsidenet.asp
states that IExplore uses this file to verify the version of the .NET
framework to use when running the control. If it does not find it, it will
use the latest .NET framework installed on the machine. I don't see this as
a problem. I have added it as an extraneous piece of information that is
related to this issue.

Thanks again

Mark

 

[Peter Huang]

Hi Mark,

I have tried your test.html, it seems that I can not access to the winform
control because it can not be displayed on the ie page.

Have you tried my suggestion that try to isolate the problem by build a
simple html page and a winform usercontrol and put the two files in the
wwwroot directory to see if the problem persists, so that we can access the
control and webpage on the localmachine.

You may have a try and let me know the result.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi Mark,

Thank you for your information, that is helpful to state the problem. Now I
can reproduce the problem on my side and I am keep researching the problem
and I will update you with new information ASAP.

Thank you for your understanding.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi

After I further researchiing, this is by design. You can avoid this
additional probing by specifying codeBase in the configuration file.
You may refer to the following article.
814668 PRB: Runtime Probe Causes a Delay When You Load a Windows Forms
Control
http://support.microsoft.com/?id=814668

If you still have any concern, please feel free to let me know.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mark Travis]

Hi Peter,

Thanks for the information. It worked. All invalid requests have been
removed.
Performance details (approximate values) are as follows

ADSL (256/64)
=====
Prefix: 30 seconds
Postfix: 12 seconds

Dialup
=====
Prefix: 1 minute 17 seconds
Postfix: 22 seconds

Thanks for all your help

Mark