私たちはvb.netのフレームワーク2.0でWebサービスを開発しました。フレームワーク3.5のWCFの webseviceを書き直す必要があります。これに関するいくつかのガイダンスを提供してください。また、 ウェブサービスURLを消費する他の多くのシステムがあります。この変換はソースシステムに影響を与えますか、それともWCFメソッドで開発されるURLをソースシステムが使用するためのビルドアクティビティを伴うのでしょうか？ これをよりよく理解するためのサンプル例を示してください。ありがとう！webservice to WCF
何も変更する必要はありません。それは同じように動作するはずです。
あなたはまだ移行を試みましたか？もしそうなら、問題は何でしたか？そうでない場合は、3.5に切り替えて何が起こるかを見てください。
いくつかの考え。
ケース1：お客様のウェブサービスはコンシューマを有しており、サービスのみを書き換え、コンシューマを妨害しないようにしたいとします。
この場合、通常のwcfサービス実装でbasicHttpBindingエンドポイントを使用します。 basicHttpBindingを使用して、WCFサービスを構築するための参照が多数見つかります。おそらくこれはあなたの必要性に合っています。
Follwoingリンクが役立ちます。
http://msdn.microsoft.com/en-us/library/aa480190.aspx
http://msdn.microsoft.com/en-us/library/ms731361(v=VS.90).aspx
ケース2：あなたがサービスを書き換えたい、消費者の変化を持つことが許容される場合、以下の点を考慮する価値があります。
エンドポイントの選択。サービスの相互運用性を維持することが望ましい場合（つまり、サービスが異なるプラットフォームに対応したい場合）、Soapベースのエンドポイントが役立ちます。 basicHTTPBinding、wsHTTPBindingなど。
b。あなたのコンシューマーがWindowsプラットフォームにあり、SOAPベースのバインディングよりも優れたパフォーマンスを望むなら、netTCPBindingベースのエンドポイントが役に立ちます。
c。消費者が同じマシンにいる場合、netNamedPipeを選択することができます。
サービスデザイン
サービスの設計では、次の組み合わせの多くで行くことに提供しています。
a。サービスインスタンスのライフサイクルを決める選択。
b。並行性の選択。
c。セッションの選択、およびサービスを呼び出さなければならない順序の実施（特定の設計者より好ましい）
d。取引の有無を選択できます。
のみ必要がサーバー側のコードを変更せずに、
http://localhost/YourProjectName/Servicename.svcとして作る
をWCFサービスでのサービスエンドポイントを変更することで、あなたは、[サービス契約]としてそれらを作るリモートインターフェイスを公開する必要があります メソッドとクライアント側の[データ契約]