Q:

Why does updating a WCF service reference append a number to a property?

Looking at the generated Reference.cs file for the request, there is a property:
    [System.Runtime.Serialization.DataMemberAttribute()]
    public TestClass1 TestClass {
        get {
            return this.TestClassField;
        }
        set {
            if ((object.ReferenceEquals(this.TestClassField, value) != true)) {
                this.TestClassField = value;
                this.RaisePropertyChanged("TestClass");
            }
        }
    }

With another property:
    [System.Runtime.Serialization.DataMemberAttribute()]
    public TestClass TestClass {
        get {
            return this.TestClassField;
        }
        set {
            if ((this.TestClassField.Equals(value) != true)) {
                this.TestClassField = value;
                this.RaisePropertyChanged("TestClass");
            }
        }
    }

That references the same field. When I try to consume this field:
var sampleRequest = new SampleRequest();
sampleRequest.TestClass = new global::SampleService.TestClass();

An error is thrown:
Cannot convert source type TestClass to TestClass1.
sampleRequest.TestClass has type TestClass and, instead of referencing the unappended property, it is referring to TestClass1. Why does this happen? Is there a way to suppress this behavior?

A:

I would say you're falling victim to their contract. Someone has decorated two properties with the same name (and the references are being generated based on that). Something like the following is most likely happening:
// The original written application had the following class, but then
// deprecated it (maybe they changed around object, changed interfaces,
// who knows. It just got deprecated internally.)
// So, with all the ties in the system, they probably retained the name,
// but renamed it in the contract.
[Obsolete]
[DataContract(Name = "TestClass1")]
public class TextClass // The class formerly known as TestClass
{
}

// This is the refactored TestClass that should be used from here on out.
// They most likely created a new class with a similar name which lent
// itself to being plumbed in a modular fashion (but wanted the same name
// to any service consumers)
[DataContract(Name = "TestClass")]
public class TestClassNew
{
}

// DTO
[DataContract]
public ParentClass
{
    // Keep the old reference (may still have back-references or
    // functionality that hasn't been migrated). However, they should have
    // also renamed the "Name").
    [DataMember(Name = "TestClass")]
    public TestClass TestClass { get; set; }

    // The new object that now shares the same name.
    [DataMember(Name = "TestClass")]
    public TestClassNew TestClassNew { get; set; }
}

Which would result, on the client, in having two properties with the same name.

