WCFサービス参照を追加すると、空のreference.csが生成される場合があります
WCFサービス参照を追加すると、空のreference.csが生成されることがあり、プロジェクト内のどこでもサービスを参照できません。
誰もこれに遭遇しましたか？
一般に、コード生成の問題であり、mostであることがわかりました。これは、解決できないタイプ名の競合があるためです。
サービス参照を右クリックして構成をクリックし、uncheck「参照アセンブリのタイプを再利用」問題を解決します。
この機能の一部を使用している場合は、名前をクリーンアップする必要がある場合があります。
受け入れられた答えが指摘しているように、型を再利用する際の型参照の問題がおそらく犯人です。問題を簡単に判断できない場合、svcutil.exeコマンドラインを使用すると、根本的な問題を明らかにするのに役立ちます（John Saundersが指摘しているように）。
ここでの機能強化として、svcutilを使用した簡単な例を示します。
svcutil /t:code https://secure.myserver.com/services/MyService.svc /d:test /r:"C:\MyCode\MyAssembly\bin\debug\MyAssembly.dll"
どこ：
- / t：codeは、指定されたURLからコードを生成します
- / d：出力用のディレクトリを指定します
- / r：参照アセンブリを指定します
完全なsvcutilコマンドラインリファレンス： http://msdn.Microsoft.com/en-us/library/aa347733.aspx
Svcutilを実行すると、インポートによってスローされる例外が表示されます。タイプの1つに関する次のタイプのメッセージを受信する場合があります。「参照されたタイプは、インポートされたDataContractと一致しないため使用できません」。
これは、参照されたアセンブリのいずれかのタイプに、サービスのDataContractで生成されたものと異なる点があるという点で、単に指定されている可能性があります。私の場合、インポートしているサービスには、共有アセンブリにあったものから新しい、更新されたタイプがありました。これは、例外で言及されたタイプが同じであるように思われたため、すぐにはわかりませんでした。異なっていたのは、型で使用されるネストされた複合型の1つでした。
このタイプの例外と結果として生じる空白のreference.csをトリガーする可能性のある他のより複雑なシナリオがあります。 ここに1つの例があります 。
この問題が発生し、データコントラクトでジェネリック型を使用しておらず、IsReference = trueを使用していない場合、共有型がクライアントとサーバーでまったく同じであることを確認することをお勧めします。そうしないと、この問題が発生する可能性があります。
私は丸一日、この問題に頭を悩ませてきました。修正しました。方法は次のとおりです...
SSLで実行するサービスhad（つまり、 https://mydomain.com/MyService.svc ）
開発サーバー上のWCFサービスへのサービス参照の追加は問題なく機能しました。
ライブ実稼働サーバーにexactWCFサービスの同じビルドを展開し、クライアントアプリケーションに切り替えて、ライブサービスを指すようにサービス参照を構成してもエラーは表示されませんでしたが、アプリはビルドしません：サービス参照のReference.csファイルは完全に空でした！サービス参照を更新しても違いはありません。ソリューションをクリーニングしても解決しませんでした。 VS2010を再起動しても違いはありません。新しい空のソリューションを作成し、コンソールプロジェクトを開始し、ライブサービスにサービス参照を追加すると、まったく同じ問題が発生しました。
競合する型または何かが原因だとは思いませんでしたが、一体何なのか-「参照されているすべてのアセンブリで型を再利用する」のチェックを外して、WCFサービス参照を再構成しました。喜びはありません。チェックマークを戻します。
次のステップは、参照URLでsvcutilを試して、問題の発見に役立つかどうかを確認することでした。コマンドは次のとおりです。
svcutil /t:code https://mydomain.com/MyService.svc /d:D:\test
これにより、以下が生成されました。
Microsoft (R) Service Model Metadata Tool
[Microsoft (R) Windows (R) Communication Foundation, Version 4.0.30319.1]
Copyright (c) Microsoft Corporation. All rights reserved.
Attempting to download metadata from 'https://mydomain.com/MyService.svc' using WS-Metadata Exchange or DISCO.
Error: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Schema with target namespace 'http://mynamespace.com//' could not be found.
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']
Error: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
XPath to wsdl:portType: //wsdl:definitions[@targetNamespace='http://mynamespace.com//']/wsdl:portType[@name='IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']
Error: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
XPath to wsdl:binding: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='WSHttpBinding_IMyService']
XPath to Error Source: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:service[@name='MyService']/wsdl:port[@name='WSHttpBinding_IMyService']
Generating files...
Warning: No code was generated.
If you were trying to generate a client, this could be because the metadata documents did not contain any valid contracts or services
or because all contracts/services were discovered to exist in /reference assemblies. Verify that you passed all the metadata documents to the tool.
Warning: If you would like to generate data contracts from schemas make sure to use the /dataContractOnly option.
それは私を完全に困惑させました。ひどくグーグルで走り、バスドライバーとしてのキャリアを考え直したにもかかわらず、私はついに開発ボックスでうまくいった理由を考えました。 IIS構成の問題でしょうか？
開発ボックスとライブボックスの両方に同時にリモート接続し、それぞれでIIS Manager（IIS 7.5を実行）を起動しました。次に、各ボックスの各構成設定を調べて、各サーバーの値を比較しました。
問題があります。サイトの[SSL設定]で、[SSLが必要]がオンになっていることを確認し、[受け入れ]の[クライアント証明書]ラジオボタンをオンにします。問題が修正されました！
この場合、エラーウィンドウと出力ウィンドウを調べて、エラーメッセージがあるかどうかを確認します。それでも解決しない場合は、svcutil.exeを手動で実行して、エラーメッセージがあるかどうかを確認してください。
これは、参照を追加し、削除してから同じ名前のサービスを再追加するたびによく発生することがわかりました。型の競合は、Visual Studioがまだ見ることができる場所に古いファイルが残っているために発生しているようです。新しい参照を追加する前に、それを修正するために必要なことはすべてきれいです。
- 問題があるサービス参照を削除します。
- Solution Explorerのプロジェクト名をクリックして、プロジェクトを強調表示します。
- プロジェクト参照を右クリックします。
- コンテキストリストの上部近くで、Cleanアイテムをクリックします。
- 通常どおりにサービス参照を追加します。
お役に立てれば。
以前のバージョンからアップグレードされたSilverlight 5でこの問題が発生しました。
サービス参照を再度追加しても、空のReference.csが表示されました。
最終的に、新しいプロジェクトを作成し、サービス参照を再作成する必要がありました。これに約30分以上を費やした場合は、これを試してみてください。元のプロジェクトを修正することに決めた場合でも、何が起こるかを確認するためだけにこれを試してから、問題を修正するために後方に作業することができます。
問題が何であるかを正確に把握することはできませんでしたが、.csprojファイル内の何かがアップグレードされなかったか、何らかの設定が間違っていた可能性があります。
これが発生し始めたときにプロジェクトに最近コレクションを追加した場合、問題は同じCollectionDataContract属性を持つ2つのコレクションが原因である可能性があります。
[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="AItems", ItemName="A")] // Wrong
public class CollectionB : List<B> { }
プロジェクトを一掃し、すべてのNameおよびItemName属性が一意であることを確認して、エラーを修正しました。
[CollectionDataContract(Name="AItems", ItemName="A")]
public class CollectionA : List<A> { }
[CollectionDataContract(Name="BItems", ItemName="B")] // Corrected
public class CollectionB : List<B> { }
その後、サービス参照を更新し、すべてが再び機能しました。
私の場合、これらの答えを役に立たなかったために働いたテクニックは、単に私の契約のすべてをコメントアウトし、バイナリ検索方式でそれが機能しなくなるまでコメントを外すことでした。これにより、問題のあるコードが絞り込まれます。
次に、そのコードの何が問題なのかを推測するだけです。
もちろん、ツール内のエラーフィードバックがあれば役に立ちました。
Webサービス契約を書いています。メンバーのないプレースホルダー列挙型がありました。それで大丈夫です。しかし、別のクラスのプロパティで使用し、クライアントでコントラクトdllを再使用すると、codegenはエラーメッセージなしで爆発します。 svcutil.exeを実行しても解決しませんでした。理由を述べずにcsファイルを出力できませんでした。
以下はここにリストされておらず、私が採用した解決策でした（SvcUtilsはエラーメッセージを見るのに役立ちました。しかし、私が得たエラーはwrapper type message cannot be projected as a data contract type since it has multiple namespacesです。つまり、このリードに従い、wsdl.exe via this post）。
私の場合、wsdl [my-asmx-service-address]を実行するだけで問題のない.csファイルが生成され、これをプロジェクトに含めて使用するためにインスタンス化しましたサービス。
私の問題は、Webサービスリンクの最後に「mex」を残したことです。
「 http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc/mex 」の代わりに
「 http://yeagertech.com/yeagerte/YeagerTechWcfService.YeagerTechWcfService.svc 」を使用します
私の場合、C＃UserControlを参照するVB Web Formsプロジェクトのソリューションがありました。 VBプロジェクトとCSプロジェクトの両方に、同じサービスへのサービス参照がありました。参照は、VBプロジェクトのサービス参照と、CS（フレームワーク）プロジェクトのグループ化されたサービスの下に表示されました。
VB Webフォームプロジェクトでサービス参照を更新する（つまり、Reference.vbファイルを空にしない）ために、CSプロジェクトを削除してからVBサービス参照を更新する必要がありました、CSソリューションをソリューションに追加します。
svcutilを使用してこの問題のトラブルシューティングを試みると、dbloodの回答に示されているエラーが表示されました（「参照された型はインポートされたDataContractと一致しないため使用できません」）。
私の場合、根本的な原因はDataContract属性を持つ列挙型であるように見えましたが、そのメンバーはEnumMember属性でマークされていませんでした。指摘された問題クラスsvcutilには、その列挙型のプロパティがありました。
これはdbloodの答えに対するコメントとしてはより適切ですが、そのための十分な担当者ではありません...
また、両側のプロジェクト参照（サービスプロジェクトとサービスへの参照を持つプロジェクト）を操作するときに、破損したサービス参照の問題がありました。たとえば、参照プロジェクトの.dllが「Contoso.Development.Common」という名前で、プロジェクト名が単に「Common」に短縮されている場合、このプロジェクトへのプロジェクト参照も「Common」という名前になります。ただし、サービスは、クラスを解決するために「Contoso.Development.Common」への参照を予期しています（このオプションがサービス参照オプションでアクティブになっている場合）。
そこで、エクスプローラーで、サービスと「Common」プロジェクトを参照しているプロジェクトのフォルダーを開きました。そこで、VSプロジェクトファイル（.csproj）をメモ帳で編集します。参照先プロジェクトの名前（この例では「Common.csproj」）を検索すると、プロジェクト参照を表す構成エントリがすぐに見つかります。
私が変更され
<ProjectReference Include="..\Common\Common.csproj"> <Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project> <Name>Common</Name> </ProjectReference>
に
<ProjectReference Include="..\Common\Common.csproj"> <Project>{C90AAD45-6857-4F83-BD1D-4772ED50D44C}</Project> <Name>Contoso.Development.Common</Name> </ProjectReference>
重要なことは、参照の名前を、参照されるプロジェクトが出力として持つDLLの名前に変更することです。
次に、VSに切り替えます。 VSの外部で変更されているため、プロジェクトをリロードするように求められます。リロードボタンをクリックします。
そうすると、サービス参照の追加と更新が期待どおりに機能しました。
これが他の人にも役立つことを願っています。
よろしくMH
エラーウィンドウを調べるアイデアを提供してくれた上記のJohn Saundersの投稿に感謝します。私は一日中頭を抱えていて、出力ウィンドウでエラーを探していました。
私の場合、犯人はISerializableでした。 Exception型のDataMemberプロパティを持つDataContractクラスがあります。 ISerializableキーワードを持つタイプのDataMemberを使用することはできません。この例外では、削除するとすぐにISerializableがあり、すべてが魅力のように機能しました。
@dbloodが指摘しているように、主な痛みはDataContractSerializerにあり、これは型を正しく再利用しません。ここにはすでにいくつかの答えがありますので、これらについていくつかの長所と短所を追加することから始めます。
- 'IsReference'フラグは多くの問題を引き起こしますが、それを削除することが常に答えとは限りません（具体的には、再帰がある状況で）。
- 根本的な問題は、データコントラクトがタイプ名と同じではない場合があることです（たとえそうなのかはわかりませんが）。どうやら、シリアライザーはかなりうるさく、実際の問題を見つけるのは非常に難しいです。
- 「サービス参照の設定」から「参照チェック」を削除すると機能しますが、複数の実装が残ります。ただし、DLL全体でSOAPインターフェイスを再利用することがよくあります。また、私が知っているほとんどの成熟したSOAでは、複数のサービスインターフェイスが同じインターフェイスクラスを実装および拡張しています。 「参照された型を使用する」チェックを削除すると、単純にオブジェクトを渡すことができなくなります。
幸いなことに、サービスを管理している場合は、これらの問題をすべて解決する簡単なソリューションがあります。これは、DLL全体でサービスインターフェイスを再利用できることを意味します。これは、適切なソリューションに不可欠なIMOです。これがソリューションの仕組みです。
- 別のインターフェイスDLLを作成します。そのDLLに、すべてのDataContractおよびServiceContractを含めます。インターフェイスにServiceContractを配置します。
- インターフェースからサーバー実装を導出します。
同じDLLを使用して、好みの方法でクライアントを構築します。例（IMyInterfaceはサービスコントラクトインターフェイスです）：
var httpBinding = new BasicHttpBinding(); var identity = new DnsEndpointIdentity(""); var address = new EndpointAddress(url, identity, new AddressHeaderCollection()); var channel = new ChannelFactory<IMyInterface>(httpBinding, address); return channel.CreateChannel();
つまり：「サービス参照の追加」機能を使用しないでください。ただし、プロキシ生成をバイパスすることにより、WCFが（正しい）サービスタイプを使用するように強制します。結局のところ、これらのクラスは既にあります。
プロの：
- Svcutil.exeプロセスをバイパスします。つまり、IsReferenceの問題はありません。
- DataContractのタイプと名前は定義により正しいです。結局、サーバーとクライアントの両方がまったく同じ定義を使用します。
- APIを拡張するか、別のDLLの型を使用すると、（1）と（2）が保持されるため、そこで問題が発生することはありません。
短所：
- 非同期プロキシを生成しないため、非同期メソッドは苦痛です。そのため、Silverlightアプリケーションでこれを行うことはお勧めしません。
昨日、開発中に同様の問題に直面しました。契約の2つの異なるバージョンで同じ名前空間を使用していることがわかりました。
バージョン4とバージョン5など、2つのバージョンのコントラクトがあります。 version4からすべてのコントラクトをコピーし、すべての名前空間の名前をversion4からversion5に変更しました。これを行っている間、ファイルの1つで名前空間の名前をv4からv5に変更するのを忘れていました。名前空間の競合のため、Reference.csファイルは空でした。
サービス参照の生成中にエラーメッセージが表示されないため、この問題のトラブルシューティングは困難です。この問題を特定するには、作成したすべての新しいファイルを手動で検証します。この問題を解決する方法は他にもあります。これは、他のオプションに進む前に実行する必要がある最初のステップです。