Is there a cost to using managed (.NET) components inside COM+?

Our company has relied heavily on COM+ components to centralize our DAL code and take advantage of the ability of COM+ to handle transactions and connection pooling. When we started using COM+, it was just with VB6 DLLs and always through late-binding so we could take advantage of DLLs being hosted on a different server.

When we started moving to .NET in 2005, we ported our DAL functionality to .NET and continued to use COM+ and late binding to host the components. We would instantiate the objects like so:

objBalLauncher = CreateObject("NETBLL.Launcher", "\\" & strCOMPlusServerName)

I noticed that CreateObject seems to be for ActiveX CO开发者_如何学运维M components, so this has me thinking about two things:

• If COM+ was designed for unmanaged components, is there a cost to using COM+ with managed .NET DLLs?
• Is there a cost to using CreateObject() to late-bind to an assembly from within .NET code? Does this force your code to cross the managed/unmanaged barrier to communicate with the DLL?

NOTE: While I would be interested in hearing about alternatives to COM+ (which I'm sure are available by now), I'm most interested in hearing about what expense I incur from using managed DLLs within COM+.

Hosting a managed .NET component as a COM+ object does require that the COM+ calls are marshaled from the unmanaged COM+ host to the managend .NET implementation of the COM object, so yes this is some overhead.

However, if you are accessing your objects remotely, then the cost of the standard COM marshalling and related RPC is probably overshadows the COM interop overhead, so it would probably not even factor much into your equation. And of course the actual work done by the COM object, accessing databases, enlisting in distributed transactions etc. probably dwarf the interop overhead.

But, of course at the end of the day you need to profile and determine where your potential bottlenecks are. I doubt the COM interop is going to be a major concern though.