Virtual Override of "Mixed" method in another assembly.

[Kevin Frey]

I have the following situation:

Assembly #1:

class NativeSearchCriteria // NOTE: a native class
{
};

public ref class TheBaseClass
{
public:
virtual void Get_Search_Criteria( NativeSearchCriteria& _Criteria );
};

Assembly #2:

#using <assembly1.dll>

public ref class MyRestriction : TheBaseClass
{
public:
virtual void Get_Search_Criteria( NativeSearchCriteria& _Criteria )
override;
};

Upon compilation of the source-file containing the MyRestriction class, I
get the following error:

warning C4490: 'override' : incorrect use of override specifier;
'Get_Search_Criteria' does not match a base ref class method
'new' or 'override' are only allowed when a matching base method
from a ref class exists

I know for a fact that this is quite doable when there are only managed
types involved, so I think the problem here is related to the presence of a
native type.

Can anyone explain what the problem is, and a solution?

Thanks

Kevin

 

[Kevin Frey]

Okay, after a little investigation:

It would appear that, from looking at the assembly with Reflector, all
native types are compiled as internal.

Hence there would appear to be an explicit firewalling between using the
same native type across an assembly boundary, on account of the native type
being internal to the assembly.

The practical effect is that class A in assembly 1 is considered distinct
from class A in
assembly 2, even though logically they are the same definition.

Fortunately I only have exactly one case where I am passing a native type
across assembly boundaries, and I intend to solve it by wrapping the native
type.

Nonetheless I'd still be interested if others have found alternative
solutions.

 

[Arnaud Debaene]

Okay, after a little investigation:

It would appear that, from looking at the assembly with Reflector, all
native types are compiled as internal.

Hence there would appear to be an explicit firewalling between using the
same native type across an assembly boundary, on account of the native
type being internal to the assembly.

The practical effect is that class A in assembly 1 is considered distinct
from class A in
assembly 2, even though logically they are the same definition.

Fortunately I only have exactly one case where I am passing a native type
across assembly boundaries, and I intend to solve it by wrapping the
native type.

Nonetheless I'd still be interested if others have found alternative
solutions.

Mark the native type as public (see
http://msdn2.microsoft.com/en-us/library/4dffacbw(VS.80).aspx) or use
#pragma make_public (see
http://msdn2.microsoft.com/en-us/library/ms235607(VS.80).aspx)

However, you should be aware that using a native parameter for a public
function is a very bad idea if you want your assembly to be compatible with
other .NET languages.

Arnaud
MVP - VC

 

[Kevin Frey]

Thanks for the reply Arnaud.

You're right. I didn't actually think about the "re-use" aspects of exposing
a public native class. The types of methods I'm referring to would be
categorized as "internal to assembly group" if there were in fact such a way
to express that concept in .NET. In other words, they are a base-class
assembly package that is not necessarily for general consumption by
end-users, but will have multiple "higher-level" assemblies depending on
it. They used to be part of one assembly, and I'm now breaking this assembly
in two, so some methods have had to become public rather than internal as a
result.

For the moment, however, I've just put a wrapper around the object in
question which solves the problem.

Thanks for the pragma option - I'll keep it in mind.

Kevin

 

[Ben Voigt]

Mark the native type as public (see
http://msdn2.microsoft.com/en-us/library/4dffacbw(VS.80).aspx) or use
#pragma make_public (see
http://msdn2.microsoft.com/en-us/library/ms235607(VS.80).aspx)

However, you should be aware that using a native parameter for a public
function is a very bad idea if you want your assembly to be compatible
with other .NET languages.

The assembly will stay compatible, just that class, or possibly only that
method, will only be useable from C++/CLI. Or not? At least the
CLSCompliantAttribute can be specified per-method.