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

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 m开发者_StackOverflowe 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.

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

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.)

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

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

So the suggested refactoring is valid.

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.

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.

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.

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?