Introduction

In C#, the new keyword on a property declaration means "this member hides an inherited member with the same name." It does not override the base property, and it does not change runtime polymorphism the way override does. That distinction is the entire point of the feature, and misunderstanding it leads to subtle bugs.

What new Means on a Property

Suppose a base class defines a property:

1public class Animal
2{
3    public string Name { get; set; } = "animal";
4}

Now a derived class declares another property with the same name:

1public class Dog : Animal
2{
3    public new string Name { get; set; } = "dog";
4}

The new keyword tells the compiler that this is intentional member hiding. The Dog.Name property hides Animal.Name when the reference type is Dog.

That is not the same as replacing the base member globally.

Hiding Versus Overriding

The easiest way to see the difference is through reference types:

1Animal animalRef = new Dog();
2Dog dogRef = new Dog();
3
4Console.WriteLine(animalRef.Name);
5Console.WriteLine(dogRef.Name);

With new, these references can resolve to different properties because lookup depends on the compile-time type of the variable:

• 'animalRef.Name uses Animal.Name'
• 'dogRef.Name uses Dog.Name'

That behavior surprises people who expected polymorphism.

If you want polymorphic behavior, the base property must be virtual, and the derived property must use override:

1public class Animal
2{
3    public virtual string Name { get; set; } = "animal";
4}
5
6public class Dog : Animal
7{
8    public override string Name { get; set; } = "dog";
9}

Now both references use the overridden property implementation.

Why the Compiler Warns Without new

If you declare a same-named member in the derived class without new, C# gives a warning. The compiler is telling you:

• either you meant to override and forgot
• or you meant to hide and should say so explicitly

Example:

1public class Dog : Animal
2{
3    public string Name { get; set; } = "dog";
4}

This compiles with a warning because the language wants you to acknowledge the hiding behavior intentionally.

Adding new does not change runtime magic. It mainly makes the hiding explicit and silences the warning.

When Hiding a Property Makes Sense

Using new is relatively uncommon, but it can make sense when:

• the base member is not virtual
• you cannot modify the base type
• the derived API needs a same-named member with different semantics

For example, a framework base class may expose a property that you want to replace at the derived API surface for convenience, even though true overriding is unavailable.

Still, this is usually a sign to slow down and ask whether the API is becoming confusing.

Why new Can Be Dangerous

Because hidden members depend on reference type, the same object can appear to have different values depending on how it is referenced.

Example:

1public class Animal
2{
3    public string Name { get; set; } = "animal";
4}
5
6public class Dog : Animal
7{
8    public new string Name { get; set; } = "dog";
9}
10
11Dog dog = new Dog();
12Animal animal = dog;
13
14dog.Name = "Rex";
15animal.Name = "BaseName";
16
17Console.WriteLine(dog.Name);    // Rex
18Console.WriteLine(animal.Name); // BaseName

These are two distinct properties stored separately. That is often more confusing than people expect.

Property Hiding Is Not Limited to get and set

The same hiding behavior applies regardless of whether the property is:

• auto-implemented
• computed
• read-only
• write-only

The key fact is the member name and inheritance relationship, not the property body style.

So this also hides:

1public class Dog : Animal
2{
3    public new string Name => "dog";
4}

The property form changes, but the hiding rule does not.

Prefer override When the Design Calls for Polymorphism

If the conceptual intent is "derived types should customize the base property," then virtual plus override is almost always the better design.

Use new only when you genuinely want name hiding. That is a narrower and more specialized tool.

A good rule of thumb is:

• use override for substitutability
• use new for explicit hiding when override is not the right model

If you cannot explain why the member should be hidden rather than overridden, new is probably the wrong answer.

Common Pitfalls

The biggest mistake is using new when the real goal was polymorphic behavior. Hidden members are selected by reference type, not by runtime dispatch.

Another issue is forgetting that the base and derived properties can hold different values. That can create debugging confusion because the object appears inconsistent depending on how it is accessed.

Developers also sometimes add new just to silence the compiler warning without understanding the API consequence. That fixes the warning, not the design.

Finally, if the base property is meant to be customizable, prefer virtual and override instead of hiding. The resulting code is usually clearer and safer.

Summary

• 'new on a property means the derived property hides an inherited property with the same name.'
• Hiding is not overriding, and it does not use runtime polymorphism.
• Hidden member lookup depends on the compile-time type of the reference.
• Use override when you want polymorphic behavior and new only when you intentionally want hiding.
• If a hidden property creates confusion, the API design is usually the real problem.