none
Presenting a C++ library (.lib) for use in C# project

    Question

  • I have a collection of C++ programs and the C++ libraries they use.  The libraries currently compile to a .lib format.  Changing the project property to use a .dll results in multiple reference errors.

    Without having to go through the entire collection of source files, is there a way to create any kind of project in a .NET language that would provide a "wrapper" for the existing .lib files so that they could be used in that environment.

    Thanks.
    Tuesday, October 10, 2006 11:16 PM

Answers

  •  RickW_Houston wrote:
    Without having to go through the entire collection of source files, is there a way to create any kind of project in a .NET language that would provide a "wrapper" for the existing .lib files so that they could be used in that environment.

    Yes (sort of) but it's non-trivial.

    Let's start with some background.  Your project to compile to a .lib format is generating something known as a "static library".  Static libraries are chunks of native code built to be combined with other pieces of code via the linker.  You #include a header file that describes the functions/classes that you want to use and then link to the .lib file to provide the implementations of those functions/classes.

    You can't use that approach with a C# client because C# generates managed code and you just can't directly link native code to managed code.

    There are three ways (I can think of) to consume native code from a managed code client

    1. You turn the native code into a native code COM object using the static library to provide the implementation of the COM object's methods and then use COM Interop to invoke the (native) COM object from the managed code client
    2. You turn the native code into a native code DLL that exports some suitable entry points (again, using the static library to provide the actual implementation) and then call those DLL entry points from the managed code client using P/Invoke
    3. You create a managed code Class Library using C++ and use the static library to provide the underlying implementation of that managed class library

    Let's say your static library's header file looks like this


    namespace MathFuncs
    {
    class MyMathFuncs
    {
    public:
    // Returns a + b

    static double Add(double a, double b);
    // Returns a - b

    static double Subtract(double a, double b);
    // Returns a * b

    static double Multiply(double a, double b);
    // Returns a / b

    // Throws DivideByZeroException if b is 0

    static double Divide(double a, double b);
    };
    }

     

    Using approach #1, you'd create a new project using the Visual C++ | ATL | ATL Server project template.  You'd add a new simple ATL object to the project that exported Add, Subtract, Multiply and Divide methods.  You'd #include your static library's header file to provide the underlying implementation of Add, Subtract etc and you'd have your COM object's Add method call the underlying MathFuncs::MyMathFuncs::Add method (and return the result).  Finally, you'd make sure your COM object project linked to your static library .lib file as part of the build process.

    To consume the 'wrapper' from a C# program, you'd use Add | Reference to add a COM reference to your COM object and then just cal the COM object's methods as necessary.

    Using approach #2, you'd create a new project using the Visual C++ | Win32 | Win32 Project template and use Application Settings to change Application Type to DLL and set Additional Options to "Export symbols".  Then you would create some exported entry points (like Add, Subtract etc) to be consumed by the client.  Again, you would #include your static library's header file to get function descriptions and link to the .lib file to get actual implementations.  You'd code your exported DLL entry points to call the static library's 'real'  implementation methods and return the result.

    To consume this kind of wrapper, you would use the C# DllImportAttribute to declare the DLL entry point in C# terms and then just call the function as needed.

    Finally, using appoach #3, you'd create a managed C++ project using Visual C++ | CLR | Class Library.  You'd create a managed class (a 'ref' class) which would be called by your C# client. Again, you'd #include the native code header file and link to the .lib file to get the actual implementation of the methods you want the client to be able to call.  The managed code wrapper for the above header file might look something like this...


    #include "MathFuncsLib.h"

    #pragma once
    using
    namespace System;

    namespace ManagedMathFuncsLib {
    public ref class Class1
    {
       public:
       Class1 ()
       {
       };
       // Returns a + b

       static double Add(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Add (a, b);
       }
       // Returns a - b

       static double Subtract(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Subtract (a, b);
       };
       // Returns a * b

       static double Multiply(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Multiply (a, b);
       };
       // Returns a / b

       // Throws DivideByZeroException if b is 0

       static double Divide(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Divide (a, b);
       };
    };}

     

    To consume this managed code wrapper, you'd use Add | Reference to add a .NET Reference (to your managed wrapper) to your client program and then would call the managed (ref) class's methods as necessary.

    In all three cases above, I simplified things by using static methods in the original native code implementation.  If your static library implements classes with non-static functions then in all three approaches above you would have to conceal a private member variable that pointed to an instance of your native class and would have to new up that instance at some suitable point (in the constructor of the wrapper for example) and would have to use that private member variable to actually invoke the actual implementation of the method you were trying to call.

     

    Wednesday, October 11, 2006 4:43 AM

All replies

  •  RickW_Houston wrote:
    Without having to go through the entire collection of source files, is there a way to create any kind of project in a .NET language that would provide a "wrapper" for the existing .lib files so that they could be used in that environment.

    Yes (sort of) but it's non-trivial.

    Let's start with some background.  Your project to compile to a .lib format is generating something known as a "static library".  Static libraries are chunks of native code built to be combined with other pieces of code via the linker.  You #include a header file that describes the functions/classes that you want to use and then link to the .lib file to provide the implementations of those functions/classes.

    You can't use that approach with a C# client because C# generates managed code and you just can't directly link native code to managed code.

    There are three ways (I can think of) to consume native code from a managed code client

    1. You turn the native code into a native code COM object using the static library to provide the implementation of the COM object's methods and then use COM Interop to invoke the (native) COM object from the managed code client
    2. You turn the native code into a native code DLL that exports some suitable entry points (again, using the static library to provide the actual implementation) and then call those DLL entry points from the managed code client using P/Invoke
    3. You create a managed code Class Library using C++ and use the static library to provide the underlying implementation of that managed class library

    Let's say your static library's header file looks like this


    namespace MathFuncs
    {
    class MyMathFuncs
    {
    public:
    // Returns a + b

    static double Add(double a, double b);
    // Returns a - b

    static double Subtract(double a, double b);
    // Returns a * b

    static double Multiply(double a, double b);
    // Returns a / b

    // Throws DivideByZeroException if b is 0

    static double Divide(double a, double b);
    };
    }

     

    Using approach #1, you'd create a new project using the Visual C++ | ATL | ATL Server project template.  You'd add a new simple ATL object to the project that exported Add, Subtract, Multiply and Divide methods.  You'd #include your static library's header file to provide the underlying implementation of Add, Subtract etc and you'd have your COM object's Add method call the underlying MathFuncs::MyMathFuncs::Add method (and return the result).  Finally, you'd make sure your COM object project linked to your static library .lib file as part of the build process.

    To consume the 'wrapper' from a C# program, you'd use Add | Reference to add a COM reference to your COM object and then just cal the COM object's methods as necessary.

    Using approach #2, you'd create a new project using the Visual C++ | Win32 | Win32 Project template and use Application Settings to change Application Type to DLL and set Additional Options to "Export symbols".  Then you would create some exported entry points (like Add, Subtract etc) to be consumed by the client.  Again, you would #include your static library's header file to get function descriptions and link to the .lib file to get actual implementations.  You'd code your exported DLL entry points to call the static library's 'real'  implementation methods and return the result.

    To consume this kind of wrapper, you would use the C# DllImportAttribute to declare the DLL entry point in C# terms and then just call the function as needed.

    Finally, using appoach #3, you'd create a managed C++ project using Visual C++ | CLR | Class Library.  You'd create a managed class (a 'ref' class) which would be called by your C# client. Again, you'd #include the native code header file and link to the .lib file to get the actual implementation of the methods you want the client to be able to call.  The managed code wrapper for the above header file might look something like this...


    #include "MathFuncsLib.h"

    #pragma once
    using
    namespace System;

    namespace ManagedMathFuncsLib {
    public ref class Class1
    {
       public:
       Class1 ()
       {
       };
       // Returns a + b

       static double Add(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Add (a, b);
       }
       // Returns a - b

       static double Subtract(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Subtract (a, b);
       };
       // Returns a * b

       static double Multiply(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Multiply (a, b);
       };
       // Returns a / b

       // Throws DivideByZeroException if b is 0

       static double Divide(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Divide (a, b);
       };
    };}

     

    To consume this managed code wrapper, you'd use Add | Reference to add a .NET Reference (to your managed wrapper) to your client program and then would call the managed (ref) class's methods as necessary.

    In all three cases above, I simplified things by using static methods in the original native code implementation.  If your static library implements classes with non-static functions then in all three approaches above you would have to conceal a private member variable that pointed to an instance of your native class and would have to new up that instance at some suitable point (in the constructor of the wrapper for example) and would have to use that private member variable to actually invoke the actual implementation of the method you were trying to call.

     

    Wednesday, October 11, 2006 4:43 AM
  • Thank you!!  Before and after posting this question here I had seen several attempts to answer the question.  This answer is the best of the bunch.

    Thanks, thanks, thanks.
    Wednesday, October 11, 2006 4:23 PM
  • Finally, a well structured answer for such issue. Thank you very much.

     

    Thursday, October 12, 2006 10:00 PM
  • Could you go into a little more detail regarding the last paragraph of your post.  I'm unclear as to dealing with functions that are not declared static.  

    Where are you creating the private member?

    How do you invoke that private member, PInvoke?

    Would it be possible to see another example?

    Thanks

    Blue
    Friday, October 13, 2006 5:02 AM
  •  bluesolitare wrote:
    How do you invoke that private member, PInvoke?

    There's no need to use P/Invoke because the wrapper is written in Managed C++ so it can invoke the private member's functions directly.

    Let's change the example slightly and create a statistical functions library that can be used to calculate a number of statistical properties of a group of numbers.  Since I'm lazy I'll just calculate average but you could imagine calculating standard deviation and median and all sorts of things.  To keep the example simple, I'll not store the actual data items, I'll just incorporate them into a sum variable as I go.  Again though you could imagine a much more elaborate data structure underneath this native class.

    The header file for the native code static library implementation of this statistical functions library might look something like this


    // StatFuncsLib.h

    namespace StatFuncs
    {
       class MyStatFuncs
       {
       private:
          double m_Count;
          double m_Sum;
     
       public:
          // Constructs an instance and initialises private members
          MyStatFuncs ();
     
          // Adds item and returns updated count
          double AddItem(double item);
     
          // Returns average
          // Throws DivideByZeroException if count is 0
          double Average ();
     
          // Returns count of items
          double Count ();
       };
    }

     

    The AddItem function will increment m_Count by 1 and will add item to m_Sum while the Average function will return m_Sum divided by m_Count.

    Because data is accumulated in the private member variables m_Count and m_Sum we can't just use static functions, we have to use individual instances of the MyStatFuncs class.  That means when we create our managed C++ wrapper class it will have to create and use an instance of the MyStatFuncs class.  The wrapper class might look something like this


    // ManagedStatFuncsLib.h

    #pragma once
    #include
    "StatFuncsLib.h"

    using namespace System;

    namespace ManagedStatFuncs {
      
       public ref class MyManagedStatFuncs
       {
     
       private:
          StatFuncs::MyStatFuncs * m_NativeStatFuncs;
     
       public:
     
          // Constructs an instance of the class and an instance 
          // of the underlying native class MyStatFuncs
          MyManagedStatFuncs ()
          {
             m_NativeStatFuncs =
    new StatFuncs::MyStatFuncs ();
          };
     
          // Adds item and returns updated count
          double AddItem(double item)
          {
             return m_NativeStatFuncs->AddItem (item);
          };
     
          // Returns average
          // Throws DivideByZeroException if b is 0
          double Average ()
          {
             return m_NativeStatFuncs->Average ();
          };
     
          // Returns count of items
          double Count ()
          {
             return m_NativeStatFuncs->Count ();
          };
       };
    }

     

    The managed C++ wrapper will compile up into an assembly that can be referenced from a C# program (using Add Reference).  Then the C# program just creates instances of the managed wrapper class and invokes the various functions as needed.  For example


    ManagedStatFuncs.MyManagedStatFuncs myStatOne =
       new ManagedStatFuncs.MyManagedStatFuncs();
    ManagedStatFuncs.MyManagedStatFuncs myStatTwo =
       new ManagedStatFuncs.MyManagedStatFuncs();
     
    myStatOne.AddItem(1.0);
    myStatOne.AddItem(3.0);
    myStatOne.AddItem(5.0);
     
    myStatTwo.AddItem(2.0);
    myStatTwo.AddItem(4.0);
    myStatTwo.AddItem(6.0);
    myStatTwo.AddItem(8.0);
     
    Console.WriteLine(
       "First group consists of {0} items with an average value of {1}",
       myStatOne.Count(), myStatOne.Average());
    Console.WriteLine(
       "Second group consists of {0} items with an average value of {1}",
       myStatTwo.Count(), myStatTwo.Average());
     

    Saturday, October 14, 2006 9:24 PM
  • Thank you, AGAIN!!
    • Proposed as answer by JZBMA Friday, June 08, 2012 1:06 PM
    Monday, October 16, 2006 1:55 PM
  • This is a good example! Thanks!

    I am trying to get this code to work on a Pocket PC device. Is it possible to build a managed C++ assembly for the Pocket PC.  So far I have only been able to build the managed C++ assembly for Win32. Visual studio will not let me do Add Reference for a Win32 assembly in C#.  When I try to add reference I get an error saying that ManagedStatFuncs can not be added because it is not a device project. Maybe this is because Win32 managed code is not compatible with compact frameworks. Maybe I need a different project template. Does anyone have any thoughts on this?

     

    Thursday, October 19, 2006 2:52 PM
  • Brian,

    Tactically, adding a question to an already answered thread (like this one) reduces the number of people likely to see your question.  Some people use the 'unanswered' links to skim through new questions that haven't been marked as answered, those people won't even see your question because this thread is already marked as answered.  You might have got an answer sooner if you had posted your question in a new thread.  No big deal, but perhaps worth keeping in mind for the future.

     Brian Wall wrote:
    Is it possible to build a managed C++ assembly for the Pocket PC?

    In a word, no.  I can't find an authoritative reference to cite but if you search the web (or these forums) for "Managed C++" and "Smart Device" you'll find several posts that say it can't be done.  For example this chat transcript

    Q: Will there be support for Managed C++ with .NET CF 2.0?
    A: Sorry, no. Only VB and C#.

    http://msdn.microsoft.com/chats/transcripts/mobileembedded/netcf_020805.aspx

    Thursday, October 19, 2006 5:20 PM
  • Great post.

    I have attempted both approach 2 and 3, and am still having minimal success.  Declaring the ref class/entry points seems straight forward, but I am still in the dark about how to link the .lib file into the picture.  Could you provide some more detail on that step?  This is the first time I have had to deal with this sort of issue.  I appreciate any further explanation you could offer.

    Wednesday, November 29, 2006 7:56 PM
  • The .lib file needs to be linked into the managed wrapper DLL.  The managed wrapper DLL effectively becomes a mixed assembly that has both managed code (visible to the C# code) and native code (the static library).  In VS 2005, you do this by adding "mylib.lib" to the Linker -> Input -> Additional Dependencies.  If the static library is another project in your solution, the linker will find it.  If the static library is not in your solution, but is somewhere else on disk, you might need to add the full path or add the path where it is to the LIBPATH environment variable (this is entered under Linker -> General ->Additional Input Directories in the Project Properties for the managed wrapper project.

    If you're doing this from the command line, just include the static library in the compilation directory and add it to your command line (cl or link command line as appropriate) or set the LIBPATH environment variable directly if needed.

    Gordon

    Wednesday, November 29, 2006 10:25 PM
  • Thanks for the response Gordon.  That post was very helpful.  I am working from VS 2005 attempting to present a C++ API in .lib format to my C# project, to clarify.

    I seem have already run into another issue.  The API I am using takes types (defined in other header/lib files) as input parameters for the High level API I am attempting to integrate.  Here is a quick example:

    The function I am attempting to expose in C# looks somewhat like the following:

    int Encrypt(NativeClass1 seed, NativeClass2 param, unsigned char *buffer);

    I am currently working on this, but I am not sure how the big picture is going to come together.  If I create ref classes for NativeClass1 and NativeClass2, and include them in the same fashion as the highest level API into my C# project, will I be able to pass those types into calls of the ref class?  I am assuming that I will have to include/compile all the libs/headers into one project.  Is this assumption correct?  How will I pass a native class into these calls from my C# app?

    Thoughts?

    Thursday, November 30, 2006 4:09 PM
  • I have a related question.

    I'm using the 3 approach and I don't have the source to the lib.

    I got it to work with trivial classes.  But one of the classes consistantly gives me an error at the end of the programs execution.  It's a memory exception.  "instruction at x tried to reference memory at y.  Memory could not be written"

    My code is rather trivial as i was just trying to get it to work.  It looks likes this:

    namespace Q
    {
        namespace Server
        {
            public ref class Application
            {
            private:
                Q::Application* m_App;

            public:
                Application() 
                {
                    m_App = &Q::Application::app();
                }
            };
        }
    }

     

    my c# main method does nothing more than Q.Application app = new Q.Application();

    the static app() method returns an Q::Application which appears to be allocated from the stack since the header file doesn't define it as a pointer or reference.  So, I should have to do anything to clean it up right?  since I never actually new it.

    So, what could be causing the memory error?

    Sunday, December 10, 2006 7:07 AM
  • These posts really helped me along.

    The only trouble i'm having now are some more complex datatypes than a simple double.
    How would I go if the function in the lib expects some char* which is additionally used as a callback reference?

    The definition of the function from the .libs header file looks like this:

    SCardListReadersA(
        IN      SCARDCONTEXT hContext,
        IN      LPCSTR mszGroups,
        OUT     LPSTR mszReaders,
        IN OUT  LPDWORD pcchReaders);



    Friday, February 01, 2008 11:10 AM
  •  

    Hi,

     

    Char is an integral data type so that isn't too bad.

     

    In C#, you can just pass in a ref to a char array, marshalling it as an LP Array.

     

    ex:

     

     

    C#
    Code Snippet

    [DllImport("lib\\library.dll")]

    private static extern int Startup([MarshalAs(UnmanagedType.LPArray)] byte[] key, int len,  [MarshalAs(UnmanagedType.LPArray)] byte[] ID);

     

     

     

    This passes a pointer to the first char of the array which is stored in contiguous memory.

     

    Code Snippet

    e.g. passed into

     

    Startup(char* key, int len, char* id) 

    {

    // Do something interesting

    }

     

     

     

     

     

    Friday, February 01, 2008 1:48 PM
  • Thanks for the great answer.  Could you elaborate the pros and cons of the three ways?  Thanks again.
     
    Sunday, July 27, 2008 3:43 AM
  •  

     RickW_Houston wrote:
    Without having to go through the entire collection of source files, is there a way to create any kind of project in a .NET language that would provide a "wrapper" for the existing .lib files so that they could be used in that environment.

     

    Yes (sort of) but it's non-trivial.

    Let's start with some background.  Your project to compile to a .lib format is generating something known as a "static library".  Static libraries are chunks of native code built to be combined with other pieces of code via the linker.  You #include a header file that describes the functions/classes that you want to use and then link to the .lib file to provide the implementations of those functions/classes.

    You can't use that approach with a C# client because C# generates managed code and you just can't directly link native code to managed code.

    There are three ways (I can think of) to consume native code from a managed code client

    1. You turn the native code into a native code COM object using the static library to provide the implementation of the COM object's methods and then use COM Interop to invoke the (native) COM object from the managed code client
    2. You turn the native code into a native code DLL that exports some suitable entry points (again, using the static library to provide the actual implementation) and then call those DLL entry points from the managed code client using P/Invoke
    3. You create a managed code Class Library using C++ and use the static library to provide the underlying implementation of that managed class library

    Let's say your static library's header file looks like this

     

       
    namespace MathFuncs
    {
    class MyMathFuncs
    {
    public:
    // Returns a + b

     

    static double Add(double a, double b);
    // Returns a - b

     

    static double Subtract(double a, double b);
    // Returns a * b

     

    static double Multiply(double a, double b);
    // Returns a / b

     

    // Throws DivideByZeroException if b is 0

     

    static double Divide(double a, double b);
    };
    }

     

     

    Using approach #1, you'd create a new project using the Visual C++ | ATL | ATL Server project template.  You'd add a new simple ATL object to the project that exported Add, Subtract, Multiply and Divide methods.  You'd #include your static library's header file to provide the underlying implementation of Add, Subtract etc and you'd have your COM object's Add method call the underlying MathFuncs::MyMathFuncs::Add method (and return the result).  Finally, you'd make sure your COM object project linked to your static library .lib file as part of the build process.

    To consume the 'wrapper' from a C# program, you'd use Add | Reference to add a COM reference to your COM object and then just cal the COM object's methods as necessary.

    Using approach #2, you'd create a new project using the Visual C++ | Win32 | Win32 Project template and use Application Settings to change Application Type to DLL and set Additional Options to "Export symbols".  Then you would create some exported entry points (like Add, Subtract etc) to be consumed by the client.  Again, you would #include your static library's header file to get function descriptions and link to the .lib file to get actual implementations.  You'd code your exported DLL entry points to call the static library's 'real'  implementation methods and return the result.

    To consume this kind of wrapper, you would use the C# DllImportAttribute to declare the DLL entry point in C# terms and then just call the function as needed.

    Finally, using appoach #3, you'd create a managed C++ project using Visual C++ | CLR | Class Library.  You'd create a managed class (a 'ref' class) which would be called by your C# client. Again, you'd #include the native code header file and link to the .lib file to get the actual implementation of the methods you want the client to be able to call.  The managed code wrapper for the above header file might look something like this...

     

       
    #include "MathFuncsLib.h"

     

    #pragma once
    using
    namespace System;

     

    namespace ManagedMathFuncsLib {
    public ref class Class1
    {
       public:
       Class1 ()
       {
       };
       // Returns a + b

     

       static double Add(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Add (a, b);
       }
       // Returns a - b

     

       static double Subtract(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Subtract (a, b);
       };
       // Returns a * b

     

       static double Multiply(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Multiply (a, b);
       };
       // Returns a / b

     

       // Throws DivideByZeroException if b is 0

     

       static double Divide(double a, double b)
       {
          return MathFuncs::MyMathFuncs::Divide (a, b);
       };
    };}

     

     

    To consume this managed code wrapper, you'd use Add | Reference to add a .NET Reference (to your managed wrapper) to your client program and then would call the managed (ref) class's methods as necessary.

    In all three cases above, I simplified things by using static methods in the original native code implementation.  If your static library implements classes with non-static functions then in all three approaches above you would have to conceal a private member variable that pointed to an instance of your native class and would have to new up that instance at some suitable point (in the constructor of the wrapper for example) and would have to use that private member variable to actually invoke the actual implementation of the method you were trying to call.

     

    first of all it's a great solution, but I don't have the header of the library I just have the library itself, any idea to use it within c#

    best regards
    Saturday, September 19, 2009 1:02 PM
  • Without the header you are out of luck.
    The header is more important than you think since it has the proper structures, definitions and prototypes for all of the functions in the library.
    Unless you are able to reproduce the header somehow you shouldn't even consider using this.
    Visit my (not very good) blog at http://c2kblog.blogspot.com/
    Saturday, September 19, 2009 3:56 PM
  • Thanks for your good answer.

     I have a question to your appoach #3.

     If I would like to return std:map<string, CSomeClass> from a method of ref class Class1 is it going to work?

    public ref class Class1

    {

     std:map<string, CSomeClass> SomeFunction(double a, CSomeClass b)

    {return ... }

    }

     My guess is No.  What is the typical solution to handle such issue?  Do I have to make the SomeFunction to be static?

     

    Thanks,

    Allan Tong

    Wednesday, May 12, 2010 6:59 PM
  • Hi,

    I did the 3rd option on 2 LIBs that I have. One of them works perfect but the second doesn't work.

    I get errors:

    Warning 3 warning LNK4248: unresolved typeref token (0100000F) for '_TestHandle'; image may not run omfor.netapproach3.obj omfor.netapproach3

    Error 4 error LNK2028: unresolved token (0A00001B) "enum TestError __cdecl TestOpenW(wchar_t const *,wchar_t const *,struct _TestHandle * *)" (?TestOpenW@@$$FYA?AW4TestError@@PB_W0PAPAU_TestHandle@@@Z) referenced in function "public: wchar_t const * __clrcall omfornetapproach3::Class1::open(wchar_t const *,wchar_t const *)" (?open@Class1@omfornetapproach3@@$$FQ$AAMPB_WPB_W0@Z) omfor.netapproach3.obj omfor.netapproach3

    And more.

    I searched for _TestHandle and I found only his code:

    typedef struct _TestHandle * TestHandle;

    I also tried to write this on a different console application and I got the same error.

     

    Does someone have any idea why it doesn’t work?

    Thanks in advance.

    Yair

    Saturday, September 04, 2010 11:23 PM
  • Hi Frank,

    I am working on a project following your method #3. I have got a problem with the compilation of the project. I am trying to create a CLR C++ DLL that is to be linked to a static library written in unmanaged VC++. The compilation settings for the static library are as below:

    Comfiguration Type: Static library (.lib)

    Use of MFC: Use Standard Windows libraries

    Common Language Runtime Support: No Common Language Runtime Support

    Runtime Library: Multi-threaded Debug (/MTd)

    The static library is properly compiled with VS 2010.

    The compilation settings for the CRL C++ DLL  are as following:

    Comfiguration Type: Dynamic Library (.dll)

    Use of MFC: Use Standard Windows Libraries

    Common Language Runtime Support: Common Language Runtime Support (/clr)

    Runtime Library: Multi-threaded Debug DLL (/MDd)

    I include definitions (header files) of some classes in the native C++ library in the CLR dll. When I compile the dll, I get following error:

    "error C1189: #error :  Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d]"

    The C1189 error orinates in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afx.h.

    Defining _AFXDLL in the code would only result in incompatible errors in the native code of the static library.

    Could anybody provide any clues for figuring out solutions? That will be apprecaited very much.

    Jason

    Friday, June 08, 2012 1:11 PM
  • Don't forget to delete the pointer in the destructor.

        ~MyManagedStatFuncs ()
        {
            delete m_NativeStatFuncs;
        };
    


    Monday, July 30, 2012 9:59 PM
  • I have collection of Object File Libraries ( .lib )

    and a typical header file is listed as below

    --------------- header file ( .h ) ---------------------------------

     

    #include <xxxx.h>
    #include <yyyy.h>

    #ifndef MY_WRITER_H
    #define MY_WRITER_H

    #ifdef __cplusplus
    extern "C" {
    #endif  

    --------- FUNCTION DECLARATIONS ----------------------------

            

    #ifdef __cplusplus
    } /* extern "C" */
    #endif    

    #endif /* MY_WRITER_H */

    How do i generate the corresponding C# .NET Wrapper for the above header file

    Regards,

    Srinivasan


    srinivasansaripalli

    Sunday, March 10, 2013 1:27 AM
  • I have collection of Object File Libraries ( .lib )
     
    and a typical header file is listed as below
    ...
    How do i generate the corresponding C# .NET Wrapper for the above header file
    In future, please do not attach your question to an old (and answered) thread.
     
    Did the answers in this thread not help you?
     
    One way or another, you are going to have to covert the functionality of your .lib into a DLL.
     

    David Wilkinson | Visual C++ MVP
    Sunday, March 10, 2013 11:14 AM
  • the answers in this thread never helped me

    srinivasansaripalli

    Wednesday, March 13, 2013 4:31 PM
  • the answers in this thread never helped me
    Why not? What did you try and what went wrong?
     

    David Wilkinson | Visual C++ MVP
    Wednesday, March 13, 2013 4:38 PM
  • i have a header file as mentioned below

    --------------- header file ( .h ) ---------------------------------

     

    #include <xxxx.h>
    #include <yyyy.h>

    #ifndef MY_WRITER_H
    #define MY_WRITER_H

    #ifdef __cplusplus
    extern "C" {
    #endif  

    --------- FUNCTION DECLARATIONS ----------------------------

            

    #ifdef __cplusplus
    } /* extern "C" */
    #endif    

    #endif /* MY_WRITER_H */

    and also couple of Object File Libraries 

    for this how to generate C# Wrappers and this thread doesnt address my issue


    srinivasansaripalli

    Wednesday, March 13, 2013 4:55 PM
  • for this how to generate C# Wrappers and this thread doesnt address my issue
    I think it does.
     
    The way I would do it is write a C++/CLI class library that exposes a managed interface, and uses your existing native code internally. You can use this managed class library from any .NET language, e.g. C# or VB.NET.
     
    This is option 3 in the comprehensive response by Frank Boyne.
     

    David Wilkinson | Visual C++ MVP
    Wednesday, March 13, 2013 6:11 PM