CSharp/C# >> Why is COM in .NET not needed anymore?

by Norbert Pringer » Mon, 08 Sep 2008 01:18:40 GMT

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

CSharp/C# >> Why is COM in .NET not needed anymore?

by Marc Gravell » Mon, 08 Sep 2008 03:52:55 GMT


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

CSharp/C# >> Why is COM in .NET not needed anymore?

by Mr. Arnold » Mon, 08 Sep 2008 04:23:25 GMT


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.

CSharp/C# >> Why is COM in .NET not needed anymore?

by Marc Gravell » Mon, 08 Sep 2008 05:10:38 GMT

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

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.


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

CSharp/C# >> Why is COM in .NET not needed anymore?

by Norbert Pringer » Mon, 08 Sep 2008 05:14:15 GMT

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?

CSharp/C# >> Why is COM in .NET not needed anymore?

by Marc Gravell » Mon, 08 Sep 2008 05:55:55 GMT

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

http://msdn.microsoft.com/en-us/library/3x7357ez (VS.80).aspx

Marc

CSharp/C# >> Why is COM in .NET not needed anymore?

by Norbert Pringer » Mon, 08 Sep 2008 06:15:31 GMT

Hi Marc,


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

CSharp/C# >> Why is COM in .NET not needed anymore?

by Marc Gravell » Mon, 08 Sep 2008 06:35:23 GMT

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

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

CSharp/C# >> Why is COM in .NET not needed anymore?

by Mr. Arnold » Mon, 08 Sep 2008 08:34:05 GMT


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.


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.


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.

Similar Threads

1. Held needed: Debugger not working anymore (Machine Debug Manager)

I recently installed Windows Scipt 5.6. Since then my VS doesn't startup
properly anymore. At startup a popup appears:

Microsoft Machine Debug Manager
usage: mdm [option]
options: /dumpjit: ...

Even worse VS says my debugger (I used every day) isn't installed properly.

In the event viewer I see a DCOM error log like:

The server {2C44C9B1-CB5D-...} didn't response in time.

I receive such a log whenever I want do do anything related to the debugger
(option setting, ...)

Hope someone has a hint keeping me from reinstalling everything.

Thanks. 


2. I am unable to understand why this use of Substring does not work - CSharp/C#

3. Why I Am Not An Mvp

4. NEWBIE: Not sure why i am getting this type of error

5. Why is this not allowed anymore (anymore being with a more recent compiler)?

So I tried to compile code that my boss wrote with a newer compiler
than I was previously using (FYI, the code compiles fine on g++ 3.4.4
but not on 4.1.1). I condensed it into this simple testprogram:

#include <string>

class Foo
{
private:
   static const std::string LETTERS;
};

using namespace std;

namespace
{
   const string Foo::LETTERS("abc");
}

int
main()
{
   Foo f;

   (void)f;
}

I must admit I'm not entirely sure what he want the anonymous (correct
term?) namespace for, but the more recent compiler sure doesn't like
it:
$ g++ --version
g++ (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

$ g++ -Wall -Wextra -std=c++98 -pedantic foo.cpp -o runme.exe
foo.cpp:13: error: definition of 'Foo::LETTERS' is not in namespace
enclosing 'Foo'

I need you gurus on this one. :-)

/ E

6. I am trying to convert a C# file to VB.NET - need help - VB.Net

7. Need help for COM working from .NET Web app, but not working from .NET EXE app

Hi,



I am currenly buliding a .NET app based on a third party software.
Since the third party software was implemented using COM technology, I
am using .NET TlbImp utility to wrapper
COM dlls, then I can use them in my .NET application. However, those
new .NET dlls (after wrapping) can only work correctly from a Web app
(ASP.NET or Web Service), and it will not work correctly from .NET exe
app (Windows Form app or Window Service app). The error message is
"mscorlib Exception has been thrown by the target of an invocation.". I
am guessing those old COM dlls relying on a web environment, but just
can't figure it out how to solve it. It will be appreciated if anybody
can help me.




Thanks,



Jeff

8. findcontrol("PlaceHolderPrice") why why why why why why why why why why why - Asp.Net