What replaces OLE 2.0 in .Net?

[Avi Nahir]

Hi all,

I'm developing a C# .Net Windows Forms application, and am trying to
"host" mshtml.

Observing ItWriting control
(http://www.itwriting.com/htmleditor/index.php), I saw it implements
OLE2 interfaces to host the mshtml control. Mshtml was written to be
used through OLE, so that's it: If you're trying to 'host' a control
you need to emulate the environment for which the control was written.

However, I have a "philosophical" (or design) question: For the sake
of this posting, I differentiate between COM and OLE not
chronologically but by taking the network layers metaphor:

(*) COM is low level, IUnknown, class factories, VTable, IDispatch,
etc.
(*) OLE is a _ COLLECTION_ of several specific COM interfaces,
decreed by MS to be the glue between applications where a document of
one application is hosted within another: merging of menus and
activation of a document hosted within a container.

So,_today_, what is the way to integrate between applications? If I
wrote Word.Net today, and wanted it to be able to serve as the message
editing component of Outlook.Net, and wanted to be able to embed an
Excel.Net spreadsheet within my mail message, would I still implement
those specific COM interfaces? How? Would .Net do it for me
transparently?

Regards,

Avi

 

[Daniel O'Connell]

If you want to continue interoperating with MS office and the com interfaces
they use you will have to implement those COM interfaces, if you want to
work within your own application set you can do that by writing your own. If
you are looking for a standard I'm afraid you are out of luck(AFAIK anyway).
Hopefully MS will provide a standard solution in the longhorn timeframe, if
not I would say its up to the user community to develop such a thing.

 

[Jay B. Harlow [MVP - Outlook]]

Avi,
A hypothetical Word.Net, Excel.Net & Outlook.Net that are NOT dependent on
COM would probably be based on .NET Remoting. As Remoting is what enables
you to use an object across AppDomains, more closely coupled then Web
Services.

However! As Daniel pointed out I don't know of a current (or even planned)
"OLE.NET" that would allow Excel.Net to embed a spreadsheet in Outlook.Net
or Word.Net "document".

BTW: You are correct, today, .NET uses COM interop to use the existing COM
interfaces.

Hope this helps
Jay

 

[Daniel O'Connell]

Avi,
A hypothetical Word.Net, Excel.Net & Outlook.Net that are NOT dependent on
COM would probably be based on .NET Remoting. As Remoting is what enables
you to use an object across AppDomains, more closely coupled then Web
Services.

Actually, while remoting would serve for automation, for hosting you'd still
need a series of interfaces that would do the work of adding toolbars, menu
entries, etc(Ideally the interfaces would be remotable using implementations
on a MarshalByRef object). Atleast in the .NET strata it would be a simpler
issue, probably just one or two interfaces instead of the what...7 or so you
have to implement for OLE?(I've never done it, considered it but its too
much work from .NET). It certainly is something I'd like to see designed, I
just don't have many hopes of it happening anytime soon.
But then you start considering locating services, and whatnot, COM probably
still has the upper hand in automation as well, its unfortunate but
currently remoting just isn't up to the task, I'm hoping indigo will help
with that.

I honestly am not sure automation on the level Office uses is even possible
in the current .NET infrastructure.

 

[Jay B. Harlow [MVP - Outlook]]

Daniel,

Actually, while remoting would serve for automation, for hosting you'd still
need a series of interfaces that would do the work of adding toolbars,

menu
Which was the point of my "However" ;-)

Remoting does not solve the embedding side of the equation.

Would you want the interface to be toolbar or menu entry based per se? What
about the new WinBar in Whidbey? Or the new UI in Longhorn. I would think
you would want the interface to be "Command" based, then the "Command" could
be implemented on what ever UI the host supported. Where Command itself was
an interface describing itself... Similiar to how VS.NET addins work, of
course VS.NET add-ins are tied to the "Office" toolbars...

Jay

 

[Avi Nahir]

First of all, thank you both for your answers. Also thanks to Jeffery Tan
from MS who - to my total amazement - wrote to tell me he was monitoring
this thread. Ho Jeffery!-)

So you are saying that if I wanted to build an Active Document (I think that
was the terminology) or an Active Document Container I have to find out
which are the relevant COM interfaces and implement interop to them? From
scratch? If this is true, than me thinks MS has given up on non-proprietry
"document" integration! It'd just be too much work! (Now that I think about
it, I think there was an OLE Container control in VB 6.0 which was removed
from VS.Net. A consipracy?-)

Avi

 

[Jay B. Harlow [MVP - Outlook]]

Avi,

So you are saying that if I wanted to build an Active Document (I think that
was the terminology) or an Active Document Container I have to find out
which are the relevant COM interfaces and implement interop to them? From
scratch?

I understand that Whidbey (VS.NET 2004 available late this year) will
support displaying (hosting) ActiveX documents. Not sure if it will support
creating ActiveX documents...

from VS.Net. A consipracy?-)

IMHO: No conspiracy, its a lack of Man Power! Look at the size of .NET, even
with MS's deep pockets they only have so much man power and so much time. If
they were to implement EVERY thing available under Win32, COM & OLE in .NET
they would never have released 1.0, they needed "draw a line in the sand"
and release why they could for 1.0, they added minimally for 1.1 as it was
more fixes then anything. 2.0 is gaining a number of new items, but not
every thing, I'm sure 3.0 will gain even more.

Hope this helps
Jay

 

[Avi Nahir]

I understand that Whidbey (VS.NET 2004 available late this year) will

support displaying (hosting) ActiveX documents. Not sure if it will support
creating ActiveX documents...

Thanks for the info.

IMHO: No conspiracy, its a lack of Man Power! Look at the size of .NET, even
with MS's deep pockets they only have so much man power and so much time. If
they were to implement EVERY thing available under Win32, COM & OLE in ..NET
they would never have released 1.0, they needed "draw a line in the sand"

I was joking re. consiprancy, but we both agree it was not too high on thier
agenda.

and release why they could for 1.0, they added minimally for 1.1 as it was
more fixes then anything. 2.0 is gaining a number of new items, but not
every thing, I'm sure 3.0 will gain even more.

Thrice pays for all!

Thanks!

Avi

 

[Yan-Hong Huang[MSFT]]

Hello Avi,

Thanks for posting in the group.

Based on my understanding, now the question is: In .NET programming, what
is the replacement of COM controls like ActiveX control and some Active
Document technology in COM world? Please correct me if I have misunderstood
the problem.

This is really a good question. In fact, when we heard of .NET in the very
beginning, many developer feel " "So does this mean that COM is dead?". In
fact, Don Box has a good article on this topic which was published in MSDN
maganize. Please refer to
http://msdn.microsoft.com/msdnmag/issues/1200/com/default.aspx for this
article "Is COM Dead?".

In .NET programming, we have some new choices when developing controls in
different applications. For an example, in web form application, we have
new server control, web user control and web custom control. In winform
application, we can develop custom Windows Forms control, compositive
winform control.

For some legacy programming, just as you mentioned, ActiveX document,
ActiveX document container, surely we can implement it from the draft in
..NET programming by InterOp. However, implements all the interfaces
manually is a time consuming work. So it is better for us to stay in
unmanaged world to achieve it. In VC.NET, we can still develop a unmanaged
application easily.

Remoting and web service are also interesting topics in application
communication and data sharing. For the long term, you can also refer to
Indigo which is a new breed of communications infrasturcture build around
the web services architecture. Please refer to
http://www.microsoft.com/indonesia/msdn/indigofaq1.asp#indigofaq1_topic2
for more details.

Hope that helps.

Ps: We can send post notify email to you when there are useful replies to
your post in the newsgroup. If you want to receive it in the future, please
register a no spam email alias at:
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Daniel O'Connell]

Daniel,
menu
Which was the point of my "However" ;-)

Remoting does not solve the embedding side of the equation.

Would you want the interface to be toolbar or menu entry based per se? What
about the new WinBar in Whidbey? Or the new UI in Longhorn. I would think
you would want the interface to be "Command" based, then the "Command" could
be implemented on what ever UI the host supported. Where Command itself was
an interface describing itself... Similiar to how VS.NET addins work, of
course VS.NET add-ins are tied to the "Office" toolbars...

Ideally, yes, the WinBar is ideal for this. Currently, ToolBar and Menu are
too inflexible. They aren't the easiest things to work with sometimes
Currently I use something like
public void AddToolbar(string toolbarName);
public void AddToolbarButton(string toolbar, string name, IAction action);
public void AddMenu(string parentMenu, string name, IAction action);
etc. The COM ActiveDocument interfaces allow merging of the document's menus
and toolbars into the apps menu's and toolbars, such as when you load word
in IE. An action\command system as you suggested would be far more flexible,
however a mechanism to control the other apps preferences is needed. Ideally
you would want your prefered toolbars to load, while commands and other
toolbars can be accessed in some way.
Out of process activation is another issue that isn't handled.