Candidate function(s) not accessible strange case

When trying to call a __gc class static function in an assembly which has CLR and non-CLR types in its signature, I get a Candidate function(s) not accessible error.

In an assembly, using /clr:oldSyntax:

TSEShared.h
--------------

// TSEShared.h
#pragma once
#include <string>
using namespace System;
namespace TSEShared {
public __gc class Global
{
public:
static std::string ToCppString(System::String *);
};
}

TSEShared.cpp
----------------

#include "stdafx.h"
#include "TSEShared.h"
std::string TSEShared::Global::ToCppString(System::String * str)
{
if (str == 0)
{
return(std::string());
}
System::IntPtr ptr(System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(str));
std::string ret(static_cast<const char *>(static_cast<void *>(ptr)));
System::Runtime::InteropServices::Marshal::FreeCoTaskMem(ptr);
return(ret);
}

Called from another assembly using /clr:oldSyntax

UseTSEShared.h
------------------

#pragma once
//#include <string>
//---------------------------------------------------------------------------
namespace UseTSEShared
{
public __gc class SomeClass {
public:
SomeClass();
};
}

UseTSEShared.cpp
--------------------

#include "stdafx.h"
#include "UseTSEShared.h"
UseTSEShared::SomeClass::SomeClass()
{
TSEShared::Global::ToCppString(0); // compiler error on this line
}

I do not see the reason why

I am trying to create resuable functions in an assembly which have mixed types in its signature. Clearly this should be doable. When I tried it with a __nogc class, I received an error that functions with clr calling conventions can not be exported. Now that I try it with a __gc class, I receive this error.

Answer this question

Candidate function(s) not accessible strange case

SeeBee
I think the core issue here is that you are returning a native class from the managed method. I don't know how well that works out. Check the IL for that assembly. It may have created a new value class that wraps or rather represents the string class. And that class may not be accessible outside the assembly.
krus

By reporting the bug, the owners will take a look straight ahead and hence answer most of your questions as soon as they can.If that is a limitation that they were aware of (by design) then they would be able to suggest how to get around it.

Thanks,

Ayman Shoukry

VC++ Team
MohammadSamara
I forgot to mentuion that there is a reference to TSEShared in the UseTSEShared project. For .NET classes, of course, one does not use #includes, as I am sure you know.
Mike Bouck
The problem would then be that one can not pass or return non-CLR classes between assemblies from within __gc classes, and that one can not pass or return CLR classes between assemblies from within __nogc classes, because of the error that functions with a clr calling convention can not be exported. It then becomes unfortunately apparent that one can not create a function in an assembly, with both CLR and non-CLR types in its signature, which can be reused by other assemblies. That seems to be a severe imposition in C++ .NET programming.
BadMojo
The reported bug is at http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=3fd8d69d-ce42-493f-a61b-47b681125864
Dylan McAtee
OK, I will report it but it does not help me with the present release. I guess I will have to propagate my mixed mode functionality to ever assembly that wants to use it. BTW the mixed mode functions which I have written, like the one I gave in the example for this thread, convert back and forth between CLR String * and std::string, and between a CLR String * and a std::wstring. That is a pretty common necessity, in my eyes, when doing mixed mode C++ programming and wanting to use C++ string classes to manipulate strings for their richer functionality than CLR String.

Your reply means to me that you and the VC++ team understand that what I describe above can not be done in Visual Studio 2005 C++, essentially having a re-usable function in an assembly whose signature has mixed mode types.

Were you aware of this before you put out the product, or has my report just made you aware of this limitation If you were aware of this, did any of the VC++ developers suggest that such a limitation was not good for VC++ when programmed in .NET

I am curious, because in Visual Studio 2003 one could export a function which had CLR types in its signature, although there the C++ loader lock problem made any mixed mode DLL written in C++ pretty chancy to use. While you solved the loader lock problem, Visual Studio 2005 no longer allows a function to be exported which has a CLR type in its signature and now the problem I discuss here exists because of it. While I like the idea that I can now create assemblies in C++ doing mixed mode programming, naturally I do not enjoy this new limitation of C++ .NET programming.
tom_g

Thanks!

Could you please post a link to the bug reported so that others can follow up on the status of the issue in the furture

Thanks,

Ayman Shoukry

VC++ Team
Keith Buik
What happens if you uncomment the #include <string> in your client code
Alexey Monastyrsky
I didn't sse that you includes the TSEShared header file. Neither you are "using" this assembly.
nelson rodriguez

Could you report the issues at http://lab.msdn.microsoft.com/productfeedback/default.aspx and describe why that would be an interesting scenario for you. I am sure that could help us planning for next versions.

Thanks,

Ayman Shoukry

VC++ Team
WendellwithSBSatMS
The bug has been reported.
abrewerton
The same error occurs.
Candidate function(s) not accessible strange case

Answer this question