B
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
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