WCF で認証が必要な Proxy を利用する [.NET Framework / .NET Core / .NET Standard 完全対応] - xin9le.net
gRPC という超クールなものが大人気な昨今、WCF なんてひと昔もふた昔も前のもの...と鼻で笑っているあなた！古き良き (？) WCF はまだまだ現役の世界線もあるのですよ！ ゴンドアの谷の歌にあるもの。 「WCF に根を下ろし、SOAP と共に生きよう。XML と共に Web を越え、REST と共に API を歌おう」 どんなに恐ろしいプロトコルを持っても、たくさんの可哀想なライブラリを操っても、WCF から離れては生きられないのよ！— じんぐる (@xin9le) 2019年12月24日 背景 / 前話 ということで僕は仕事で EC サービスの開発/運営をやっているのですが、とある WCF を採用している外部 API と連携する必要が業務上の必須要件としてあるのです。そして、その外部 API はアクセス元を IP 制限しています。僕たちが運用している EC サービスは Azure
![WCF で認証が必要な Proxy を利用する [.NET Framework / .NET Core / .NET Standard 完全対応] - xin9le.net](https://cdn-ak-scissors.b.st-hatena.com/image/square/4816e2e73a9a23d9a847fa30381bef10f8f8f01b/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F8454420450074880027%2F26006613489783106%2F1577602131)
net.tcpでの通信
SvcEditorで操作した。 ■netTcpBindingでの接続 ・web.config ・netTcpBindingでバインドを作成する ・エンドポイントを追加し binding：netTcpBinding bindingConfiguration：上で作ったバインド と設定する。 <?xml version="1.0"?> <configuration> <system.serviceModel> <bindings> <netTcpBinding> <binding name="MyTcpBinding"> <security mode="Transport" /> ※2 </binding> </netTcpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="TestBehavior"> <se
ASP.NET Web APIを業務アプリ開発で使う時の勘所 - Qiita
ASP.NET Web APIの勘所 日本マイクロソフト株式会社の赤間さんのセッションを見た時のメモ Web APIというとRESTful型、JSONエンコードというイメージがあるがRPC型、XMLエンコードもいいよ サーバー・クライアント間の通信 RESTfulスタイル エンティティオブジェクトのCURD処理の形で実装 RPCスタイル 処理伝票の送信と結果伝票の受信の形で実装 ASP.NET Web APIのサンプルでRESTfulなサーバーAPIを開発するというのをよく見かける ASP.NET Web APIはRESTfulスタイル用の技術ではない！ マッピングルールを変更するとRPCスタイルも使える ASP.NET Web APIの既定のマッピング URL：コントローラクラス名 HTTP Verb：メソッド名 HTTP Verb 意味
WCFサービスへのリクエストが、タイムアウト前に再送される
WCFサービスアプリケーションを作成し、HTTPSで「信頼できるセッション(reliableSession)」を用いて接続できるように設定しております。 次にクライアントプログラムをWPFで作成し、上記WCFサービスへのサービス参照を作成して通信を行っています。基本的にはそれで通信できているのですが、サーバ側の応答に時間がかかる場合、タイムアウト時間(1分間に設定しております)を待たずに同じリクエストを再送しているようなのです。 Fiddler4で確認したのですが、サーバへ要求を投げてから応答もなく、タイムアウト時間にもなっていない時にもう一度同じ要求を投げています。またしばらく同じ状況が続くともう一度要求が投げられる、というようなことが繰り返され、最初の要求から1分後に、それらの要求がほぼ同時にタイムアウトとなります。 クライアントプログラム自体には、特にタイムアウト時に同じ要求を繰り返
WCF で呼び出されたサービスのメソッド名とクライアントのIPアドレスを OperationContext から取得するメモ - present
OperationContext の IncomingMessageHeaders や IncomingMessageProperties から取り出せる。 でもこれくらいはプロパティで用意しておいて欲しいな。 public static class OperationContextExtensions { // 実行中のサービスのオペレーション名を取得 public static string GetOperationName(this OperationContext operationContext) { var action = operationContext.IncomingMessageHeaders.Action; var operationName = action.Substring(action.LastIndexOf("/", StringComparison.Or
WCF の用語について自分なりにまとめる
WCF は色んなところが関連付いていて、用語の定義が難しくなっている気がします。全体が見渡せるようになってからやっと用語の意味が理解できるようになる、というかなり高いハードルが WCF の普及を妨げているのかもしれませんね。自分なりのまとめをしておきます。 Service（サービス） とは ServiceContract 属性の付いた Interface を実装するクラス。次の例でいう MyWcf.Service1 のこと。 namespace MyWcf { [ServiceContract] public interface IService1 { [OperationContract] string GetData(int value); } } namespace MyWcf { public class Service1 : IService1 { public string G
WCF を 拡張する
MSDN マガジンのこの記事がよくできているのです。WCF を拡張する時に知りたいことが全て書いてあります。 でも、元記事の訳し方に問題があるのか、元記事が悪いのか、今ひとつわかりにくいです。自分なりの理解を残しておきます。 クライアント側のプロキシに相当するサーバー側のコンポーネントは、Dispatcher（ディスパッチャ）と呼ぶ。 拡張は、プロキシとディスパッチャに対して行う。 ※この記事は、プロキシとディスパッチャに対しての拡張についてのみ扱う、という意味。WCF はメッセージ、トランスポート、エンコーダ、などその気になったらなんでも作ることができる プロキシはメソッドごとに ClientOperation オブジェクトを持つ。またプロキシ全体で１つ、 ClientRuntime オブジェクトを持つ。 ディスパッチャはメソッドごとに DispatchOperation オブジェクトを
WCF + EntityFramework で POCO プロキシ のシリアル化
Entity Framework では 変更追跡と遅延読み込みを可能とするために Model クラスに対して自動的にプロキシクラスを作るのが既定の動きです。ですが、WCF ではこのプロキシオブジェクト をシリアライズすることができません。いや、正確にいうと、 DataContractSeirializer ではシリアライズできません。 MSDN にあるチュートリアルでは IOperationBehavior と Attribute を実装し、 WCF のメソッドに属性で適用する例が説明されています。ですが、該当するメソッドにいちいち属性を付けるのは実際のアーキテクチャでは採用されないでしょう。面倒だし、属性を忘れたら訳のわからないエラー（基礎になる接続が閉じられました、とかなんとか）で苦しむことになります。 データアクセスに EntityFramework を使用する、と決めたのならば W
WCF - memcache @wiki
XML文書の論理的構造を定義する為のスキーマ言語の一つ。 元々XMLのスキーマ言語としてはSGML用スキーマ言語であるDTD(Document Type Definition:文書型定義)が使われていたが、要素のデータ型が定義できない、文法がXMLと全く異なる等、XMLでは使いづらい面があった為、W3Cが開発・標準化にあたっている。
)
WCF トラブルシューティング クイックスタート
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 このトピックでは、WCF クライアントと WCF サービスの開発時に生じるさまざまな既知の問題の一覧を示します。発生している問題がこの一覧にない場合は、サービスに対してトレースを構成することをお勧めします。これにより、トレース ファイル ビューアーで表示し、サービス内で発生することがある例外に関する詳細情報を取得できるトレース ファイルが生成されます。トレースの構成の詳細については、「トレースの構成」を参照してください。トレース ファイル ビューアーの詳細については、「サービス トレース ビューアー ツール (SvcTraceViewer.exe)」を参照してください。 最初の要求の後でクライアントがしばらく
)
WCF パフォーマンス カウンター
Windows Communication Foundation (WCF) には、アプリケーションのパフォーマンス測定に役立つ多数のパフォーマンス カウンターが備わっています。 パフォーマンス カウンターの有効化 次のように、WCF サービスの app.config 構成ファイルを使用して WCF サービスのパフォーマンス カウンターを有効にできます。 <configuration> <system.serviceModel> <diagnostics performanceCounters="All" /> </system.serviceModel> </configuration> 特定の種類のパフォーマンス カウンターを有効にするよう performanceCounters 属性を設定できます。有効な値は次のとおりです。 All : すべてのカテゴリ カウンター (Service
)
クライアントを使用したサービスへのアクセス
クライアント アプリケーションがサービスと通信するには、クライアント アプリケーションで WCF クライアントまたはチャネルを作成および構成し、使用する必要があります。「WCF クライアントの概要」では、オブジェクトの概要および基本的なクライアントやチャネル オブジェクトの作成と使用に関する手順を説明しています。 このトピックでは、ユーザーのシナリオに応じて役立つ、クライアント アプリケーション、クライアント オブジェクト、およびチャネル オブジェクトに関するいくつかの問題について詳しく説明します。 概要 ここでは、以下の項目に関連する動作と問題について説明します。 チャネルとセッションの有効期間 例外処理 ブロックの問題について 対話方式によるチャネルの初期化 チャネルとセッションの有効期間 Windows Communication Foundation (WCF) アプリケーションの
C#と諸々 WCFサービスのインスタンス コンテキスト モード
C#がメインで他もまぁ諸々なブログです おかしなこと書いてたら指摘してくれると嬉しいです(´･∀･`) つーかコメント欲しい(´･ω･｀) [ インスタンス コンテキスト モード ] WCFでは、サービスのインスタンス化方式が3種類あります。 クライアント毎にサービスのインスタンスを生成 クライアントを識別しサービスのインスタンスを生成し、クライアントが一連の処理を終えるまで ( クライアントのサービス プロキシ オブジェクトがクローズするまで ) インスタンスを保持します。 要求毎にサービスのインスタンスを生成 サービスのメソッドが呼び出される度にサービスのインスタンスを生成します。一つのインスタンスは一度のメソッド呼び出しにしか使用されません。 シングルトン サービスのインスタンスは常に一つだけ存在し、すべてのクライアントの要求に対して同一のインスタンスが使用されます。 従来のASP.
)
セッションの使用
Windows Communication Foundation (WCF) アプリケーションでは、セッションがメッセージのグループを相互に関連付けて通信を行います。WCF セッションは、ASP.NET アプリケーションで使用できるセッション オブジェクトとは異なるものであり、サポートされる動作と制御する方法が異なります。ここでは、WCF アプリケーションのセッションで有効になる諸機能とそれらの使用方法について説明します。 Windows Communication Foundation アプリケーションのセッション サービス コントラクトでセッションが必要であると指定されている場合、すべての呼び出し (つまり、呼び出しをサポートする基本的なメッセージ交換) を同じメッセージ交換の一部にする必要があります。セッションが許可されるが必須ではないコントラクトの場合、クライアントは、接続した後に
WCF の例外処理 - present
WCF は例外を握りつぶしてしまう WCF サービス内で発生した例外は、何もしなければ握り潰されます。そして、代わりに FaultException がクライアントに返されます。 例外の内容も、「例外がハンドルされなかった」という旨に変更されてしまいます。これじゃ何が原因なのか、全く分からないですよね。 クライアントに役立つ情報を返したいなら、自分で FaultException をスローしよう クライアント側に役立つ情報を返したい場合は、一度例外をキャッチし、自分で FaultException に置き変える必要があります。 public class FooService : IFooService { public void Foo() { try { // アプリケーションロジックで例外発生 throw new ArgumentException("エラー発生"); } catch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HttpClient で WCF サービスを呼出
Application Insights での WCF の監視
WCF RIAサービスを使ったWeb連携アプリを作ろう一覧
SvcPerf - WCFのトレース分析ツールをリリース
Google
