UWPアプリからWCFサービスを呼び出すと、Debugでは正常なのにReleaseに切り替えた瞬間「endpointが見つからない」などで失敗することがあります。原因の多くは、エンドポイントURLがDebug専用の設定ファイルにしか入っていないこと。Releaseでも確実に動かすための確認手順と直し方をまとめます。
ReleaseビルドだけWCFが動かないときの典型的な症状
DebugとReleaseで挙動が変わる場合、ネットワーク自体が遮断されているというより、設定の読み込み・参照先・ビルド成果物の差でつまずいているケースが多いです。まずは症状を整理して、原因を狭めます。
- Debug実行ではWCFサービスに接続でき、API呼び出しも成功する
- Release実行では、起動直後〜最初の呼び出し時に例外が出て通信できない
- 例外メッセージに
endpoint/address/contract/configurationといった語が含まれる
代表的な例外の雰囲気は次のような形です（文言は環境や参照方法で多少異なります）。
Could not find default endpoint element that references contract '...'
The endpoint configuration section was not found.
Could not find endpoint element with name '...' and contract '...'
この時点で「WCFが壊れた」のではなく、Release側の生成物にWCFクライアント設定（endpoint）が入っていない／参照できていない可能性が濃厚です。
なぜDebugでは動いてReleaseで落ちるのか
Debug/Releaseは単なる最適化ON/OFFではありません。プロジェクトによっては、ビルド構成ごとに次のような差が発生します。
| 差が出やすいポイント | Debug | Release | Releaseで起きがちな問題 |
|---|---|---|---|
| 設定ファイルの差し替え・変換（config transform） | Debug用の設定が適用 | Release用の設定が適用 | Release用にendpointが書かれていない／変換が走っていない |
| 成果物に含まれるファイル | ローカル実行向けに揃っている | パッケージング規則で除外されることがある | 設定ファイルがアプリに同梱されていない |
| ビルド最適化 | 最適化が弱い | 最適化が強い | Debugでは偶然動いていたコードパスが表面化する |
今回のように「Debug/Releaseでendpointの設定や参照が欠けているように見える」場合、原因の本命はエンドポイントURL（endpoint address）の設定が “Debug用の設定ファイルだけ” に入っていることです。たとえば *.debug.config にだけ <endpoint address="..." /> が存在していると、Debugビルドでは動いてもReleaseビルドでは参照先が消えたように見えます。
原因の本命：endpoint addressがDebug用設定にしか入っていない
「Debug専用の設定ファイル」と一口に言っても、プロジェクト構成によって名称や適用方法が異なります。よくある構成を整理すると、次のどれかに当てはまるはずです。
| ファイル例 | 想定される役割 | 適用タイミング | つまずきポイント |
|---|---|---|---|
ServiceReferences.ClientConfig / App.config（ベース） | 共通のWCFクライアント設定 | 全ビルド | ここに書けばDebug/Release両方に効く |
*.Debug.config（変換・差し替え用） | Debugだけの差分 | Debugビルド | Debugでは動くがReleaseには反映されない |
*.Release.config（変換・差し替え用） | Releaseだけの差分 | Releaseビルド | 未作成/未適用だとendpointが空になる |
結論はシンプルで、Releaseでも同じendpoint設定が必要なら、Release側の設定に同じ情報を入れるか、Debug/Releaseで同じ値ならベース（共通）設定に寄せるのが正解です。
最短で切り分ける：Releaseの生成物にendpointが入っているか確認する
「設定が入っていない」のか「別名で入っている」のかを見誤ると、延々とコード側を疑って時間を溶かします。ここでは、最短で原因に到達するための確認手順を具体的に紹介します。
| 確認項目 | 見る場所 | 狙い | よくあるNG |
|---|---|---|---|
| Release成果物に設定ファイルがあるか | bin\\x86\\Release / bin\\x64\\Release など | Releaseにendpoint定義が載っているかを物理的に確認 | Debug出力だけ見て「あるはず」と思い込む |
| AppX出力に設定が含まれているか | bin\\...\\Release\\AppX など | 実際に配布される形で欠落していないか確認 | ローカル実行ではOKでも配布版で落ちる |
endpointのnameとcontractが一致しているか | 設定ファイルと生成されたクライアントコード | 参照先のキーが一致しないと見つからない | 手編集で名前や名前空間を変えて不一致になる |
| Debug/Releaseの変換ルールが正しいか | 変換設定・ビルド手順・導入している拡張機能 | Releaseで別ファイルが適用されていないか | Release用変換ファイルが存在しない／適用されない |
Releaseのパッケージを直接見て「設定が入っているか」を確実に確認する
Visual Studio上でプロジェクトが正しく見えていても、実際のパッケージには入っていないことがあります。もっとも確実なのは、Releaseで作られたパッケージを中身まで確認することです。
- Releaseでビルド（必要なら「発行」や「アプリ パッケージの作成」）を行う
- 出力先の
.appx/.msixを見つける（AppPackages配下など） - ファイルをコピーして拡張子を
.zipに変更する（または展開ツールで開く） - 展開した中に、WCFクライアント設定ファイルや、endpoint情報が入った設定が存在するか確認する
ここで「Debugではあるのに、Releaseパッケージには無い」と分かれば、原因は通信処理ではなくビルド構成・パッケージング・設定ファイル運用に確定します。
生成されたクライアントが「どのendpoint名」を探しているかを確認する
WCFの自動生成クライアントは、よくある書き方だと次のように「設定からendpointを引く」前提になっています。
// 例：自動生成されたクライアントのイメージ
var client = new MyServiceClient(); // 既定のendpoint名を設定ファイルから探す
await client.SomeOperationAsync();
この場合、Release側の設定に該当するendpoint要素が無いと、例外文言に Could not find endpoint 系が出ます。逆に、コードでbindingとaddressを明示している場合は、設定ファイル欠落とは別の原因（URL誤り、TLS、証明書、認証、Capabilityなど）を疑うべきです。
解決策：Releaseにもendpoint設定を入れる（最も確実）
Debug専用ファイル（例：*.debug.config）にだけendpointがあるなら、Release用（例：*.release.config）にも同等の定義を用意します。環境が違うならURLだけを切り替え、binding/contract/nameは一致させるのが基本です。
設定例（イメージ）：
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMyService" />
</basicHttpBinding>
</bindings>
重要：ここでいう「同等」とは、単にURLをコピーするだけではありません。name（endpoint名）と contract（インターフェース）が一致していないと、Release側で「存在しないendpointを探す」状態になります。
URLだけを切り替えたいなら「差分はaddressだけ」に寄せる
環境ごとに変えるのは本来URLだけ、というケースは多いはずです。その場合、ベース設定にbindings/contract/nameを置き、Debug/Release側はaddressだけを差し替える設計にすると、更新漏れが激減します。
- ベース（共通）：binding設定、contract、endpoint名
- 環境差分（Debug/Release）：endpoint address（URL）
「差分が増えるほどミスが増える」という現場あるあるを、構造で潰すイメージです。
解決策：Debug/Releaseで同じURLならベース設定に移す（事故が減る）
もしDebug/Releaseで同じエンドポイントに向けて良いなら、環境別ファイルに分けるメリットはほとんどありません。むしろ、分けたことで「片方だけ更新漏れ」が起きやすくなります。
- endpoint addressが同じ：ベース（ルート）の設定ファイルに移動して共通化
- 差分がある：Release用ファイルを作り、変換が必ず走るように運用で担保
とくにチーム開発では、共通化できるものは共通化しておく方が、将来のデプロイや環境追加（Staging/Production等）でも破綻しにくくなります。
環境別にURLを切り替えたいときの現実的な設計
「開発用はテスト環境、Releaseは本番」という設計は自然ですが、切り替え方を雑にすると今回のようにビルド構成差で事故ります。UWP + WCFで実務的に扱いやすい選択肢をまとめます。
| 方式 | 概要 | メリット | 注意点 |
|---|---|---|---|
| 設定ファイルの変換（Debug/Release） | ベース設定に対して差分を適用 | URLだけ差し替えやすい | 変換の仕組みがプロジェクトに依存（未適用が起きる） |
| ビルド構成ごとに別ファイルを同梱 | Release用の設定を明示的に用意 | 挙動が直感的で追いやすい | ファイルの取り違え・更新漏れが起きやすい |
| コードでendpointを生成 | bindingとaddressをコードで指定 | 設定ファイル依存を減らせる | ハードコードは避け、環境値の管理が必要 |
| リモート設定（起動時に取得） | サーバーや設定サービスからURL取得 | 配布後に切り替え可能 | 初回起動の失敗設計、改ざん対策が必要 |
「設定ファイルをやめてコードで指定する」例
どうしてもビルド成果物の設定同梱が不安定な場合、クライアント生成時にendpointを明示する方が安定することがあります（特にUWPで配布形態が複数ある場合）。
// 例：bindingとendpointをコードで明示（イメージ）
var binding = new BasicHttpBinding();
var endpoint = new EndpointAddress("https://api.example.com/MyService.svc");
var client = new MyServiceClient(binding, endpoint);
await client.SomeOperationAsync();
この方式にする場合も、URLは環境別に差し替えられる形（アプリ設定・ビルド定数・安全な設定配信など）にしておくと運用が楽になります。
よくある落とし穴：endpointが「あるのに」見つからないケース
設定ファイルにendpointが存在しても、次のパターンだと「見つからない」扱いになります。Releaseに同じものを入れたのに改善しない場合は、ここを疑ってください。
| 落とし穴 | 起きること | 対処 |
|---|---|---|
endpointのnameが一致していない | コードが別名を探し続ける | 生成されたクライアントの期待名に合わせる（名前を手で変えない） |
contract（名前空間）がズレている | 同名サービスでも別契約として扱われる | 参照更新後にconfigも更新、手編集を最小化 |
| bindingConfigurationの参照先が無い | endpointは読めてもbindingが解決できない | bindings配下のnameを一致させる |
| 設定ファイルがアプリに同梱されていない | DebugではあるがReleaseパッケージに無い | ファイルのビルドアクションやパッケージング設定を見直す（自前追加した場合は特に要注意） |
Releaseだけ通信に失敗する場合に「次に」疑うポイント
今回の本命は設定欠落ですが、もしendpoint設定が正しく反映されているのに失敗するなら、Releaseで顕在化しやすいポイントを順番に潰します。
- URLのプロトコル差：DebugはHTTP、ReleaseはHTTPSに切り替えていないか（サーバー側のTLS設定・証明書の問題が出る）
- DNS/ホスト名：DebugはIP直指定、Releaseはドメイン指定で名前解決に失敗していないか
- UWPのCapability：インターネット接続が必要ならマニフェストの
Internet (Client)を見直す - 認証・ヘッダー：Debug用の中間環境だけが認証不要になっていないか
ただし、例外にendpoint関連の文言が出ているなら、まずは「設定の不整合」を片付ける方が近道です。
Releaseビルドでの再発を防ぐチェックポイント
「直ったけど、次のリリースでまた起きた」を防ぐために、最低限ここだけは仕組み化するのがおすすめです。
- Release成果物（またはパッケージ）を開いて、endpoint定義が存在するかを毎回確認する
- Debug/Releaseで設定ファイルを分けるなら、両方のファイルを同時に更新する運用（レビュー観点に入れる）
- 共通URLなら、分割をやめてベース設定に一本化する
- 自動生成プロキシを更新したら、config手編集の差分が破綻していないか確認する
- 可能なら、Release構成での疎通テストをCIに入れて「DebugだけOK」を許さない
Debugでしか試していない状態が最大のリスクです。WCFエンドポイントの問題は、早い段階でRelease成果物を目視すると、だいたいその場で答えが出ます。
まとめ：endpoint設定は「どのビルド構成に入っているか」を必ず確認する
Debugでは動くのにReleaseでWCFエンドポイントが動かない場合、原因はコードよりも「設定の所在」と「ビルド成果物への反映」にあることが大半です。まずはReleaseの生成物にendpointが入っているかを確認し、Debug専用の設定に閉じているならReleaseへ反映、同一URLならベース設定に移して共通化してください。それだけで、Releaseだけ落ちる問題の多くは解消できます。
コメント