Click here to Skip to main content
Click here to Skip to main content

Visual Studio 2008 SP1 (C#) IDE bug

By , 9 Oct 2008
 

Feel free to download the tiny project for the sample...

Introduction

Before all, this is my very first contribution (and it is NOT a classic application!) and I want to take advantage to thanks many of you that are helping so much the development. I will try hard to write down something useful in the near future, but at the moment I only drop this issue...

Today I have found a dirty bug in the Visual Studio 2008 Sp1 IDE or, at least, in the Visual C# Express since I am using it.

Using the code

The problem itself is tricky, because the (really useful) Intellisense tip showing the value of the variables, just fail on a simple inheritance case.

As you may see on the picture, there are two classes: let B inherited by C.

Now let assuming both B and C have the same property (signature), however with different access modifiers: let the base's property be marked as "virtual" and the derived's one marked as "override".

The "entire" program for test is just below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            C c = new C();
            Console.WriteLine(c.Exec());
            Console.ReadKey();
        }
    }



    class B
    {
        public virtual int Value
        {
            get { return 10; }
        }
    }



    class C : B
    {
        public override int Value
        {
            get { return 5; }
        }


        public int Exec()
        {
            return base.Value; //this correctly returns 10
        }
    }
}
		

If you try to run the program, it outputs correctly "10" in the console window...but, what if you try to walk the code and stop just over the line marked with a remark?

Note: place a breakpoint here:

    ...

        public int Exec()
        {
            return base.Value; //place breakpoint here, then hover it
        }
   
    ...

Here is a simple snapshot of the behavior:

Trick!...the tip shows "5" not "10", as I were typed as:

    ...

        public int Exec()
        {
            return this.Value; //that MUST show 5!
        }
   
    ...

Points of Interest

I am assuming that Visual C# Express has the same "engine" of the bigger brother Visual Studio. I was not able to try this snippet inside the "real" Visual Studio Pro or superior. Please, feel free to feedback any different behavior.

History

First release.

License

This article, along with any associated source code and files, is licensed under A Public Domain dedication

About the Author

Mario Vernari
Software Developer (Senior) CET Electronics
Italy Italy
Member
Played with transistors and ICs before being ten. First approaches to programming (PET Commodore) in the early '80.
Then AppleSoft, TurboPascal, Assembler and VisualBasic.
Currently employed at CET Electronics as lead software developer, involved in creation of industrial control systems.
Loving graphics technologies, I had some great time with SVG.
Since 2006 my primary language is C#, where I am focusing on WPF.

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralEnigm solved!memberMario Vernari9 Oct '08 - 19:32 
I don't know why,but by trying the same game by using methods instead of properties, the debugger (watch) warns about this limitation.
 
A call to a virtual method through the base keyword will always call most derived function while debugging.
 
At this point it could be acceptable, but the same warning should be notified also for properties (and whatever else behaves like).
To the next...
Ciao
GeneralRe: Enigm solved!memberPaw Jershauge13 Oct '08 - 11:31 
well a .Net developer would know that an property is actualy methods, depending on the property level.
 
a GET will resolve in an method <Modifier> <PropertyType> <PropertyName>_get
and a SET will resolve in an method <Modifier> <PropertyName>_set(<PropertyType> Value)
if im not wrong... Shucks | :->
 
And for the syntax engine not to come up with an warning here, is perhaps to spare the delevoper for to much debug info... but thats just me... WTF | :WTF: WTF | :WTF:
 
But in the end problem solved... Wink | ;)
 
With great code, comes great complexity, so keep it simple stupid...Shucks | :-> Shucks | :->

GeneralBase classes are overridden when constructedmemberPaw Jershauge9 Oct '08 - 3:45 
Correct me, if im wrong here, but is it not like this:
 
When constructing an derived class of an base class, the base class members which are overridable will be overridden with data from the derived class and therefor the result is correct when showing 5 untill til Value member of the base class is called.
 
Try setting breakpoint in B class on this line:
return 10;
 
And Correct the Exec call in C class like this:
public int Exec()
{
    int V = base.Value;
    return V;
}
and put breakpoints on both lines.
 
Now look at the order of the breakpoints when you run the program:
- First breakpoint int V = base.Value; base.Value shows 5, correctly
- Second breakpoint return 10; base.Value will now be corrected to 10, as the Value member was "overtaken" overridden by the derived class to show 5
- Third breakpoint return V; V is showing 10, correctly
 
With great code, comes great complexity, so keep it simple stupid...Shucks | :-> Shucks | :->

AnswerRe: Base classes are overridden when constructedmemberGünther M. FOIDL9 Oct '08 - 7:12 
This is correct. So works the inheritance.
GeneralRe: Base classes are overridden when constructedmemberPaw Jershauge9 Oct '08 - 8:24 
Thanks Günther...
 
Then the IDE bug is not correct... there is NO bug. WTF | :WTF: WTF | :WTF: WTF | :WTF:
The tooltip will always show the overridden one, even when its actually another value, since the value wont be changed untill the Method is called. And by method i mean the Value_get() which an get property actually is. WTF | :WTF: WTF | :WTF: WTF | :WTF:
 
With great code, comes great complexity, so keep it simple stupid...Shucks | :-> Shucks | :->

GeneralRe: Base classes are overridden when constructedmemberMario Vernari9 Oct '08 - 17:58 
Hi everyone and thanks for your opinions...
I have been thinking a lot and I have also made some experiments around. I agree that it is NOT a bug, rather a limitation of the CLR (or the language itself)...
The fact is that the keyword "base" give not any reference as "this" does. It means that "base.Value" would act as "gimme the Value property below the current context"...You cannot use the keyword "base" alone.
Of course I agree that if I write:
int v = base.Value;
return v;
But what does it means?
The program runs perfectly: no doubt about the correct inheritance.
What I do NOT like is that both the tip and the watch shows an "unexpected" value...
From my viewpoint, once typing "base.Value" in the watch (if you don't like the tip) the JIT should take care on the inheritance and get the same value would be assigned to the variable "v" in the snippet above.
Nothing more, thanks again.
Cheers
GeneralVS 2005 PromemberMario Vernari9 Oct '08 - 2:35 
It act the same also on VS 2005 Pro/Team: I just have the chance to try on it.
GeneralVisual studio 2008 sp1 development editionmemberMember 26978419 Oct '08 - 2:22 
I can confirm this also exists on the development edition of visual studio 2008 sp1
GeneralConfirmmembercodernix9 Oct '08 - 2:18 
I get the same results in Visual Studio 2008 Team System Development Edition SP1.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web02 | 2.6.130523.1 | Last Updated 9 Oct 2008
Article Copyright 2008 by Mario Vernari
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid