tags:

views:

674

answers:

2

Back in the day, I wrote an out-of-process (i.e. EXE) COM server using VC++ 7.x (Visual Studio 2003 and .Net 1.1) using the ATL library. The server used the Multi Threaded Apartment (MTA) model and is activated by DCOM calls (VB6 clients). Multiple client requests are satisfied by a single process -- which is activated by the first request (automatically by the COM infrastructure).

It was quite a complex piece of code and I now have to make some changes to it. Unfortunately, the machine I built it on is long gone and I'm having problems even compiling the project on a new machine with VS 2003. A few years ago, I toyed with moving this project to VS 2005, but there were a lot of breaking changes to the ATL library and I gave up on that effort.

Rather than tackle with my current problems building this old VS 2003 C++ project, I'm toying with rewriting the thing in .NET. This will make it much more maintainable at my small shop (where we don't do C++ anymore). The ATL macros and C++ idioms are long since gone from my memory, and I'd like to keep them there. :-)

So I'm exploring how feasible it is to do this rewite in C#/VS2008. I know you can expose .NET classes to COM clients. Indeed I've done so with some simple stuff in the past. However, this is much more complex. I'm not sure of a number of things:

  1. The interfaces are all defined in a type library that is consumed by the clients (that must remain unmodifed). May I assume that I can build a .NET server that implements these interfaces based on an existing type library?

  2. The server implements a number of interfaces that inherit from IDispatch and are marked with "dual" and "oleautomation". As an example:

    [odl, uid(...), dual, oleautomation]
    interface IKDFTSearchManager : IDispatch {
    
    
    
        HRESULT Method1(...);
        HResult Method2(...);
    
    }

    I don't believe that any of the clients use the IDispatch methods, but I would assume that the VTable generated by interop must match up. How would one expose this from a .NET server?

  3. What type of project should house the components? A console application?

  4. DCOM would presumably activate the EXE if it is appropriately registered with one of the interop tools. Is that the case? Would the infrastructure behave as it did with the C++/ATL server -- i.e. cause a single EXE to be activated that serviced multiple client requests?

  5. Related to (4), would this server be using the Multi Threaded Apartment model?

A: 

I come from the similar background, and I can image there will be significant efforts to do this especially if you don't want to touch the client at all.

There is .Net sdk tool called Tlbexp.exe which will export the type library for you on .Net assembly. I assume you need use this tool to run against your new c# assembly (dll) to generate the same type library as your old COM server.

J.W.
+1  A: 

To begin with I would recommend reading this (Ever done a total rewrite of a large C++ application in C#?)

You should look into ServicedComponent which is the official way of implementing a DCOM server in .NET.

The project will be a class library that will hosted by the COM+ you can host the project as service also again you don't need to write the host COM+ will take care for that.

You can reference you old tlb (but I would recommend writing p/invoke interface inside your project) and implement the interfaces.

You will need to use ProgIdAttribute to keep the old one.

Shay Erlichmen