1

VB.NET (Visual Studio 2008 を使用) では、私の WCF サービスには次のようなインターフェイスがあります。

<ServiceContract()> _
Public Interface IThingService
    <OperationContract()> _
    Function GetThingByNumber(ByVal thingNumber As MyKeyClass) As Thing
    <OperationContract()> _
    Function GetThing(ByVal thingId As Guid) As Thing

    ' ...

End Interface

最近、同様のコードを持つ 2 つのプロジェクトを、wsHttpBinding ではなく basicHttpBinding を使用するように変更しました。すべてがサービス側でうまくコンパイルされます。次に、クライアント アプリで [Update Service Reference] を選択します。あるプロジェクトでは、結果の reference.vb は正しいように見えます。各メソッドの単純なラッパーを使用して 100 行未満です。ただし、他の例では、結果として得られる reference.vb は、サービスが何であるかを理解できないようです。次のような1000行を超えるreference.vbを取得します。

 '------------------------------------------------------------------------------
 ' <auto-generated>
 '     This code was generated by a tool.
 '     Runtime Version:2.0.50727.3053
 '
 '     Changes to this file may cause incorrect behavior and will be lost if
 '     the code is regenerated.
 ' </auto-generated>
 '------------------------------------------------------------------------------
 Option Strict On
 Option Explicit On
 Imports System.Data
 Namespace ThingService

 <System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0"),  _
 System.ServiceModel.ServiceContractAttribute(ConfigurationName:="GetThingByVersion.IGetThingByVersion")>  _
 Public Interface IThingService

    'CODEGEN: Parameter 'GetThingByNumberResult' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
    <System.ServiceModel.OperationContractAttribute(Action:="http://tempuri.org/ThingService/GetThingByVersion", ReplyAction:="http://tempuri.org/ hingService/GetThingByVersionResponse"),  _
     System.ServiceModel.XmlSerializerFormatAttribute()>  _
    Function GetThingByNumber(ByVal request As ThingService.GetThingByVersionRequest) As ThingService.GetThingByVersionResponse

    'CODEGEN: Parameter 'GetThingResult' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
    <System.ServiceModel.OperationContractAttribute(Action:="http://tempuri.org/ThingService/GetThing", ReplyAction:="http://tempuri.org/ThingService/GetThingResponse"),  _
     System.ServiceModel.XmlSerializerFormatAttribute()>  _
    Function GetThing(ByVal request As ThingService.GetThingRequest) As ThingService.GetThingResponse
'...
End Interface

 '''<remarks/>
 <System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.3082"),  _
 System.SerializableAttribute(),  _
 System.Diagnostics.DebuggerStepThroughAttribute(),  _
 System.ComponentModel.DesignerCategoryAttribute("code"),  _
 System.Xml.Serialization.XmlTypeAttribute([Namespace]:="http://schemas.datacontract.org/2004/07/ThingLibraryCore")>  _
 Partial Public Class MyKeyClass
    Inherits Object
    Implements System.ComponentModel.INotifyPropertyChanged

    Private concatenatedThingNumberField As String
    Private ThingNumberField As Integer
    Private ThingNumberFieldSpecified As Boolean

 '... goes on and on...

生成されたコードは、実際のサービス インターフェイスについて何も知らないかのようです。これをトラブルシューティングする方法はありますか？前もって感謝します。

編集: サーバーが XmlSerializer ではなく DataContractSerializer を使用できることを確認する必要があるようです: http://blogs.msdn.com/sonuarora/archive/2007/06/16/contract-generation-from-wsdl-を参照してくださいxml-schema-datacontractserializer-vs-xmlserializer.aspx . 私のコード (おそらく Class Thing) で DataContractSerializer の制限に違反しているものを特定する方法を知っている人はいますか?

4

2 に答える 2

3

正直なところ、私は答えが何であるかわかりません。サービス参照を削除して、最初から再作成してみましたか? 特に変更を加えたので、それはそれを修正しようとする最も簡単な方法のようです.

私はあなたがこれを尋ねていないことを知っていますが、余談ですが、私は個人的にビジュアル スタジオでサービス参照機能を使用することから完全に離れました。これは、コードを少しリファクタリングする意思がある場合に、それがいかに簡単かを説明する優れたビデオです。あなたは WCF クライアントとサーバーの両方を担当しているように聞こえるので、Miguel が提唱するアプローチから多大な恩恵を受けると思います。

編集：

John Saunder のコメントに応えて、クライアントとサーバーの両方を担当している場合、私の意見では、コントラクト (サービス コントラクトとデータ コントラクト) を共有される単一のアセンブリにリファクタリングする方がよいでしょう。クライアントとサーバーの間。サービス参照を追加/更新する場合、クライアント用のこれらのコントラクトのコード生成コピーを作成し、プロキシ用のボイラープレート コードを追加するだけです。したがって、本質的には、これらのインターフェイスとクラスの 2 つの別個の、しかし同一の定義があり、1 つはサーバー側に、もう 1 つはクライアント側にあります。

これを行うことから移行した理由は、Windows サービスでホストされている WCF サービスがあるためです。このサービスは、プロジェクト全体で 4 つの個別のアセンブリでクライアントによって使用されました。WCF サービスのサービス/データ コントラクトを変更するたびに、WCF サービスを使用する 4 つのアセンブリでサービス参照を更新する必要がありました。これらのコントラクトを 1 つの共有アセンブリにリファクタリングすることで、そのアセンブリを更新し、再コンパイル (とにかくこれを行う必要があります) を行えば、準備は完了です。どのアセンブリを更新する必要があるかを覚えておく必要がなくなりました。

Web 上の例の多くは、svcutil ツールの使用の単純さについて語っていることを認識していますが、私の場合、それは不必要なオーバーヘッドです。

ビデオを見て、自分で判断してください。

于 2009-08-18T21:53:02.380 に答える