Auto Property - Resharper error or Cool Unknown C# Feature?

Question

I have the following code:

public interface IMyInterface
{
    DataGrid ItemsInGrid { get; set; }
}

partial public class MyClass: Window, IMyInterface
{
   public DataGrid ItemsInGrid 
   {
       get { return grdItemsInGrid}
       set { grdItemsInGrid= value; }
   }
}

In a Different file:

partial public class MyClass: Window
{
   private System.Windows.Forms.DataGrid grdItemsInGrid;

   // Reference to private variable here
   // This is the designer portion that actually sets up the 
   // private variable to be shown on the form.
}

Now resharper wants me to convert ItemsInGrid to an autoproperty (public DataGrid ItemsInGrid{ get; set; })

How can this be an equal transformation? An autoproperty would create a hidden backing variable that would not match up to the private grdItemsInGrid right?

Is resharper broken? or is there something in C#.NET that I am not aware of?

---

EDIT: I am sensing a common miss-communication here. grdItemsInGrid is a grid that is displayed on a form (MyClass actually implements Window). The idea is to grant access to grdItemsInGrid to scenarios where MyClass is passed as an IMyInterface to a method.

Answer 1

It is an equal transformation. You're exactly right about it using a hidden backing variable.

Here's the MSDN page on the language feature: http://msdn.microsoft.com/en-us/library/bb384054.aspx

Answer 2

Autoproperties remove the need for a visible backing variable. Nothing is broken here. It's just a very convenient feature.

Answer 3

Have you tried it? Maybe it is going to delete the grdItemsInGrid and then fix up any references to it so that they instead use the property.

Answer 4

I don't see your issue? No, the autoproperty would not match grdItemsInGrid, but for what would you need grdItemsInGrid? Your class would interact with ItemsInGrid directly as you don't have access to the hidden backing field, but in your logic you don't need that access anyway.

Answer 5

Your interface contract defines the name of a property, not the private backing variable.

So the suggested refactoring is valid.

Answer 6

Auto property is a VS 2008 feature that prevent lazy programmers (like me ;) ) to use public fields in their classes and compiler will do the job for you (behind the scene as you said) and there will be a private variable backing your property (you can use Reflector to see what's happening) As long as implicit interface implementation cares there should be a property with the given name declared in your class it doesn't matter if it's auto property or not.

Answer 7

If you're not going to do anything special with that private field, you can safely accept resharper's suggestion. It will work exactly the same way. I'm not sure if reshaper will remove the private member in your case, since is named grdItemsInGrid and not itemsInGrid.

Answer 8

As far as I can see this is a bug in resharper. The private variable in question is a element on a form. I did not show this because I did not realize it was relevant. Because the form stuff is in a different file (it is a partial class). Resharper does not realize that the private variable is being referenced and thinks I can just go to an auto property.

Once I referenced the private variable in the same file then ReSharper stopped hinting that I should convert to an auto property. (But it did not realize that it was referenced in the partial class for purposes of this refactor.)

Answer 9

There is no logic involved in either setter or getter. So how on earth could this refactoring change your code in any way?

ReSharper knows this and will show you the refactoring in question because it is an obvious one.

What makes you think, there's any change in how your code behaves?