469,920 Members | 2,409 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,920 developers. It's quick & easy.

Architecture Issues

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

Nov 15 '05 #1
1 1084
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

Nov 15 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by d0wsdkn02 | last post: by
7 posts views Thread by Dan Walls | last post: by
3 posts views Thread by Julia | last post: by
6 posts views Thread by V. Jenks | last post: by
4 posts views Thread by wh1974 | last post: by
2 posts views Thread by WXS | last post: by
10 posts views Thread by Matt Fielder | last post: by
7 posts views Thread by Samuel | last post: by
24 posts views Thread by Jon | last post: by
reply views Thread by Waqarahmed | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.