What is COM, COM+ ?

[Bradley1234]

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

 

[Guest]

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

 

[For Your Eyes Only]

Hi

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

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.

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

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

Is ActiveX a similar thing?

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

And yes, it is a com object.

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

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
each other.

 

[David Browne]

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.

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

 

[Bradley1234]

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.

 

[For Your Eyes Only]

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

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.

When ms rewrites office as a .net app, then we can forget about com/com+

 

[David Browne]

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.

When ms rewrites office as a .net app, then we can forget about com/com+

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

David

 

[For Your Eyes Only]

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

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.