IE does not display a .NET Windows Form control.

Question

I have an identical asp.net application hosted on two computers, PC1 and PC3 on the intranet. The .NET control is hosted using the object tag. The following three url when executed on PC1 work properly:

http://pc1/test/test.aspx (The other two urls have pc1 replaced with pc3 and localhost)

All three urls in IE v8 show the page with the .NET control.

But the same urls do not work on PC3. They control is shown with a small red X symbol.

On the second machine, the Fiddler view shows the .NET dll is being downloaded properly, but the fusion log and IEHost log do not show anything. The first machine fusion log and IEHost log show expected reporting.

The IE on both machine are set to include all three urls above in the trusted zone. The .NET2 administration trust for the trusted zone is set to FullTrust. Additionally I have created code groups for pc1 and pc3 to provide FullTrust.

Why does IE on second machine fail to show the .NET control? Also, why the no IEHost and fusion logs are created?

Answer 1

It sounds like you have everything setup correctly.

One thing you may want to check, and this may be a shot in the dark, is your Temporary Internet Files on PC3. Make sure the assembly is actually being downloaded there. You may be over your limit if you have a lot of old files there.

I'd clear out your Temporary Internet Files and try again. Also, check your Temporary Internet Files folder to see if it is actually there. If it's not being saved because of this, that would explain why fusion log isn't seeing anything.

Answer 2

As you probably know, IE8 blocks use of .NET UserControls in the Internet Zone. http://blogs.msdn.com/ieinternals/archive/2009/10/09/DotNet-UserControls-Do-Not-Load-in-IE8-Internet-Zone.aspx

Perhaps the machine where the control doesn't work has the URLAction2005 also set for the Trusted zone?

Have you tried changing the other IE Zone security settings for .NET controls to "Prompt" to see if you get the prompt? Have you tried using that machine to load someone else's .NET control? Does that machine maybe have a .NET add-on that loads the .NET1.1 framework into the IE process preventing load of the 2.0 framework?

Answer 3

Thanks to both Eric and Aaron for helping me figure out this problem. It turned out that McAcfee site adviser add-on installed in IE was blocking access to .NET control. Although, it is curious that it would allow an ActiveX control on the form. It seems that McAfee does it own .NET related permission checking before the .NET control ever gets to IEHost.dll. I disabled McAfee Site Advisor to fix the problem.