Architecture Issues

[Bruce Vander Werf]

Our current unmanaged architecture consists of an EXE and several
optional DLLs. The list of available DLLs is stored outside of the
EXE, and the DLLs are loaded as needed. The DLLs have identical
calling interfaces. The program dynamically links to a number of
routines in the DLL, and the DLLs, when loaded, dynamically link to a
number of routines in the EXE.

As we move the application to .NET, we are considering several
possibilities for the short-term:

1. Calling the DLLs as-is from a managed program using PInvoke.
2. Wrapping the DLLs in a COM interface and calling them using COM
Interop.
3. Creating managed versions of the DLLs.

The questions that come to mind as we start are the following:

1. What do we do about the fact that the DLLs can currently
dynamically link and call back into the EXE? I'm thinking we are going
to completely restructure this using callbacks or delegates.

2. Is there a way to dynamically link to DLLs using PInvoke? I'm
thinking that we would develop a class on the managed side that would
encapsulate the calls to the unmanaged DLL, and have one instance of
this class for each DLL that is loaded. However, it doesn't appear
that you can use the [DLLImport ...] attribute dynamically.

3. If both the EXE and DLLs are managed, is there a way to specify
references to external classes that don't have to be resolved at
compile time?

I would appreciate any insight into this.

--Bruce

[Cowboy \(Gregory A. Beamer\)]

Late binding is a bit easier in VB.NET, as it allows you to use the VB late
binding syntax. This is not a reason I would go to VB.NET, but something you
should realize.

PInvoke is certainly an option, although it requires a bit higher level
coder to get it done. The learning curve may be a bit steep on a tight
project.

COM DLLs? OK, but you get a perf hit that may be unacceptable.

Managed code? C#? Reflection.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************** ********************
Think Outside the Box!
************************************************** ********************
"Bruce Vander Werf" <br*****@hotmail.com> wrote in message
news:vp********************************@4ax.com...

Our current unmanaged architecture consists of an EXE and several
optional DLLs. The list of available DLLs is stored outside of the
EXE, and the DLLs are loaded as needed. The DLLs have identical
calling interfaces. The program dynamically links to a number of
routines in the DLL, and the DLLs, when loaded, dynamically link to a
number of routines in the EXE.

As we move the application to .NET, we are considering several
possibilities for the short-term:

1. Calling the DLLs as-is from a managed program using PInvoke.
2. Wrapping the DLLs in a COM interface and calling them using COM
Interop.
3. Creating managed versions of the DLLs.

The questions that come to mind as we start are the following:

1. What do we do about the fact that the DLLs can currently
dynamically link and call back into the EXE? I'm thinking we are going
to completely restructure this using callbacks or delegates.

2. Is there a way to dynamically link to DLLs using PInvoke? I'm
thinking that we would develop a class on the managed side that would
encapsulate the calls to the unmanaged DLL, and have one instance of
this class for each DLL that is loaded. However, it doesn't appear
that you can use the [DLLImport ...] attribute dynamically.

3. If both the EXE and DLLs are managed, is there a way to specify
references to external classes that don't have to be resolved at
compile time?

I would appreciate any insight into this.

--Bruce