Interface re-implementation changed from 1.0 to 2.0???

[Andy DeMaurice]

Something has changed from C# 1.0 to 2.0 regarding interface
re-implementation. See my sample code below; when compiled and run under VS
2003, you get:

Control.Paint
Control.IContro l.Paint

But when compiled and run under VS 2005: you get:

Control.Paint
Control.Paint

Please explain why in C# 2.0, a class that re-implements an interface
prefers to map to a virtual method of the base class rather than an explicit
implementation of the base class.

Thanks
----
using System;

namespace InterfaceMapTes t
{
class MyApp
{
static void Main(string[] args)
{
MyControl obj = new MyControl();
obj.Paint();

IControl iControl = obj as IControl;
iControl.Paint( );
}
}

public interface IControl
{
void Paint();
}

class Control : IControl
{
public virtual void Paint()
{
Console.WriteLi ne("Control.Pai nt");
}

void IControl.Paint( )
{
Console.WriteLi ne("Control.ICo ntrol.Paint");
}
}

class MyControl : Control, IControl
{
}
}

[Greg Young]

Verified ... quite weird.
"Andy DeMaurice" <an******@noema il.nospamwrote in message
news:04******** *************** ***********@mic rosoft.com...

Something has changed from C# 1.0 to 2.0 regarding interface
re-implementation. See my sample code below; when compiled and run under
VS
2003, you get:

Control.Paint
Control.IContro l.Paint

But when compiled and run under VS 2005: you get:

Control.Paint
Control.Paint

Please explain why in C# 2.0, a class that re-implements an interface
prefers to map to a virtual method of the base class rather than an
explicit
implementation of the base class.

Thanks
----
using System;

namespace InterfaceMapTes t
{
class MyApp
{
static void Main(string[] args)
{
MyControl obj = new MyControl();
obj.Paint();

IControl iControl = obj as IControl;
iControl.Paint( );
}
}

public interface IControl
{
void Paint();
}

class Control : IControl
{
public virtual void Paint()
{
Console.WriteLi ne("Control.Pai nt");
}

void IControl.Paint( )
{
Console.WriteLi ne("Control.ICo ntrol.Paint");
}
}

class MyControl : Control, IControl
{
}
}

[Greg Young]

OK ..

I checked through the spec and couldn't find anything on a quick read
through specifying this had changed so I escalated it to another list.
Should hear something back soon.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

"Andy DeMaurice" <an******@noema il.nospamwrote in message
news:04******** *************** ***********@mic rosoft.com...

Something has changed from C# 1.0 to 2.0 regarding interface
re-implementation. See my sample code below; when compiled and run under
VS
2003, you get:

Control.Paint
Control.IContro l.Paint

But when compiled and run under VS 2005: you get:

Control.Paint
Control.Paint

Please explain why in C# 2.0, a class that re-implements an interface
prefers to map to a virtual method of the base class rather than an
explicit
implementation of the base class.

Thanks
----
using System;

namespace InterfaceMapTes t
{
class MyApp
{
static void Main(string[] args)
{
MyControl obj = new MyControl();
obj.Paint();

IControl iControl = obj as IControl;
iControl.Paint( );
}
}

public interface IControl
{
void Paint();
}

class Control : IControl
{
public virtual void Paint()
{
Console.WriteLi ne("Control.Pai nt");
}

void IControl.Paint( )
{
Console.WriteLi ne("Control.ICo ntrol.Paint");
}
}

class MyControl : Control, IControl
{
}
}

[Greg Young]

OK I think I know what is happenning but I am awaiting confirmation.

I think when you re-implement the interface on MyControl it is seeing the
Paint() method on the base and implementing the interface with it. I have
not been able to find the area of the spec that would define this behavior
but I believe this is the cause of the issue. I will continue digging
through the spec based upon this and let you know if I can come up with
something but immediately you can work around it by not re-implementing the
interface on the derived class which will give the same behavior (except it
works)

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

"Greg Young" <dr************ *******@hotmail .comwrote in message
news:uP******** ******@TK2MSFTN GP05.phx.gbl...

OK ..

I checked through the spec and couldn't find anything on a quick read
through specifying this had changed so I escalated it to another list.
Should hear something back soon.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

"Andy DeMaurice" <an******@noema il.nospamwrote in message
news:04******** *************** ***********@mic rosoft.com...

>Something has changed from C# 1.0 to 2.0 regarding interface
re-implementation. See my sample code below; when compiled and run under
VS
2003, you get:

Control.Pain t
Control.IContr ol.Paint

But when compiled and run under VS 2005: you get:

Control.Pain t
Control.Pain t

Please explain why in C# 2.0, a class that re-implements an interface
prefers to map to a virtual method of the base class rather than an
explicit
implementati on of the base class.

Thanks
----
using System;

namespace InterfaceMapTes t
{
class MyApp
{
static void Main(string[] args)
{
MyControl obj = new MyControl();
obj.Paint();

IControl iControl = obj as IControl;
iControl.Paint( );
}
}

public interface IControl
{
void Paint();
}

class Control : IControl
{
public virtual void Paint()
{
Console.WriteLi ne("Control.Pai nt");
}

void IControl.Paint( )
{
Console.WriteLi ne("Control.ICo ntrol.Paint");
}
}

class MyControl : Control, IControl
{
}
}

[Jeffrey Tan[MSFT]]

Hi Andredem,

Yes, this is really a strange issue. Based on my research, I find that the
C# compiled generated IL is almost the same with VS.net2003 and VS2005:

VS.net2003:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTes t.MyControl obj,
[1] InterfaceMapTes t.IControl iControl)
L_0000: newobj instance void InterfaceMapTes t.MyControl::.c tor()
L_0005: stloc.0
L_0006: ldloc.0
L_0007: callvirt instance void InterfaceMapTes t.Control::Pain t()
L_000c: ldloc.0
L_000d: stloc.1
L_000e: ldloc.1
L_000f: callvirt instance void InterfaceMapTes t.IControl::Pai nt()
L_0014: ret
}

VS2005
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTes t.MyControl obj,
[1] InterfaceMapTes t.IControl iControl)
L_0000: nop
L_0001: newobj instance void InterfaceMapTes t.MyControl::.c tor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: callvirt instance void InterfaceMapTes t.Control::Pain t()
L_000d: nop
L_000e: ldloc.0
L_000f: stloc.1
L_0010: ldloc.1
L_0011: callvirt instance void InterfaceMapTes t.IControl::Pai nt()
L_0016: nop
L_0017: ret
}
As we can see that, .Net2.0 generated IL code emits 1 or 2 more nop
instruction, which does not interrupt the code logic. So the problem should
lie in runtime changes regarding interface reimplementatio n between 1.1 and
2.0 CLR.

I have forwarded this issue to our C# team, I will feedback any progress
here. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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.

[Greg Young]

Jeffrey, I have validated this as a runtime issue. The problem is not
present in later versions of the runtime with the same IL.

I have forwarded it off in hopes of reaching the CLR team.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

""Jeffrey Tan[MSFT]"" <je***@online.m icrosoft.comwro te in message
news:I7******** ******@TK2MSFTN GXA01.phx.gbl.. .

Hi Andredem,

Yes, this is really a strange issue. Based on my research, I find that the
C# compiled generated IL is almost the same with VS.net2003 and VS2005:

VS.net2003:
method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTes t.MyControl obj,
[1] InterfaceMapTes t.IControl iControl)
L_0000: newobj instance void InterfaceMapTes t.MyControl::.c tor()
L_0005: stloc.0
L_0006: ldloc.0
L_0007: callvirt instance void InterfaceMapTes t.Control::Pain t()
L_000c: ldloc.0
L_000d: stloc.1
L_000e: ldloc.1
L_000f: callvirt instance void InterfaceMapTes t.IControl::Pai nt()
L_0014: ret
}

VS2005
method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTes t.MyControl obj,
[1] InterfaceMapTes t.IControl iControl)
L_0000: nop
L_0001: newobj instance void InterfaceMapTes t.MyControl::.c tor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: callvirt instance void InterfaceMapTes t.Control::Pain t()
L_000d: nop
L_000e: ldloc.0
L_000f: stloc.1
L_0010: ldloc.1
L_0011: callvirt instance void InterfaceMapTes t.IControl::Pai nt()
L_0016: nop
L_0017: ret
}
As we can see that, .Net2.0 generated IL code emits 1 or 2 more nop
instruction, which does not interrupt the code logic. So the problem
should
lie in runtime changes regarding interface reimplementatio n between 1.1
and
2.0 CLR.

I have forwarded this issue to our C# team, I will feedback any progress
here. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== =============== =====
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

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.

[Brian Gideon]

Greg,

So are you saying this is a bug? If it's not then I can't imagine why
it would have been changed.

Brian

Greg Young wrote:

Jeffrey, I have validated this as a runtime issue. The problem is not
present in later versions of the runtime with the same IL.

I have forwarded it off in hopes of reaching the CLR team.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

[Greg Young]

I am saying I am not sure but it appears so.

It seems to work differently with the same IL ILASM'ed in 2.0.50727.97 and
2.0.50727.42

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

"Brian Gideon" <br*********@ya hoo.comwrote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Greg,

So are you saying this is a bug? If it's not then I can't imagine why
it would have been changed.

Brian

Greg Young wrote:

>Jeffrey, I have validated this as a runtime issue. The problem is not
present in later versions of the runtime with the same IL.

I have forwarded it off in hopes of reaching the CLR team.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

[Greg Young]

You can also just use the .97 revision of the CLR ... not much help if you
are distributing this app to many users but there is a download for it.

Cheers,

Greg
"Greg Young" <dr************ *******@hotmail .comwrote in message
news:%2******** **********@TK2M SFTNGP04.phx.gb l...

>I am saying I am not sure but it appears so.

It seems to work differently with the same IL ILASM'ed in 2.0.50727.97 and
2.0.50727.42

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

"Brian Gideon" <br*********@ya hoo.comwrote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

>Greg,

So are you saying this is a bug? If it's not then I can't imagine why
it would have been changed.

Brian

Greg Young wrote:

>>Jeffrey, I have validated this as a runtime issue. The problem is not
present in later versions of the runtime with the same IL.

I have forwarded it off in hopes of reaching the CLR team.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

[Greg Young]

More information
http://codebetter.com/blogs/gregyoun...0-runtime.aspx

I believe it is a bug but has been fixed in revision 97.

Cheers,

Greg

"Brian Gideon" <br*********@ya hoo.comwrote in message
news:11******** **************@ e3g2000cwe.goog legroups.com...

Greg,

So are you saying this is a bug? If it's not then I can't imagine why
it would have been changed.

Brian

Greg Young wrote:

>Jeffrey, I have validated this as a runtime issue. The problem is not
present in later versions of the runtime with the same IL.

I have forwarded it off in hopes of reaching the CLR team.

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung