none
Problem on Upgrading .NET 1.1 based (embedded) Smart Client solution to .NET 4.0 based... RRS feed

  • Question

  • I'm on a project that is upgrading .NET 1.1 based (embedded) Smart Client solution to .NET 4.0 based, and I came across a problem.

    The solution doesn't work when I build it on .NET 4.0, but it works well on .NET 2.0 ~ 3.5.

    When I open the web page which is embedding a smart client module(WinForm based, of course), IE just leaves a small box on the module area, without any error message.

     

    The usage pattern of smart client module is like the below(embedded in html).

    <object id="smartClientModule1" classid="SmartClientModules/WinformControl.dll#WinformControl.SmartClientControl" />

    (the module name is WinformControl.dll, the namespace is WinformControl and the control name is SmartClientControl).

     

    I researched and found that the version of 'IEHost' and 'IIEHost' assemblies are 2.0.0.0, not 4.0.0.0, and the same with mscorlib.dll. The below is a log message from 'Assembly Binding Log Viewer(fuslogvw.exe)'.

     

    .NET 4.0 seems to doesn't have these modules, in contrast to 2.0 or 1.1.

     

    How can I solve this problem?

     

     

     

     

     

    *** Assembly Binder Log Entry  (2010-05-13 @ 오후 4:45:18) ***

    The operation failed.
    Bind result: hr = 0x8013101b. No description available.

    Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
    Running under executable  C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
    --- A detailed error log follows.

     

     

    === Pre-bind state information ===
    LOG: User = anyflow-PC\anyflow
    LOG: Where-ref bind. Location = http://anyflow-pc/SmartClientTest/SmartClientModules/WinformControl.dll
    LOG: Appbase = http://anyflow-pc/SmartClientTest/SmartClientModules
    LOG: Initial PrivatePath = bin
    LOG: Dynamic Base = NULL
    LOG: Cache Base = NULL
    LOG: AppName = NULL
    Calling assembly : (Unknown).
    ===
    LOG: This bind starts in LoadFrom load context.
    WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
    LOG: Using application configuration file: C:\Users\anyflow\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\HUT7HZ9B\WinformControl.dll[2].xml
    LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
    LOG: Attempting download of new URL http://anyflow-pc/SmartClientTest/SmartClientModules/WinformControl.dll.
    LOG: Assembly download was successful. Attempting setup of file: C:\Users\anyflow\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\HUT7HZ9B\WinformControl[1].dll
    LOG: Entering download cache setup phase.
    ERR: Error extracting manifest import from file (hr = 0x8013101b).
    ERR: Setup failed with hr = 0x8013101b.
    ERR: Failed to complete setup of assembly (hr = 0x8013101b). Probing terminated.


    jeoff
    Thursday, May 13, 2010 7:21 AM

Answers

  • Sadly, IEHost is not supported in .NET 4.0 - it means you can't use host WinForm control in IE as is. If you want to use it, you should continue to use .NET 3.5 SP1. (As you know, you can install both 3.5 SP1 and 4.0 on same machine.)

    I can understand their decision, but what I'm worrying is even this is breaking change but there is no mention on any document or website. We requested this issue to Microsoft, We've got "offical" comment. Here's what Microsoft saying..

    IEHost.dll is the runtime host that provides the ability to host Windows Forms controls and run executables in IE. IEHost is a .Net 1.1 technology that provided a better model than ActiveX to host controls within the browser since they were lightweight and the controls operated under the .NET security model, where they operated inside a sandbox.

    For Dev10, the proposal is to remove IEHost.dll for the following reasons

    1)    IEHost/HREF-EXEs are surface area exposed to the Internet. This poses a high security risk (we already have bugs filed related to this), and most customers (by far) who install the Framework are getting very little value for this security risk. If IEHost and IEExec is left as-is, a new model needs to be designed where either (a) using this technology is safe and is always on, or (b) is as secure as today and can be configured to be turned off. The cost of doing this is very high.

    2)    Customers who want IEHost/HREF-EXE-sytle controls or apps have numerous other technologies they can use, like ClickOnce, XBAP, Silverlight.

    3)    Customers who want the exact same functionality as 3.5 SP1 for this feature can continue to use 3.5 SP1. This change, of removing IEHost takes effect only in .Net Framework 4.0.

    4)    The opportunity cost and risk of continuing to support this feature for the CLR team is high. Going forward, we will be able to deliver more features and bug fixes that benefit more of our customers if we can remove this from NetFx4.

     

    • Marked as answer by eryang Tuesday, August 17, 2010 3:06 AM
    Thursday, July 15, 2010 9:03 AM

All replies

  • Hi jeoff,

    You can create a configuration file for your project. Then you can define the exact assemblies you need in your project. For how to use the configuration file in .net, you can refer to the link below:

    1. How to: Add Application Configuration Files to C# Projects 
    2. How to: Use an Application Configuration File to Target a .NET Framework Version 
    3. Configuring Assembly Binding Redirection 

    Good luck and have a nice day!


    Hope this helpful to you! If you have any further quetions, please feel free to let me know.
    Please mark the right answer at right time.
    Bset Regards,
    Tracy
    Monday, May 17, 2010 7:59 AM
  • Thanks for your kind answer.

    I've already put a app config file on the project, and targetted .NET Framework version 4 like below.

    ..

    <startup>

         <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/

    </startup>

    ...

    But I didn't put any assembly binding redirection tag, because there's no IEHost.dll which use .NET 4.0 core libraries.

     

    Do you have any idea about it?

     

    Thanks.


    jeoff
    Tuesday, May 18, 2010 2:40 AM
  • I have the exact same problem when I updated my WinForm control from 3.5 to .NET 4.0 and hosted in IE.

    I get the same fusion log and the control is not displayed in the browser and as you mentioned there is no IeHost library for .NET 4.0 so i am wondering if this technology is still supported in .NET 4.0

    Did you find any solution for your problem? 

    I couldn't find any one talking about this and Microsoft didn't say anything about this for .NET 4.0.



    Thanks,

    Xeos
    Tuesday, July 6, 2010 2:16 PM
  • Sadly, IEHost is not supported in .NET 4.0 - it means you can't use host WinForm control in IE as is. If you want to use it, you should continue to use .NET 3.5 SP1. (As you know, you can install both 3.5 SP1 and 4.0 on same machine.)

    I can understand their decision, but what I'm worrying is even this is breaking change but there is no mention on any document or website. We requested this issue to Microsoft, We've got "offical" comment. Here's what Microsoft saying..

    IEHost.dll is the runtime host that provides the ability to host Windows Forms controls and run executables in IE. IEHost is a .Net 1.1 technology that provided a better model than ActiveX to host controls within the browser since they were lightweight and the controls operated under the .NET security model, where they operated inside a sandbox.

    For Dev10, the proposal is to remove IEHost.dll for the following reasons

    1)    IEHost/HREF-EXEs are surface area exposed to the Internet. This poses a high security risk (we already have bugs filed related to this), and most customers (by far) who install the Framework are getting very little value for this security risk. If IEHost and IEExec is left as-is, a new model needs to be designed where either (a) using this technology is safe and is always on, or (b) is as secure as today and can be configured to be turned off. The cost of doing this is very high.

    2)    Customers who want IEHost/HREF-EXE-sytle controls or apps have numerous other technologies they can use, like ClickOnce, XBAP, Silverlight.

    3)    Customers who want the exact same functionality as 3.5 SP1 for this feature can continue to use 3.5 SP1. This change, of removing IEHost takes effect only in .Net Framework 4.0.

    4)    The opportunity cost and risk of continuing to support this feature for the CLR team is high. Going forward, we will be able to deliver more features and bug fixes that benefit more of our customers if we can remove this from NetFx4.

     

    • Marked as answer by eryang Tuesday, August 17, 2010 3:06 AM
    Thursday, July 15, 2010 9:03 AM
  • Thanks Jaewoo,

    For the last day or so I couldn't find anything about that change mentioned anywhere.

    Thursday, July 15, 2010 5:34 PM
  • Jeoff,

    I am also trying to upgrade a 1.1 smart client in to a 4.0 solution...did you ever get a solution this?  Does it require switching to Click Once, or is there some workaround to have the smart client in 3.5 SP1 and still run 4.0 supporting assemblies?

    Thanks!

    Tuesday, March 1, 2011 5:01 PM