469,282 Members | 2,000 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,282 developers. It's quick & easy.

Virtual Override of "Mixed" method in another assembly.

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
Mar 1 '07 #1
4 2127

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.

Mar 1 '07 #2

"Kevin Frey" <ke**********@hotmail.coma écrit dans le message de news:
eF**************@TK2MSFTNGP05.phx.gbl...
>
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/lib...bw(VS.80).aspx) or use
#pragma make_public (see
http://msdn2.microsoft.com/en-us/lib...07(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
Mar 1 '07 #3
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

"Arnaud Debaene" <ad******@club-internet.frwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...
>
"Kevin Frey" <ke**********@hotmail.coma écrit dans le message de news:
eF**************@TK2MSFTNGP05.phx.gbl...
>>
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/lib...bw(VS.80).aspx) or use
#pragma make_public (see
http://msdn2.microsoft.com/en-us/lib...07(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


Mar 4 '07 #4

"Arnaud Debaene" <ad******@club-internet.frwrote in message
news:O5**************@TK2MSFTNGP05.phx.gbl...
>
"Kevin Frey" <ke**********@hotmail.coma écrit dans le message de news:
eF**************@TK2MSFTNGP05.phx.gbl...
>>
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/lib...bw(VS.80).aspx) or use
#pragma make_public (see
http://msdn2.microsoft.com/en-us/lib...07(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.
>
Arnaud
MVP - VC


Mar 9 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

20 posts views Thread by Raymond Lewallen | last post: by
3 posts views Thread by Stephen Gennard | last post: by
5 posts views Thread by ron jacobs | last post: by
8 posts views Thread by Bern McCarty | last post: by
8 posts views Thread by Nadav | last post: by
9 posts views Thread by Andrew Robinson | last post: by
1 post views Thread by =?Utf-8?B?SmltIFdhbHNo?= | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.