Can I use .NET instead of COM

[Guest]

I have several unmanaged C++ based DLLs. I would like to wrap them and
expose them as a class library for third party use (i.e., VB). In the past
(pre .NET days) I've done this with COM - I'd write ATL COM interfaces that
could then be programmed to in VB code by a third party. I have tinkered
with 'unsafe' C++/CLI and seem to be able to achieve the same result by
writing a managed C++ wrapper that I expose to the outside world (e.g., VB
and C#), while translating to native/unmanaged C++ within the wrapper to
leverage the legacy unmanaged C++ code base. Can I move forward with this
approach in a production environment? Some considerations/questions I need
to know more about:

1) Versioning: COM supports versioning where a versioning number scheme is
supported by COM, and the rules support previous interface versions are
supported by newer versions. .NET seems to support the same sort of thing.
Is this true and .NETs intent?

2) Strong/unique naming: COM had unique GUIDs to ensure a unique name.
..NET has the Strong naming concept. Are they in the same vein, and will I
have difficulty with my unmanaged code/dlls (i.e., do I have to, and can I
strong name my unmanaged DLLs)?

Thanks for any help!

 

[Bruno van Dooren [MVP VC++]]

I have several unmanaged C++ based DLLs. I would like to wrap them and

expose them as a class library for third party use (i.e., VB). In the
past
(pre .NET days) I've done this with COM - I'd write ATL COM interfaces
that
could then be programmed to in VB code by a third party. I have tinkered
with 'unsafe' C++/CLI and seem to be able to achieve the same result by
writing a managed C++ wrapper that I expose to the outside world (e.g., VB
and C#), while translating to native/unmanaged C++ within the wrapper to
leverage the legacy unmanaged C++ code base. Can I move forward with this
approach in a production environment?

Yes. One of the major advantages of C++/CLI is the ability to reuse
unmanaged code in a managed environment without having to jump through
hoops.

Some considerations/questions I need
to know more about:

1) Versioning: COM supports versioning where a versioning number scheme
is
supported by COM, and the rules support previous interface versions are
supported by newer versions. .NET seems to support the same sort of
thing.
Is this true and .NETs intent?

Yes. .NET apps link against versioned assemblies.

2) Strong/unique naming: COM had unique GUIDs to ensure a unique name.
.NET has the Strong naming concept. Are they in the same vein, and will I
have difficulty with my unmanaged code/dlls (i.e., do I have to, and can I
strong name my unmanaged DLLs)?

I am not the .NET expert around here, but I think .NET uses namespaces for
that.
I.e. the combination namespace.typename should be unique, and exist in the
specific version of the assembly that you load.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"