#pragma mak_public() has strictly no effect RRS feed

  • Question

  • Hi,


    I have been struggling  for hours now with the famous "candidate function(s) not accessible" 


    From what I understood #pragma make_public  should solve this problem but it doesn't.


    Here is the context.

    The structure which is responsible for this pb is from the PKCS#11 library defined in  pkcs11t.h included in cryptoki.h.


    In DLL A:

    #include "cryptoki.h"


    public ref class ClassA



        ClassA(CK_ATTRIBUTE_PTR pAttr, CK_ULONG count)


            // Do something with pAttr





    In DLL B:

    #include "cryptoki.h"


    public ref class ClassB



          static void MyMethod()


                 CK_ATTRIBUTE_PTR pAttr = CK_ATTRIBUTE[] { // Initialisation};

                 ClassA^ classA = gcnew ClassA(pAttr, 1);




    In DLL B I get the anoying "candidate function(s) not accessible candidate function(s) not accessible" error on the constructor of ClassA called in MyMethod.


    In the documentation of MS it is said that #pragma make_public(CK_ATTRIBUTE) should solve the problem.


    Unfortunately using this in DLL A leads to a new error at LINK time Error 1 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001a7). CryptokiAttribute.obj

    and using it DLL B has strictly no effect. 


    Does anyone has already managed to use this s called solution in the above situation.


    PS: Mike Gold if you see this post  I desesperately need some help!


    Wednesday, April 18, 2007 8:54 PM

All replies

  • I've got the same problem, and haven't been able to solve it yet...


    The weird thing is that, in my DLL A, there's one file where I'm already using #pragma make_public successfully. But the other files where I need it generate that link error. I haven't been able to spot any difference between the file in which I'm using it successfully, and the ones where it generates the error...


    Anybody has an idea?

    Wednesday, October 3, 2007 5:59 PM
  • Actually, I fixed the problem by offering a single include entry point for the native types I exposed through make_public : a single header file that contains all the #include needed for the native types, and all the #pragma make_public statement following that. This way, everybody "sees" the native types with they "make_public" metadata. I think the error was because, somehow, some include paths elsewhere ended up with a .obj file having some native types without the "make_public" metadata, and some others with.


    Also, see


    • Proposed as answer by Simon Alford Thursday, June 18, 2009 2:57 PM
    Wednesday, October 3, 2007 6:13 PM