Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Active Document Server and .NET migration

0 views
Skip to first unread message

Kevin Greer

unread,
Jan 3, 2003, 1:29:12 PM1/3/03
to
Hi,

Our application is an Active Document Server developed
using VC++ 6.0. We have successfully compiled the code in
VC7.0. We were planning to use the .NET languages to
develop new features (with rich GUI) as .NET controls
instead of ActiveX controls and host it in the original
application. Since .NET controls cannot be hosted in the
legacy containers what options do we have to migrate to
the .NET languages? Our goal is to code new enhancements
using the new languages and integrate successfully with
our legacy applictaion. How can we do this? How can we
make our application use Windows forms so that .NET
controls can be used?

Any help will be appreciated.

Thanks,
Kevin.

Jian-Shen Lin[MSFT]

unread,
Jan 6, 2003, 1:27:24 AM1/6/03
to
Windows Forms Article...
You can refer to following document for how to use ,NET control under IE
container.


Using Windows Forms Controls in Internet Explorer
This document describes how to successfully execute Windows Forms controls
within Internet Explorer (IE). Windows Forms controls within IE are
activated without user prompt, require no registration and utilize the
Common Language Runtime (CLR) code access security.

There are four steps in getting the Windows Forms control activated within
Internet Explorer, each listed here and detailed below.

Configure Code Access Permissions
Create the Windows Forms control
Create an HTML document with an object tag
Create the virtual directory, copy content and set permissions
Run the control

http://www.gotdotnet.com/team/windowsforms/iesourcing.aspx

Best Regards

Jian Shen

This posting is provided "AS IS" with no warranties, and confers no rights.

Kevin Greer

unread,
Jan 6, 2003, 1:03:08 PM1/6/03
to
Hi,

Thanks for your response. Are you suggessting that my
application launch or integrate with IE which in turn can
host .NET controls? My old application is MFC based full
document server.

Thanks,
Kevin.

>.
>

Anson Tsao [MSFT]

unread,
Jan 7, 2003, 5:09:00 PM1/7/03
to
Kevin,

There's an alternative and more efficient method of hosting WinForms control
in MFC applications for Visual C++ .NET 2003 (Everett release). In the
upcoming release, WinForms controls can be hosted as ActiveX controls within
MFC (that's the only new ActiveX control container that is supported). You
no longer need to use IE as a control host in your application.

In VS .NET 2003, WinForms UserControls exposes all the necessary COM
interfaces to be hosted as an ActiveX Control in MFC, however, the controls
cannot be 'registered' with RegAsm to be created as normal ActiveX controls,
you have to use the control as a managed object and obtain the IUnknown COM
interface for hosting.

There are 2 ways of obtaining the IUnknown of a UserControl from MFC:
1) Use the CLR hosting COM objects in native code to host the CLR, create
the default AppDomain and create an instance of the UserControl in this
AppDomain.
These CLR hosting interfaces are documented in the Tools Developers
Guide directory of the .NET Framework SDK
Quick summary: Use CorBindToRuntimeEx to host the runtime, obtain the
_AppDomain (i.e. System::AppDomain), and call the CreateInstance() method to
create the UserControl
2) Use Managed Extension to C++, directly create the UserControl with "new
MyControl()", and use the Marshal::GetObjectForIUnknown() to get the
IUnknown of the UserControl

The ActiveX hosting API in MFC 7/7.1 (unlike ATL) does not provide methods
to directly host IUnknown* as controls, but with a little bit of work, you
can override COleControlSite to do this yourself.

Which method to choice?
1) Using the CLR hosting leaves all your MFC code as unmanaged (x86), but
you are limited to interacting with the WinForms control through COM
Automation interfaces, this limits the degree of intergration you can
achieve with WinForms.
2) Using the MC++ method, you have to compile part of your MFC code with
/CLR (into MSIL), but you can have full access to the WinForms control, you
can expose additional methods using the full .NET type system, not just
limited to Automation types.

Hope this will get you started.

Anson Tsao
Program Manager
Microsoft Visual C++

This posting is provided "AS IS" with no warranties, and confers no rights.

"Kevin Greer" <greer_...@cat.com> wrote in message
news:07bd01c2b5ad$de4070d0$d7f82ecf@TK2MSFTNGXA14...

0 new messages