none
Problem exporting a class that contains __clrcall methods.

    Question

  •   I'm getting compiler error C3395: 'identifier': __declspec(dllexport) cannot be applied to a function with the __clrcall calling convention)

      What I have is an non-managed class (I'm porting a library from another compiler/tool/environment), which is in a CLR-enabled (native) DLL and needs to be exported.  I can export the class without an issue if I don't include 2 methods.  If I have those methods declared I get the above compiler error every time the header is included somewhere in the DLL.

    Roughly speaking it looks like this
    #ifdef _USRDLL
    #define DLL_EXPORT __declspec(dllexport)
    #endif

    class DLL_EXPORT MyClass {
    // ... public:
    #ifdef _INCLUDE_PROBLEM_METHODS
       MyClass::MyClass(System::String^ src);
       System::String^ str();
    #endif
    }

    MyClass::MyClass(System::Strign^ src) {
       for (int i=0; i < src.Length; i++) {
          // append each srcIdea character to MyClass string stuff.
       }
    }

    System::String^ MyClass::str() {
       return gcnew System::String(c_str());
    }

    Like I said this all compiles if I drop the DLL_EXPORT or don't define _INCLUDE_PROBLEM_METHODS, then it compiles, otherwise the above two methods generate the C3395 compiler error.  Is there some way to export that class and still have these methods or functions to make going between MyClass and SystemString easier?  I added the above two methods to make going between an System::String and this class more or less simple.  Not having these functions means I have to do the above 'routines' every time I want to go between System::String and MyClass, and results in really unruly code.

    Thanks,

    Thursday, December 08, 2005 2:56 PM

Answers

  • I am sorry to say that you cannot use dllexport on any method that includes a CLR type in its signature. The reason is that dllexport is a purely native construct and there is no way to support passing a CLR type, like System::String, through the DLL boundary.

    The question I have is do you need to export these specific functions? If you do: then you must have managed code on both side of the DLL boundary so in that casw why not just use a managed type?

    If you don't need to export these specific functions then I would remove the DLL_EXPORT from the class definition and instead just export the functions you need using a *.def file.
    Thursday, December 08, 2005 3:10 PM

All replies

  • I am sorry to say that you cannot use dllexport on any method that includes a CLR type in its signature. The reason is that dllexport is a purely native construct and there is no way to support passing a CLR type, like System::String, through the DLL boundary.

    The question I have is do you need to export these specific functions? If you do: then you must have managed code on both side of the DLL boundary so in that casw why not just use a managed type?

    If you don't need to export these specific functions then I would remove the DLL_EXPORT from the class definition and instead just export the functions you need using a *.def file.
    Thursday, December 08, 2005 3:10 PM
  •  Jonathan Caves MSFT wrote:
    I am sorry to say that you cannot use dllexport on any method that includes a CLR type in its signature. The reason is that dllexport is a purely native construct and there is no way to support passing a CLR type, like System::String, through the DLL boundary.

    The question I have is do you need to export these specific functions? If you do: then you must have managed code on both side of the DLL boundary so in that casw why not just use a managed type?

    If you don't need to export these specific functions then I would remove the DLL_EXPORT from the class definition and instead just export the functions you need using a *.def file.


    Well...  Currently this code is used both in the old environment and is being migrated to VC++.NET, I suppose if I can figure out a way to ifdef the reference type version vs the DLL_EXPORT version than it would be doable.  Otherwise, it'll have to be one of those things that waits until we have completely migrated from the old environment.

    George
    Thursday, December 08, 2005 3:21 PM