override method without extending visibility

[Ben Voigt]

Is there any way to have an overridden method which is not callable from the
assembly overridding it? A contrived example (though I want this feature,
my program has nothing to do with food service):

Specifically, how can the DemonstrateConditions method be implemented by
GoodEats, so that it can be called by HealthBureau and not by
GoodEatsWaiter?

Assembly A
{
public class HealthInspector
{
}

public abstract class LicensedEstablishment
{
internal abstract void DemonstrateConditions(HealthInspector);
}

public static class HealthBureau
{
public static void Complain(LicensedEstablishment restaurant)
{
HealthInspector h = GetResponsibleInspector();
restaurant.DemonstrateConditions(h);
}
}
}

Assembly B references A
{
public class GoodEats : LicensedEstablishment
{
// yikes!
}
internal class GoodEatsWaiter {}
}

[Ben Voigt]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:e4**************@TK2MSFTNGP04.phx.gbl...

Is there any way to have an overridden method which is not callable from
the assembly overridding it? A contrived example (though I want this
feature, my program has nothing to do with food service):

Specifically, how can the DemonstrateConditions method be implemented by
GoodEats, so that it can be called by HealthBureau and not by
GoodEatsWaiter?

The help for CS0507 suggests I can accomplish this by declaring the base
method "protected internal" and the override as "protected"... however
CS0507 is still generated.

>
Assembly A
{
public class HealthInspector
{
}

public abstract class LicensedEstablishment
{
internal abstract void DemonstrateConditions(HealthInspector);
}

public static class HealthBureau
{
public static void Complain(LicensedEstablishment restaurant)
{
HealthInspector h = GetResponsibleInspector();
restaurant.DemonstrateConditions(h);
}
}
}

Assembly B references A
{
public class GoodEats : LicensedEstablishment
{
// yikes!
}
internal class GoodEatsWaiter {}
}

[Ben Voigt]

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>
"Ben Voigt" <rb*@nospam.nospamwrote in message
news:e4**************@TK2MSFTNGP04.phx.gbl...

>Is there any way to have an overridden method which is not callable from
the assembly overridding it? A contrived example (though I want this
feature, my program has nothing to do with food service):

Specifically, how can the DemonstrateConditions method be implemented by
GoodEats, so that it can be called by HealthBureau and not by
GoodEatsWaiter?

The help for CS0507 suggests I can accomplish this by declaring the base
method "protected internal" and the override as "protected"... however
CS0507 is still generated.

Filing a bug because the C# compiler clearly does not implement the behavior
indicated by the CS0507 help page.

https://connect.microsoft.com/Visual...dbackID=236091

>

>>
Assembly A
{
public class HealthInspector
{
}

public abstract class LicensedEstablishment
{
internal abstract void DemonstrateConditions(HealthInspector);
}

public static class HealthBureau
{
public static void Complain(LicensedEstablishment restaurant)
{
HealthInspector h = GetResponsibleInspector();
restaurant.DemonstrateConditions(h);
}
}
}

Assembly B references A
{
public class GoodEats : LicensedEstablishment
{
// yikes!
}
internal class GoodEatsWaiter {}
}

[Arne Vajhøj]

Ben Voigt wrote:

Filing a bug because the C# compiler clearly does not implement the behavior
indicated by the CS0507 help page.

Before filing a bug report, then why not post some
real code that would give people a fair chance to comment ??

Arne

[Walter Wang [MSFT]]

Hi Ben,

I'm not sure I fully understand your question, so please feel free to let
me know.

Per your question:

==========
Specifically, how can the DemonstrateConditions method be implemented by
GoodEats, so that it can be called by HealthBureau and not by
GoodEatsWaiter?
==========

I think that using "protected internal" on the method should be ok for your
requirement. "protected" means it can only be called by inheriting classes.
"internal" means can only be called by the declaring assembly (in this
case, is assembly A). Combining them means it can be called by inheriting
classes or classes in the same assembly.

When you inherit this class in assemly B, you will notice the overridden
method only has signature "protected", we're not allowed to use "internal"
here because "internal" to assembly B means it's callable in assembly B
which will change the visibility and violates compiler error CS0507.

So I think the documentation os CS0507 is correct here.

Please let me know if my understanding of your question is correct or not.
Thanks.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Marc Gravell]

If I understand your non-code, then your interpretation is incorrect;
"protected internal" allows inherited OR same-assembly access, not AND.

Marking HealthBureau.Complain as sealed will prevent the downstream classes
from further overriding, but that doesn't sound like quite what you want...

Marc

[Ben Voigt]

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:l3**************@TK2MSFTNGXA01.phx.gbl...

Hi Ben,

I'm not sure I fully understand your question, so please feel free to let
me know.

Per your question:

==========
Specifically, how can the DemonstrateConditions method be implemented by
GoodEats, so that it can be called by HealthBureau and not by
GoodEatsWaiter?
==========

I think that using "protected internal" on the method should be ok for
your
requirement. "protected" means it can only be called by inheriting
classes.
"internal" means can only be called by the declaring assembly (in this
case, is assembly A). Combining them means it can be called by inheriting
classes or classes in the same assembly.

When you inherit this class in assemly B, you will notice the overridden
method only has signature "protected", we're not allowed to use "internal"
here because "internal" to assembly B means it's callable in assembly B
which will change the visibility and violates compiler error CS0507.

So I think the documentation os CS0507 is correct here.

I agree that this interpretation of "protected internal" with a "protected"
override is designed for this situation. However, the compiler (C# 2.0 with
SP1 beta) doesn't actually behave as advertised. CS0507 is generated when
the override is "protected", and it only compiles when the override is
"protected internal" (accessible from assembly B, NOT what I want).

I've worked around this by making the virtual function protected, and
defining an internal shim method.

>
Please let me know if my understanding of your question is correct or not.
Thanks.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your
reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Marc Gravell]

However, the compiler (C# 2.0 with

SP1 beta) doesn't actually behave as advertised.

In the definition
(http://msdn2.microsoft.com/en-us/lib...8b(VS.80).aspx) the key
phrase is "defined in referenced metadata" - i.e. separate assemblies.
The "internal" aspect doesn't make it past the assembly edge.

Marc

[Marc Gravell]

To clarify - by this I mean that within a single assembly you are bound
by the first condition (changing access), not the second (specifically
relating to protected internal in referenced metadata).

Marc

[Walter Wang [MSFT]]

Hi Ben,

I'm not sure if I understood you correctly, do you mean that having:

virtual protected internal void M() {}

in assembly A, and in assembly B:

protected override internal void M() {}

works while:

protected override void M() {}

doesn't work?
I just verified that on VS2005 and VS2005+SP1 Beta, both indicates only:

protected override void M() {}

works, which is the behavior as documented in compiler error CS0507.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Ben Voigt]

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:yM**************@TK2MSFTNGXA01.phx.gbl...

Hi Ben,

I'm not sure if I understood you correctly, do you mean that having:

virtual protected internal void M() {}

in assembly A, and in assembly B:

protected override internal void M() {}

works while:

protected override void M() {}

doesn't work?

Yes, I mean exactly that. Only, my base method is pure as well as virtual
(using abstract keyword).

public abstract class IHandlespace

{

....

protected internal abstract void OnEndEpisode();

//internal void EndEpisode() { OnEndEpisode(); }

}

internal sealed class Handlespace : IHandlespace

{

....

override public event HandlespaceHandler EpisodeEnded;

protected override void OnEndEpisode()

{

if (EpisodeEnded != null)

EpisodeEnded(this);

}

}
error CS0507: '....Handlespace.OnEndEpisode()': cannot change access
modifiers when overriding 'protected internal' inherited member
'.....IHandlespace.OnEndEpisode()'

>
I just verified that on VS2005 and VS2005+SP1 Beta, both indicates only:

protected override void M() {}

works, which is the behavior as documented in compiler error CS0507.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Ben,

Is Handlespace in the same assembly as IHandlespace? If this is the case,
the "internal" is required because without it it will change the
accessibility of the method.

If it's in another assembly, then the "internal" should be removed as I
described in my previous reply.

Would you please help me confirm this behavior? Thanks.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Ben Voigt]

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:6$**************@TK2MSFTNGXA01.phx.gbl...

Hi Ben,

Is Handlespace in the same assembly as IHandlespace? If this is the case,
the "internal" is required because without it it will change the
accessibility of the method.

If it's in another assembly, then the "internal" should be removed as I
described in my previous reply.

Would you please help me confirm this behavior? Thanks.

Two different assemblies, however there is also an
InternalsVisibleToAttribute in play.

>
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Ben,

Thanks for letting us know that you're also using
InternalsVisibleToAttribute. I'm sorry that I haven't taken this attribute
into account in my previous replies. However, I think the compiler behavior
is still correct here, although the documentation of CS0507 should mention
this attribute. I mean, when you make the first assembly internal
classes/methods visible to second assembly, overriding the method will
certainly need to keep the internal modifier just as if you're overriding
it in the same assembly.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.