同様のプロパティを持つWCFServiceContractがあります。
int P1 { [OperationContract()] get; [OperationContract()] set; }
そして、私はクライアントで同じものが必要ですが、生成されたプロトコルは私に与えます：
get_P1（）メソッドとset_P1（int）メソッドがあるため、毎回手動で別のクラスインターフェイスを作成する必要があります。
int P1 { get { return get_P1() } ; set { et_P1(value) ; }
このようなクラスの作成を自動化するにはどうすればよいですか？
理由：私が編集したいのはインターフェースと実現だけです。他のすべてのものは自動的に生成されます。
ツール（svcutilまたは「サービス参照の追加」）がコントラクトを生成する方法を変更できますが、それは単純ではありません。WSDLインポートとコード生成拡張機能を実装してから、それをツールに接続して、2つのメソッドとプロパティの間で変換する必要があります。http://blogs.msdn.com/b/carlosfigueira/archive/2011/10/18/wcf-extensibility-wsdl-import-and-code-generation-extensions.aspxの投稿には、これらの拡張機能に関する情報がいくつかあります。
もう1つの方法は、サーバーとクライアント間でコントラクトを共有することです。ツールにクライアントプロキシを生成させる代わりに、クライアントプロジェクトでコントラクトファイルをコピー（または参照）するだけです。
だから、あなたはそれを行うことができます。しかし、私はあなたがすべきではないと思います。プロパティは通常、オブジェクト状態の単純なアクセサに関連付けられています。プロパティがあるということは、[OperationContract]プロパティにアクセスするという行為には、完全なネットワークラウンドトリップに加えて、それに伴う追加のシリアル化/パッケージ化/フレーミングの潜在的なコストがかかることを意味します。メソッドは、他のメソッドの呼び出しを含む複数のタスクを実行できる（そしてしばしば実行する）ので、その暗黙の要件はありません。現時点では、プロパティアクセサで運用契約を結んでいるのは理にかなっていますが、コードに不慣れな人はほとんどいないので、将来的にはメンテナンスの問題が発生する可能性があります。