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

G

Guest

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.IControl.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 InterfaceMapTest
{
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.WriteLine("Control.Paint");
}

void IControl.Paint()
{
Console.WriteLine("Control.IControl.Paint");
}
}

class MyControl : Control, IControl
{
}
}
 
G

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 said:
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 said:
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.IControl.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 InterfaceMapTest
{
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.WriteLine("Control.Paint");
}

void IControl.Paint()
{
Console.WriteLine("Control.IControl.Paint");
}
}

class MyControl : Control, IControl
{
}
}
 
J

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] InterfaceMapTest.MyControl obj,
[1] InterfaceMapTest.IControl iControl)
L_0000: newobj instance void InterfaceMapTest.MyControl::.ctor()
L_0005: stloc.0
L_0006: ldloc.0
L_0007: callvirt instance void InterfaceMapTest.Control::paint()
L_000c: ldloc.0
L_000d: stloc.1
L_000e: ldloc.1
L_000f: callvirt instance void InterfaceMapTest.IControl::paint()
L_0014: ret
}

VS2005
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTest.MyControl obj,
[1] InterfaceMapTest.IControl iControl)
L_0000: nop
L_0001: newobj instance void InterfaceMapTest.MyControl::.ctor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: callvirt instance void InterfaceMapTest.Control::paint()
L_000d: nop
L_000e: ldloc.0
L_000f: stloc.1
L_0010: ldloc.1
L_0011: callvirt instance void InterfaceMapTest.IControl::paint()
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 reimplementation 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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
G

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]" said:
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] InterfaceMapTest.MyControl obj,
[1] InterfaceMapTest.IControl iControl)
L_0000: newobj instance void InterfaceMapTest.MyControl::.ctor()
L_0005: stloc.0
L_0006: ldloc.0
L_0007: callvirt instance void InterfaceMapTest.Control::paint()
L_000c: ldloc.0
L_000d: stloc.1
L_000e: ldloc.1
L_000f: callvirt instance void InterfaceMapTest.IControl::paint()
L_0014: ret
}

VS2005
method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 1
.locals init (
[0] InterfaceMapTest.MyControl obj,
[1] InterfaceMapTest.IControl iControl)
L_0000: nop
L_0001: newobj instance void InterfaceMapTest.MyControl::.ctor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: callvirt instance void InterfaceMapTest.Control::paint()
L_000d: nop
L_000e: ldloc.0
L_000f: stloc.1
L_0010: ldloc.1
L_0011: callvirt instance void InterfaceMapTest.IControl::paint()
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 reimplementation 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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.
 
B

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
 
G

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
 
G

Greg Young

Thats the only place I can find it as well although I believe it is also
installed with one of the betas currently out as one of my machines here has
it. I have pushed out a mention that an update may be needed in order to
actually solve this in a "good" way.

Cheers,

Greg
 
G

Guest

Thanks for your investigation Greg and Jeffrey. It's VERY interesting to see
that it behaves "the old way" with 50727.97. The July CTP of Vista includes
that runtime. Jeffrey, we have a large C# application that depends on the
correct way of interface mapping, and I'm very uneasy about simply attempting
to find all the places where I would need to change code to make it work with
2.0.50727.42. Please let me know if Microsoft will be making some sort of
public fix or if I need to create a case with PSS.

Thanks!
 
C

Carl Daniel [VC++ MVP]

Andy said:
Thanks for your investigation Greg and Jeffrey. It's VERY
interesting to see
that it behaves "the old way" with 50727.97. The July CTP of Vista
includes
that runtime. Jeffrey, we have a large C# application that depends
on the
correct way of interface mapping, and I'm very uneasy about simply
attempting
to find all the places where I would need to change code to make it
work with
2.0.50727.42. Please let me know if Microsoft will be making some
sort of
public fix or if I need to create a case with PSS.

You might try requesting the hotfix for KB917782, which appears to include
50727.97 of mscorlib.dll, which is presumably where the fix appears. That
may not be a good solution, but it might be a workable one.

http://support.microsoft.com/kb/917782

-cd
 
J

Jeffrey Tan[MSFT]

Hi Andredem,

Yes, based on the feedback, one C# developer is forwarding my email to
another 3 experts on this topic now, but I still did not get any update
from them.

Anyway, I have just sent another strike email to them, and asked for the
confirmation of whether 2.0.50727.97 version of CLR will fix this problem.
Once, I got the confirmation, which means that this hotfix is the correct
solution, you may just contact Microsoft PSS and request for the hotfix of
KB917782.

I will update any information here ASAP. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
G

Greg Young

Jeffrey,

There has been some other discussion on this ..

While requesting the hotfix will work great for server hosted applications
it would seem to me that there will need to be an update sent out for client
based products where you cannot control the version of the runtime. I guess
one could use the tactic of installing the hotfix with their application but
this seems rather innapropriate and open to numerous other problems
(especially with smart client applications).

Cheers,

Greg
 
J

Jon Skeet [C# MVP]

Greg Young said:
There has been some other discussion on this ..

While requesting the hotfix will work great for server hosted applications
it would seem to me that there will need to be an update sent out for client
based products where you cannot control the version of the runtime. I guess
one could use the tactic of installing the hotfix with their application but
this seems rather innapropriate and open to numerous other problems
(especially with smart client applications).

It certainly seems like a pretty horrible bug :(

Just to remind people who may be worried about this - it's easy to work
out which version you're using - Environment.Version gives you all the
necessary bits.

Still shuddering at this kind of thing making it out of the door
though...
 
B

Brian Gideon

Jon said:
Still shuddering at this kind of thing making it out of the door
though...

Yeah, that's one of the higher profile ones I've seen in awhile.
 
J

Jeffrey Tan[MSFT]

Hi Andredem,

Sorry for the late response. I was out of office yesterday.

Yes, our C# team has confirmed this as a bug of CLR2.0, however, I still
did not get the confirmation of whether KB917782 will have any side-effect.

Currently, I recommend you contact Microsoft PSS for a case support to
obtain a hotfix. Since this issue is confirmed as a bug, this support
incident will be free. I think this is the most efficient way to resolve
your problem.

You can contact Microsoft Product Support by contacting us at
1-(800)936-5800 or by choosing one of the options listed at:
http://www.microsoft.com/services/microsoftservices/srv_support.mspx.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
G

Greg Young

Ok some follow up on this ..

it appears that the hot fix does not fix the problem ... I tested with
2.0.50727.97 in vista which worked. The 2.0.50727.97 version of that hotfix
I am told does not work. This would make the problem that much more
difficult as you can now not even check for an environment version to see if
the system youa re running against has the issue or not.

Cheers,

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top