locked
function compiled as native, Reflection and BadFileFormatException RRS feed

  • Question

  • Here is the setup
    Visual Studio 2010, .Net 4.0
    • Core.lib - a native C++ project that uses Boost and compiles to a static library
    • Interface.dll - a managed C++ project the 'wraps' Core, compiles into a single .dll
    • Addin.dll - a C-sharp project that creates instances of classes in Interface vai Reflection.
    This was all working fine until the Core project started using parts of Boost that are not compatible with CLR. When building Interface.dll, I get a number of warnings like this:
    2>c:\program files (x86)\boost\boost_1_44\boost\signals2\deconstruct_ptr.hpp(36): warning C4793: 'boost::signals2::detail::do_postconstruct' : function compiled as native :
    2>   varargs not supported under /clr
    But it does build. 
    The C# DLL also builds fine.
    I try to create an instance of a class in Interface.dll via reflection: Type->GetContructor->Invoke. It produces this exception:
    BadImageFormatException: Could not load file or assembly 'Interface.dll' or one of its dependencies.  is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
    If I switch the linker options on Interface.dll as follows:
    Fixed Base Address -> Yes
    Randomzied Base Address -> No
    The run-time error changes to:
    FileLoadException: Could not load file or assembly 'Interface.dll' or one of its dependencies. Attempt to access invalid address. (Exception from HRESULT: 0x800701E7)
    As I mentioned, everything was working fine with this setup until the Core project started using additional portion of Boost and those 'compiled as native' warnings began appearing.
    Any recommended solutions? I would rather not have to seperate Core into a seperate unmanaged assembly - although I'm not even sure that will work. Please let me know if you need any other info about my setup.
    Thanks.
    Friday, April 22, 2011 1:41 PM

All replies

  • What is your target CPU type of the C# dll?

    What is the target CPU type of your C++/CLI dll and core lib?



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Friday, April 22, 2011 7:33 PM
  • 32-bit / x86 for all.

    Though it is running on Windows XP 64-bit Pro.

    Friday, April 22, 2011 9:18 PM
  • What is the configuration for /CLRIMAGETYPE (Specify Type of CLR Image) in the C++/CLI project?

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Friday, April 22, 2011 9:42 PM
  • "Default Image Type"

     

    Thanks.

    Sunday, April 24, 2011 1:44 AM
  • You get this compiler warning when a class is tried to be compiled as managed but some C++ constructs cannot be expressed in managed code hence this warning. You must take care that your managed wrapper does not include any of your C++ header files. In your managed wrapper only standard types and include header should be visible. The parts which uses boost must be included in your cpp file where the implementation of your wrapper resides. This is a receipe for compiling warning free and you will get a working executable.

     

    Yours,

       Alois Kraus

     

    Monday, April 25, 2011 6:53 AM
  • Thanks Alois.

    I'm trying to implement your suggestion, but I think I have a problem. The declaration of the unmanaged class includes references to unsupported types - not just the implementation of the class. Would your solution still work? 

    E.g.:

    Native.h:

    #include "NonCLRSupportedLibrary.h"

    class nativeClass

    {

    private NonCLRSupportedType member_;

    };

     

    Managed.h:

    #include "Native,h"   // is this a problem right here? 

    class ManagedWrapper

    {

    private nativeClass* ntvClass_;

    }

    Wednesday, April 27, 2011 1:16 PM
  • Do we have a sample available - one which will reproduce the issue? That would help. This following option might be helpful as well:

     

    “Reflecting on C++ executable files may throw this exception. This is most likely caused by the C++ compiler stripping the relocation addresses or the .Reloc section from the executable file. To preserve the .relocation address in a C++ executable file, specify /fixed:no when linking” (http://msdn.microsoft.com/en-us/library/k7137bfe.aspx)


    --Trevor H.
    Send files to Hotmail.com: "MS_TREVORH"
    Monday, May 16, 2011 3:49 PM