Call .Net assembly from OBJECT tag in IE8

Question

I have a web page that calls a .Net assembly. Everything works fine in Windows XP and IE7. The relevant parts:

<html>
<head>
    <script language="javascript" type="text/javascript">
    function doScript() {
        myControl1.Go("value1","value2");
    }
    </script>
</head>
<body onload="javascript:doScript();">
    <object id="myControl1" name="myControl1" 
            codebase="../cabs/myassembly.dll" 
            classid="../cabs/myassembly.dll#MyNs.MyClass" 
            width="1" height="1"></object>
</body>
</html>

I cannot get this to work in Windows 7 with IE8. Some notes:

The assembly is strong named.
I am hosting this on localhost right now.
- On the machine that is working (VirtualBox-hosted WinXP, IE7), it is using an IP address to my local machine (http://1.2.3.4/...) and that IP is in the "Trusted Sites" of IE.
- On the machine that is not working (Windows 7, IE8), it is using http://localhost/... and localhost is in the "Trusted Sites" of IE.
The assembly is being served from http://localhost/cabs/myassembly.dll.
The error message is a javascript error, "Object doesn't support this property or method"
Fiddler shows a 200 OK response when the file is requested, however, it does not appear that the dll is making it to the temporary internet files location.
The site is running in "IE 7 compatibility" mode.
I have dropped all IE permissions to the most insecure it will let you in all zones, and the behavior is exactly the same.

Does anyone have any ideas to try to get this to work or troubleshoot where the problem is at?

Disclaimer: Yes, I realize it is 2012, and the world has moved past IE7, IE8, ActiveX, etc. Let's just say we're a little bit behind technologically. This is the problem I have to solve; upgrading to modern solutions isn't going to be an option.

UPDATE: I did get it to work in a Windows XP VirtualBox running IE8. So it appears the problem is specific to Windows 7. It fails both on my local machine and a VirtualBox running Windows 7, IE8.

Have you tried using IE8's Compatibility Mode? If that works then just add the compatibility mode `` to the page to force the browser into compatibility mode. — Dai, Aug 31 '12 at 16:24
Not sure if you already come across this KB http://support.microsoft.com/kb/311301/en-us?fr=1 — rene, Aug 31 '12 at 16:30
Or this http://blogs.msdn.com/b/askie/archive/2009/05/22/net-control-no-longer-loads-in-ie8-in-internet-zone.aspx — rene, Aug 31 '12 at 16:34
I'd go into trusted sites, go to custom level and then enable all the active X options, just to see if that makes a difference. There is one in there "Unsafe scripts" that I have had to enable for older code, be careful with that though. — dcreight, Aug 31 '12 at 18:01
@rene - Yes, I saw that, but that doesn't seem to be the issue. IE8 on XP is fine; only IE8 on Win 7 is failing. I even checked the registry settings directly for the `URLACTION_DOTNET_USERCONTROLS`, but everything looks good there. — Dave Mateer, Sep 11 '12 at 14:52
Have you tried w/o the ".." references in the paths? Is the IEHost dll injected in the IE process? Is your DLL injected in the IE process? What about 32-bit vs 64-bit issues? — Simon Mourier, Sep 12 '12 at 16:43
@Simon: The relative references do not make a difference. If you don't mind, please elaborate on the IEHost and DLL injection issues; I have no idea what you mean or how to trace that. Include that in an answer, if you could. Thanks! — Dave Mateer, Sep 13 '12 at 12:41
If you run a tool like process explorer from sysinternals, do you see the IEHost.dll or your DLL injected in the iexplore.exe process in question? — Simon Mourier, Sep 13 '12 at 12:45
@Simon - No, I do not see anything under the iexplore.exe process. When I run it on a machine that is working, I do see the application that is being launched by the DLL under the iexpore.exe process. — Dave Mateer, Sep 13 '12 at 16:58
If you don't see IEHost, it means Mscorie.dll did not loaded it, and if Mscorie.dll itself is not loaded, it means the problem is more in url actions or low level security things. You could check all actions (especially the new ones) to see if there seems to be something that applies to your problem, although actions tend to apply more to IE, not to Windows. — Simon Mourier, Sep 13 '12 at 17:09

score 5 · Accepted Answer · edited May 23 '17 at 12:07

5

This was solved by adding the registry key answered on "Loading .NET UserControls in IE with .NET 4.0" (even though this was a 2.0 control)

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"EnableIEHosting"=dword:00000001

edited May 23 '17 at 12:07

Community

1
1

answered Oct 09 '13 at 15:48

Dave Mateer

17,608
15
96
149

Yes, they disabled it by default for both .net 2.0 and 4.0 runtime for security reasons. Note as per the linked solution you may need to use the Wow6432Node key on 64-bit machines. – Rory Jul 23 '15 at 17:56

score 1 · Answer 2 · answered Sep 11 '12 at 09:14

I'm not sure that this will help, but I have had a similar issue and this has usually fixed it. Try these steps on the machine where it's not working.

Assign the domain of the url where the dll is located to the Trusted sites zone.
Open the Security tab in Internet Options and click Trusted sites
Click Default level and make sure that it selects Medium. If not, manually set it to Medium.
Apply

For good measure, close all IE windows and then relaunch and test if it works.

The key issue is the one that was discussed in the page that rene linked to in his second comment. As of IE8 and onwards, there is a security setting that does not have it's own UI in the Custom level list of options. The only way to affect it is by setting the Level - Medium or lower sets it to Enable while Medium-high higher sets it to Disable.

Now this might very well not be your problem, since usually the default level for Trusted sites is Medium which would enable the setting. But it's worth trying at least (maybe you have some Group Policy or something that has changed the default level of Trusted Sites).

Unfortunately, I've gone down this road, and it made no difference. That's why I'm so stumped--it *should* work exactly as you say, but something else seems to be interfering. — Dave Mateer, Sep 11 '12 at 14:57

score 0 · Answer 3 · answered Sep 11 '12 at 09:57

0

Don't use .dll file. Use .cab instead.

answered Sep 11 '12 at 09:57

Quannt

2,035
2
21
29

Do you mean a standard ActiveX control with CLSID and all that? That definitely complicates the implementation and possibly the deployment and maintenance. That might be a workaround, but I'd rather solve the problem. The DLL *should* work, as far as I can tell; I'm just not sure what else to test to determine the problem. – Dave Mateer Sep 11 '12 at 14:55
Yes I do. FYI, even with a cab file. I could not get my ActiveX works 100% as expected (I have to run IE as Admin first, install the cab, quit IE, turn on IE again in order to use that ActiveX). – Quannt Sep 12 '12 at 01:30

Call .Net assembly from OBJECT tag in IE8

3 Answers3

Linked