Why is COM in .NET not needed anymore?

[=?ISO-8859-1?Q?Norbert_P=FCrringer?=]

Hello,

I would like to explain, why COM in-process and COM local server are
not needed in .NET anymore. Of course there are several .NET
techniques how to solve remote communication as successor of .COM
remote servers (.NET remoting, WCF communication and web services).

But the successor of COM in-process and COM local server is the simple
assembly, isn't it? The manifest of the assembly can be seen as
successor of the COM type library. There you get all the informations
about all types defined in the assembly.

Am I right?

Thank you,
Norbert

[Marc Gravell]

Re remote servers, "remoting" is probably the most natural equivalent.

The biggest gap with .NET vs COM is the out-of-process local server -
with COM an out-of-process server can be lazily instantiated, but
with .NET it would have to already be running, for example as a
windows service. Fortunately, you can use "serviced
components" (enterprise services) with .NET to host an assembly
within COM+. A little more involved, but it works.

Re the type library... if you mean a standalone TLB, then I'm not sure
there really is an equivalent. In .NET the metadata is in the assembly
itself, although you can export this to COM for interop purposes.

Marc

[Mr. Arnold]

Norbert Pürringer wrote:

Hello,

I would like to explain, why COM in-process and COM local server are
not needed in .NET anymore. Of course there are several .NET
techniques how to solve remote communication as successor of .COM
remote servers (.NET remoting, WCF communication and web services).

They got rid of COM in .Net, because COM componets such as Active X
controls are being abused, and they present serious exploit problems
that a hacker can use to exploit the computer.

COM components such as DLL(s) must be registered with the O/S, which
creates the DLL H-E-L-L issues as various versions of the same named
DLL(s) used by multiple applications break applications. With .Net
DLL(s), they can reside in the folder of its exe that uses the DLL, they
are not registered with the O/S, so multiple versions can exist on the
machine for various applications.

..Net DLL(s) such as C# and VB.Net are managed code solutions that are
controlled by the CLI and CLR.

[Marc Gravell]

They got rid of COM in .Net, because COM componets such as Active X

controls are being abused, *and they present serious exploit problems
that a hacker can use to exploit the computer.

I think that is a bit of an over-simplification, but yes: that was
*one* of the motivations. But COM/COM+ is still alive and well.

COM components such as DLL(s) must be registered with the O/S

Not true; there is registry-free COM

GAC hell isn't quite as bad, as it can at least host multiple
versions; in reality this isn't as useful as it sounds. But yes: it is
mcuh easier to drop assemblies in the release folder than it is to
configure registry-free COM for the same.

Marc

[=?ISO-8859-1?Q?Norbert_P=FCrringer?=]

How can .NET replace COM local servers? The COM in process server can
be replaced by a simple assembly with its manifest. The COM remote
server can be replaced by WCF or webservices. But is there a chance to
start a .NET application from outside and to use the functions of the
current process? Excel is a local server and can be automatically
started from a COM client (visible = true), then I can call functions
of the running Excel instance. Another COM client may use the current
running Excel instance. How can that be realized in .NET using the CLR?

[Marc Gravell]

How can that be realized in .NET using the CLR?
By hosting in COM+ via Serviced Components

http://msdn.microsoft.com/en-us/libr...ez(VS.80).aspx

Marc

[=?ISO-8859-1?Q?Norbert_P=FCrringer?=]

Hi Marc,

How can that be realized in .NET using the CLR?

By hosting in COM+ via Serviced Components

http://msdn.microsoft.com/en-us/libr...ez(VS.80).aspx

Very interesting. So the COM technique is not obsolete. Serviced
components in .NET are still based on COM. I thought, COM is not
needed anymore since release of .NET

Norbert

[Marc Gravell]

Very interesting. So the COM technique is not obsolete. Serviced

components in .NET are still based on COM. I thought, COM is not
needed anymore since release of .NET

Well, COM+. Note that interoperability with other technologies still
depends heavily on COM; not everything knows about .NET, but via COM-
interop you can write a .NET implementation of a COM API, or consume a
COM API from your .NET code. So as I already said: COM is still very
much alive and well.

Marc

[Mr. Arnold]

Marc Gravell wrote:

>They got rid of COM in .Net, because COM componets such as Active X
controls are being abused, and they present serious exploit problems
that a hacker can use to exploit the computer.

I think that is a bit of an over-simplification, but yes: that was
*one* of the motivations. But COM/COM+ is still alive and well.

Yeah it's still alive and that's why .Net must inter-operate with the
unmanaged COM and COM+ components, because if it's not broke, then one
doesn't fix it.

However, a COM component still is and will remain to be a very dangerous
solution, as it allows a software developer/hacker to do anything once
the code is executed with the privileges of the user logged into the
machine, in an exploit situation. That would be root/admin/ rights on
Windows ME and down or they run with user-admin for the most part on
Windows NT based O/S(s) that allows COM components to do anything from
an exploit standpoint.

Now supposedly, .NET managed solutions are suppose to be looking at code
execution intent to see of the execution of code is malicious in nature.
It's most likely not bullet proof, but it's better than nothing at all
which is the present situation with COM.

That's what users are looking at now as how easily the Windows O/S
platform can be exploited in the corporate and home user sectors, due to
COM componets.

>

>COM components such as DLL(s) must be registered with the O/S

Not true; there is registry-free COM

Every COM and COM+ legacy solution I have ever developed or worked with
has had to have those DLL's registered with the O/S. What you're talking
about is new technology trying to circumvent the problems of old legacy
technology. I doubt that many COM or COM+ developers even know that it
exist. And I look at this registry-free COM thing as another security
threat on MS Windows platform.

>
GAC hell isn't quite as bad, as it can at least host multiple
versions; in reality this isn't as useful as it sounds. But yes: it is
mcuh easier to drop assemblies in the release folder than it is to
configure registry-free COM for the same.

I know, and one can have strong named assemblies without the use of GAC.
I have never used GAC for Windows WEB or Windows desktop solutions.