views:

33

answers:

1

I'm writing a class library in .NET that wraps a COM dll and exposes specific functionality to be consumed by other .NET code. The COM library has several enumerations defined and I've used some of the enum types as parameters like so:

//C#
public void TransactionTypeSetByEnum(COMComponent.TransactionType transType)
{
    this.TransactionType = transType
}

'VB.NET'
Public Sub TransactionTypeSetByEnum( _
  ByVal transType As COMComponent.TransactionType)
    Me.TransactionType = transactionType
End Sub

However, when I go to consume this .NET wrapper from a different project, the compiler can't see the COM types (and I don't want to expose them to the consuming class). For example...

 netWrappedObject.TransactionTypeSetByEnum( //...No intellisense for the enum

Is there a way to expose the underlying unmanaged enumeration in my .NET wrapper library without adding an unmanaged DLL reference the project that's responsbile for consuming that library?


Additional background information:

The business already has working VB6 code that has been compiled into a COM component. The business does not want to rewrite those components in .NET managed code, but wants to be able to consume that existing code in a .NET application. Rather than have every .NET application pull the COM component in directly, my goal is to write a .NET "wrapper" around the existing COM component and expose needed functionality with classes and interfaces to other .NET application.

Part of my thinking behind using interface design to wrap the COM dll is this: should the business decide later on that it would be better to rewrite the existing COM dll to be 100% managed .NET code, all I would have to do is implement the interface with the new code and change the existing applications to reference the new assembly and possibly change one line of code. This avoids the need to have to rewrite the implementation of the COM dll for each .NET application.

In my question above, my problem is that the COM dll has several enums that I want to be exposed through the .NET component that "wraps" that DLL. Let's say the COM dll has a class called ComFoo which has an enumeration call ComFooEnum. I want the NetFoo class to somehow expose ComFooEnum when other projects consume NetFoo. I don't want the other projects to be required to reference ComFoo just to be able to see the enum exposed by NetFoo. If I have to mimic ComFooEnum and make a new NetFooEnum, I suppose that's what I'll do, but I'm wondering if there's a better way.

Here's a diagram that tries to explain the encapsulation I'm trying to achieve:

______________________________  
|                            |  
| Compiled VB6 COM Assembly  |  
|  Exposes class called      |  
|     ComFoo                 |  
|____________________________|   
                        ||
_____________________   ||
|                   |   ||
| Existing VB6      |   ||
| Business          |  < |
| Application       |   ||
| references ComFoo |
|___________________|

//The business is building new applications in .NET
//that need to consume ComFoo, which cannot be rewritten.
//NetFoo exposes the functionality of ComFoo.

____________________________________
|                                  |
|        .NET Wrapper Assembly     |
|    Exposes class called NetFoo   |
|  ______________________________  |
|  |                            |  |
|  | Compiled VB6 COM Assembly  |  |
|  |  Exposes class called      |  |
|  |     ComFoo                 |  |
|  |____________________________|  |
|__________________________________|
                        ||
_____________________   ||
|                   |   ||
| New .NET Business |  < |
|  Order Entry App  |   ||
| references NetFoo |   ||
|___________________|   ||
                        ||
_____________________   ||
|                   |   ||
| New .NET Business |   ||
|  Internet App     |  < |
| references NetFoo |   ||
|___________________|   
+1  A: 

There's no magic available here. Just as you wrap the interface types from the COM component with equivalent .NET types, so you have to wrap other declarations from the type library. If you don't want to expose the COM enum types then you have to wrap them. With a .NET enum type declaration. The code is simple by casting through int, but it is a maintenance item. Just like the .NET class wrappers are. Make sure there's an actual value-add from wrapping the COM types, a one-to-one mapping is rarely useful.

Unless this is training wheels for an eventual replacement of the COM server. Which is a-okay, it gives you a good feel for what's needed. In which case you really do want to declare the enum.

Hans Passant
+1 I don't understand the benefit of the .Net wrapper. To me the obvious upgrade path would be to replace the COM component with a.Net one with equivalent signature. That component could be used for all the .Net clients. Sounds like this is a refactoring in order to make possible future changes easier . But what is to be gained by doing it now, not during the future change? I don't understand the benefit in this case.
MarkJ