locked
DLL from unmanaged EXE RRS feed

  • Question

  • I have a legacy cosole application that I wish to port to C#.NET.  I would like to know anyone's opinions on the options I'm considering.

    1)Use the unmanaged EXE as-is to import it's functions using P/Invoke?

     

    2) Re-write some of the code and re-build the unmanaged code as Visual C++ DLL project and import it's functions in a C# project.  This is (I think) necessary to take out the Console I/O calls and create a DLL Main function.

     

    3) Start from scratch in a new C# project.

     

    Item three while being the best use of resources is the last resort as it would be tedious to translate a fairly large header file that defines a couple of structs.

     

    Any help or advice appreciated as always

     

    Al

    Tuesday, October 23, 2007 8:36 PM

Answers

  • 1) You can't call managed functions from unmanaged functions through P/Invoke.  P/Invoke is used to allow managed code to talk to unmanaged functions. If this is a console app then that won't help you as the console app won't expose any functions to be called.  You would have to break out all your functions you wanted to call into a DLL.  Sounds like a lot of work.

     

    2) This is a better option but your fears (from #3) will still be realized.  You can't call unmanaged code with structures without converting those structures to managed code.  Converting structures is actually really easy and generally a direct copy from the header file with a few syntax changes.  Arrays, pointers and strings complicate things.  If you went that route then your console app would be converted to a C# app.

     

    3) Always the best option but requires the most time and effort.

     

    I assume you're porting the code because you want to rather than having a need for it?  In general it is just easier to leave legacy code as is unless you intend to add new features that require managed code.    Here are some more options.

     

    4) Rather than using C#, recompile your existing C++ app with C++/CLI.  Then you can take advantage of .NET code without rewriting your existing code.  Over time you will migrate your C++ code to managed code and can then more easily switch to C#.  As you migrate code or write new code you can begin breaking out functionality into new classes and store them in a separate DLL.  This DLL can be in C#.  So, until the migration is complete, you are using a hybrid approach of unmanaged C++ code using C++/CLI to interact with managed code and C# code in a DLL or two for newer code (if desired).  This is probably the ugliest, but fastest, approach and ensures that your app will continue to work.  There are some issues with this though as mixing managed/unmanaged code requires a good deal of knowledge of .NET and how the interaction will work.  Additionally C++/CLI can be picky about what it will and will not allow.  For example you can't nest an unmanaged type inside a managed type directly.  You get into wrapper classes and whatnot.  You'll want a good book on the topic.  I recommend C++/CLI In Action.

     

    5) I hate to mention it but if you already know/use COM in your code then you can use COM to bridge the gap.  Write your managed code and expose it through COM to your console app.  If you don't use/know COM then skip this option altogether.

     

    Michael Taylor - 10/24/07

    http://p3net.mvps.org

     

    • Marked as answer by alleyes Wednesday, May 13, 2009 2:08 PM
    Wednesday, October 24, 2007 1:27 PM

All replies

  • 1) You can't call managed functions from unmanaged functions through P/Invoke.  P/Invoke is used to allow managed code to talk to unmanaged functions. If this is a console app then that won't help you as the console app won't expose any functions to be called.  You would have to break out all your functions you wanted to call into a DLL.  Sounds like a lot of work.

     

    2) This is a better option but your fears (from #3) will still be realized.  You can't call unmanaged code with structures without converting those structures to managed code.  Converting structures is actually really easy and generally a direct copy from the header file with a few syntax changes.  Arrays, pointers and strings complicate things.  If you went that route then your console app would be converted to a C# app.

     

    3) Always the best option but requires the most time and effort.

     

    I assume you're porting the code because you want to rather than having a need for it?  In general it is just easier to leave legacy code as is unless you intend to add new features that require managed code.    Here are some more options.

     

    4) Rather than using C#, recompile your existing C++ app with C++/CLI.  Then you can take advantage of .NET code without rewriting your existing code.  Over time you will migrate your C++ code to managed code and can then more easily switch to C#.  As you migrate code or write new code you can begin breaking out functionality into new classes and store them in a separate DLL.  This DLL can be in C#.  So, until the migration is complete, you are using a hybrid approach of unmanaged C++ code using C++/CLI to interact with managed code and C# code in a DLL or two for newer code (if desired).  This is probably the ugliest, but fastest, approach and ensures that your app will continue to work.  There are some issues with this though as mixing managed/unmanaged code requires a good deal of knowledge of .NET and how the interaction will work.  Additionally C++/CLI can be picky about what it will and will not allow.  For example you can't nest an unmanaged type inside a managed type directly.  You get into wrapper classes and whatnot.  You'll want a good book on the topic.  I recommend C++/CLI In Action.

     

    5) I hate to mention it but if you already know/use COM in your code then you can use COM to bridge the gap.  Write your managed code and expose it through COM to your console app.  If you don't use/know COM then skip this option altogether.

     

    Michael Taylor - 10/24/07

    http://p3net.mvps.org

     

    • Marked as answer by alleyes Wednesday, May 13, 2009 2:08 PM
    Wednesday, October 24, 2007 1:27 PM
  •  TaylorMichaelL wrote:

    1)You would have to break out all your functions you wanted to call into a DLL.  Sounds like a lot of work.

     

    I agree

     

    3) Always the best option but requires the most time and effort.

     

    I assume you're porting the code because you want to rather than having a need for it?  In general it is just easier to leave legacy code as is unless you intend to add new features that require managed code.

     

    The need is what's driving the effort.  The need is essentially incorporating this app into a suite of other C# Windows code.

     

    4) Rather than using C#, recompile your existing C++ app with C++/CLI.  Then you can take advantage of .NET code without rewriting your existing code. 

     

    How am I using the existing code?  If I am to use it with my C# apps, I need to then compile it as a DLL right?  I'll need to see an example of the use of that, but will surely consider that as an option.  Got to get moving on it so I'll hunt around for something that seems to fit.  Pass on a link if one comes to mind.

     

    Thanks again.

     

    Thursday, October 25, 2007 2:40 PM