Groups | Blog | Home
all groups > dotnet general > december 2004 >

dotnet general : What is COM, COM+ ?


Tim S.
12/29/2004 11:35:03 AM
Honestly you are very late in the game. But this shows you have spirit. I
imagine most online COM/COM+ documentation is geared to the 99% developers
who have been programming in it for years.

I suggest getting a good beginner book.

You might find the following title helpful:

The COM and COM+ Programming Primer by Alan Gordon

You may have to buy it used at Amazon.com. Or you could just wing by
studying .Net. The .Net interoop documentation should be able to show you
all you need to know.

Good Luck




[quoted text, click to view]
David Browne
12/29/2004 1:52:29 PM
[quoted text, click to view]

That's because COM is difficult to grasp. It's ugly and complicated and
there are multiple different frameworks to hide the complexity. Learning
COM now is about as usefull as learning sandscrit.

Missing the 90s is a good thing. If at all possible, leave COM, OLE and
ActiveX there.

Except for interfacing with legacy COM code and a few unmanaged API's, COM
is dead.

David

David Browne
12/29/2004 3:42:32 PM

[quoted text, click to view]

But Office apps have PIA's and you really don't have to understand anything
about COM in order to use them.

David

Bradley1234
12/29/2004 7:04:27 PM
Hi

Im trying to really understand COM and the replacement in the newer .net
framework.

Coming from an embedded side and not riding the Windows wave in the 90s, COM
seems difficult to grasp. The msdn library documentation seems to go in
circles, saying: what is com? well its, its sort of like, com is, whats com?
its extensible, its versatile, for a better description click <here>. So
that click brings up another page, com is unique, its powerful, its made for
you, for a better description, click <here> (which is the page you came
from.)

If comparing COM to LabView, would a COM object be like a .vi ?

Where you simply bring in the .vi and connect up the interfaces?

Im running a C# Express Beta (which is awesome) and want to try COM or
COM+, is this possible?

Is ActiveX a similar thing? Its like this hidden thing, hard to understand,
is there a design wizard to help create an AX component?

mtia

For Your Eyes Only
12/29/2004 7:47:08 PM
[quoted text, click to view]

COM is one thing, and one thing only: an interface specification.

It is a design for letting components talk to each other.

Com allows components ( which can be writen in c, c++, java, COBOL or
anything else ) to find what each others interfaces are, and to use them.

[quoted text, click to view]

If you right click on References, you will see that you can reference
both a .net assembly and a COM object in .net


[quoted text, click to view]

ActiveX is the name for the ms equivalent of a java applet.

And yes, it is a com object.


[quoted text, click to view]

Why would you? ActiveX is old hat. You can build WebForms components a
whole lot easier in .net

Basically, .net insulates you from COM by taking you one level higher.

Instead of having to carry around interface instructions with each
object, the .net clr and assemblies insure that .net apps can talk to
Bradley1234
12/29/2004 8:09:41 PM
Thanks Tim, that gives me a great idea, maybe trying to find documentation
and examples of the first release and see how it was presented. That book
looks excellent, my library system doesnt have it, neither is it close by in
the UC library system. I will put this book into my search/wish list.

The Amazon search also pulled up other books (those who bought...).

And yes, the documentation does seem geared to developers who have been
using it. I was feeling kind of dumb not grasping some of the stuff.

Since dotnet is going to be widely used it seems to me folks will be
migrating up or across from COM. Here Ive been hoping to find ways to
insert machine code into C# source to make it easier but maybe I should just
learn how you all are using the dotnet platform.

Are you familiar with Labview www.ni.com ? When I hear that some
application code calls an object to do a function, it reminds me of a vi;
You create one vi to handle a com port or parse data or display data, save
it, then other apps can reference it, saving time. Sort of like a semi
independent module of code where you only interact with its interfaces, and
dont care how it works.


[quoted text, click to view]

For Your Eyes Only
12/29/2004 8:31:07 PM
[quoted text, click to view]

Obviously you don't do any Outlook interop programming.

Remember, ms office apps are not .net applications, so if you want to do
any office automation, it's still COM addressible.

For Your Eyes Only
12/29/2004 10:26:15 PM
[quoted text, click to view]

Ok, I will concede.

You don't need to know COM to use a COM object in .net

The only thing I fear is that, having done quite a bit of .net interop
with Outlook recently, there are a surprising number of things that
force me to fall back on the old COM model interfaces to manipulate Office.

I really would like to see a top to bottom implementation of ms office
in pure .net

In fact, I would like to see the old IAYF model, where there are global
assemblies of /office/ methods, and maybe a whole spew of apps and
applets that do office tasks ( instead of 5 big monolithic apps, like
Word, Excel ).

The world has moved on to the web model even for office tasks (
peoplesoft ) so the ms office style is less and less relevent.
AddThis Social Bookmark Button