Please read my blog's comment policy here.
Over the past few months, I’ve run across a number of developers who have reported problems where their .NET application fails to render Flash or Silverlight content within a Web Browser Control.
The most common reason for this problem is that .NET, by default, compiles with a target of AnyCPU, which means that your application will run as a 64bit application if the user is running a 64bit version of Windows. This, in turn, means that the Web Browser Control is the 64bit version, and that, in turn, means that it will attempt to load the 64bit version of Flash or Silverlight. And there’s the problem—Adobe and Microsoft don’t currently ship 64bit versions of these controls. Unfortunately, most HTML content won’t detect that the browser is 64bit and will instead simply direct the user to install the 32bit ActiveX control (which won’t help).
Obviously, the same problem will occur with all other ActiveX controls which are only available in 32bit flavors, but Flash and Silverlight are the most common culprits. Until ActiveX control vendors ship 64bit versions of their controls, the only real workarounds are to either avoid using HTML content that requires the controls, or force your application to run in 32bit mode. To accomplish the latter using Visual Studio 2008:
If you don’t have the source to a .NET application and are encountering this issue, you can tweak the executable file to force it to run in x86 mode using CorFlags.exe.
We have a web application having some legacy ActiveX controls developed back in 2002-03. Some of them are from Microsoft, ComponentOne and others were developed here.
32-bit OS and 32-bit IE 7/8 works fine.
64-bit OS and 32-bit IE 7/8 again works fine.
The problem is when we run the web app on 64-bit OS with 64-bit IE 8. When a request is made, it shows yellow strip on top asking to install the ActiveX but it really doesn't install it. Rather it keeps on asking the same and after multiple attempts it shows red cross in the place holder where the control is placed.
As I mentioned the controls are quite old and for majority of them we don't have source. I am just wondering if CorFlags.exe would help us. If not, what would you like to suggest alternatively.
For the newer version of the application (that we started dev before 4 years), we strictly applied no-activex policy to make sure the app support cross browsers. But unfortunately, in the newer version we have some legacy pages that we must have to support and we can't just run away with activex controls.
For the time being, we haven't added 64-bit IE in our supportability matrix but we may wish to include in near future.
@Dhananjay: Yes, this is exactly the same issue; you're being asked to install the control because the 64bit version isn't installed, but since the web page is blindly pointing at the 32bit installer, installing it doesn't help at all.
It's very unlikely that any of these controls were written in .NET, so CorFlags.exe will not help you. You will either need to remove the dependency, get the vendor to release new versions of all of the controls, or not support 64bit IE. It's important to understand that requiring 32bit IE isn't unusual-- any site that requires Flash, including many major sites like YouTube, will not work in 64bit IE at this time.
Huh, I don't think we can get a 64-bit version libraries. The current we-dont-support-64bit-IE just works but for permanent solution we will have to migrate our pages.
Anyways, thanks for making this clear for me so quickly. Appreciate that.
Of course, a better permanent solution would be Microsoft and Adobe making 64-bit versions of Flash and Silverlight instead. It seems long overdue to me, as the transition to 64-bit computing is well underway. They both seem to be taking forever to get these versions ready, there's not even beta versions of either yet AFAIK.
@Mike: Shipping 64bit controls would be nice, yes, but it's not without its own set of problems and tradeoffs.
As noted in my original post, (http://blogs.msdn.com/ieinternals/archive/2009/05/29/q-a-64-bit-internet-explorer.aspx) web browsers are not typically the sort of things that benefit from a move to 64bit.
@EricLaw: What kind of problems and tradeoffs are we talking about ? I can appreciate that providing these 64-bit controls means more work for MS/Adobe (although with the shift to 64-bit computing in general, it's something they have to do at some point anyway), but I wasn't aware there was any drawbacks to them for users or developers. Am I missing something ?
Additionally though web browsers in general may not benefit much from 64-bit, I don't think you can say the same for the WebBrowser control. An application may use the WebBrowser control + Flash/Silverlight just as a small part of the UI for instance, and forcing the app to be 32-bit because of that could be a significant compromise.
There's also a potential issue with programs that use third party DLLs, these may not always be available in both 32-bit/64-bit and having your Platform Target choice restricted by web browser plugins may prevent a developer from using a DLL they need.
Tradeoffs: >Memory use. >Install size. >Transfer size. Incompatibility. etc, etc.
Sounds like IE8 should detect and load 32bit activex controls.
@Anthony: As a general rule, 64bit processes cannot make use of 32bit libraries.
I have tried setting compile/debug target to x86 in both VS2005 and VS2008 Express and it doesn't work. Silverlight is still saying the browser is 64 bit. Anyone got any other ideas on this one? Ta.
@xoggoth: Did you look in Task Manager to see whether or not the application is properly 32bit? You'll see a * icon after the process name if so.
Thanks EricLaw, it wasn't. Did a more relevant search and sorted it by manually editing the vbproj file as here:
Ran into this issue, but changing my target cpu to x86 did not solve the issue, the user still had to install the 64-bit version of flash for it to be useable: labs.adobe.com/.../flashplayer10_square.html
Any other suggestions?
VB.net, VS 2008, .Net 3.5
@fatal, if the app is loading the 64bit version, then your user can use taskmgr to confirm that you failed to successfully build your executable targeting x86.
Thanks for your reply. The user did confirm to me that the process has a * icon next to it, indicating that the application is indeed 32bit...yet still seems to load the 64bit version of IE.
He is on Win 7 64-bit running IE9.
Any ways for me to debug this and see why this is happening?