Standard class library dll versus COM/COM+ libraries

[ennrike]

Hi,

I am about to start a visual studio 2005 project to create a C# class library, however, I have seen that some people uses the COM/COM+ components and they develop their libraries under COM/COM+ architecture ... they see the COM component in "Component Services" and the process as well when it is running.

I am wondering ...

What are the "pros and cons" of using COM/COM+ ? (over the standard default class library dll)

Thanks,

[nelo]

What are the "pros and cons" of using COM/COM+ ? (over the standard default class library dll)

Well...it depends on a number of factors. I'm not sure how much experience you have in commercial development or otherwise. As you are probably aware the .NET Framework is relatively recent in comparison to COM and its derivatives. One of the motivations behind the .NET Framework was to provide a development and runtime platform that avoided a lot of the problems that we had with previous technologies. These problems included versioning, memory management, interoperability, etc. Most new development projects are targeting the .NET Framework and would tend to use standard .NET assemblies (which includes class libraries). That would be my approach anyway. However, a significant amount of development goes towards maintaing, upgrading or integrating existing software systems that would have originally developed using older technologies. This could be one of the reasons COM libraries are being developed. Only last year I was working for a company that was still churning out COM components (although there was a significant push to replace them with .NET components that could still be accessed as COM components through COM Callable Wrappers). There may be contractual obligations to do so. COM+ components tend to be developed to take advantage of the Component Services framework that ships with the Windows Operating System. In summary Component Services offers services such as object instantiation, object pooling, transaction support, etc. It basically does a lot of plumbing that the developer would otherwise have to do. It was a good thing and still is if the users of your component need that functionality.

In your case you probably best to stick with development in C# and .NET Framework. Remember that you can easily redesign your library to make some of the classes available to applications that want to deal with COM components. I would point out that if the interactions between your component and the client application are going to be frequent and intensive I would suggest that are built on the same platform (i.e. .NET component with a .NET client application). If you have a native application that needs to access a component it is generally quicker for it to do so with native component as well (as opposed to .NET component that is pretending to be a COM dll).

[ennrike]

Thanks for the reply, It helped me, I used to program a lot in C++ but only small proyects I am new with .NET.

Regards,

[darwen]

What are the "pros and cons" of using COM/COM+ ? (over the standard default class library dll)

A standard class library dll in C# is .NET. COM is native. There's a HUGE difference. If you can keep everything in C# and write a class library dll, or assembly as they're called in .NET-land (simply speaking - 'assembly' actually means more than just 'dll') then do so.

If you're looking at interfacing between .NET and native code I would strongly suggest you write a native static C++ dll rather than a COM dll because

(a) It supports xcopy deployment, just as .NET does.
(b) It supports side-by-side deployment, just as .NET does.
(c) Types like arrays do not need to be block copied into COM types, unlike COM.
(d) It doesn't suffer from all the irritations of COM threading models.
(e) Writing a C++ static dll doesn't require as much code as a COM-based dll.
(f) I could probably think of more, but I think that's enough...

It does mean you'll have to get used to platform invoke but there are tools out there to help you. See the wikipage (click the link) for more information and good resources.

Just bear in mind the golden rules of static dll writing :

(1) Only pass standard C++ types into and out from the dll - no classes and definately NO STL types . char * etc is fine, vector is not. Structs with no functions and all public member variables are ok - so long as they're standard C++ types..
(2) All memory allocated in the dll should be released by methods in the dll. .NET code should not be releasing memory allocated in native code - not that it can that easily of course.

And before people start jumping around about C++/CLI mixed mode dlls, unless there's a really good reason to I'd stick with native code in native dlls and .NET code in .NET exes/dlls rather than mixing them up. You'll find things easier this way. At least in my opinion - that's what I always do.

Darwen.

[nelo]

I think Darwen has put the nail in the coffin for COM . Darwen: how many of points would you raise against a native client interacting with COM? I worked in a project a couple of years ago where were interfacing with the drivers for a peripheral device. We found it worthwhile to define a C++/CLI wrapper that around the native API. Although to be fair we probably didn't look at any p/invoke tools.

[darwen]

Darwen: how many of points would you raise against a native client interacting with COM?

There are some good things about COM. For dlls which may or may not be there they are great - i.e. a plugin architecture. In contrast with static dlls you have to dynamically load them but dynamically loading dlls in C++ and then calling their methods is painful and requires a lot of code. And if you statically link and the dll isn't there your app crashes at startup, usually with a very unhelpful message.

If you have an already existing C++ static library or dll which widely uses classes then C++/CLI is the way to go. There aren't any tools that I'm aware of which will convert libraries using classes easily (not yet anyway - watch this space !).

There's SWIG - which I'm aware of, but not really investigated thoroughly. From what I've seen the configuration necessary to get SWIG to work seems horrendously complicated and the C# interfacing code you need to write using it is very unpleasant. That's just a first impression though.

However if you have a C++ static dll which has been written in a 'C' style (like the Win32 API or libxml2), or are writing a new application which will use new native code I'd stick with PInvoke for sheer simplicity. C# on one side, native C++ on the other. You always know what kind of code you are writing and from a maintenance point of view the boundaries between native and managed code are distinct so from my experience it's easier to maintain - especially if someone other than the author is doing the maintenance.

It has the added advantage of being supported by mono so the Linux people out there could have a linux port of your app if they wanted.

Darwen.