Web アプリ、Linux 上の Web アプリ、モバイル バック エンド、または API アプリを Azure App Service にデプロイする場合は、既定の運用スロットではなく、別のデプロイ スロットを使用できます。 この方法は、App Service プランの Standard、Premium、または Isolated レベルで実行する場合に使用できます。 デプロイ スロットは、固有のホスト名を持つライブ アプリです。 アプリのコンテンツと構成の各要素は、(運用スロットを含む) 2 つのデプロイ スロットの間でスワップすることができます。
非運用スロットにアプリケーションをデプロイすることには、次のメリットがあります:
スロットを運用環境にスワップする前に、アプリの変更を検証できます。
運用環境にスワップする前に、スロットのすべてのインスタンスがウォームアップされていることを確認できます。 この方法により、アプリをデプロイするときのダウンタイムがなくなります。 トラフィックのリダイレクトはシームレスです。 スワップ操作であるため、要求は削除されません。
スワップ前の検証が必要ない場合は、自動スワップを構成することで、このワークフロー全体を自動化できます。
スワップ後も、以前のステージング アプリ スロットに元の運用アプリが残っているため、 運用スロットにスワップした変更が想定どおりでない場合は、同じスワップを実行して、"適切な動作が確認されている元のサイト" にすぐに戻すことができます。
デプロイ スロットは追加料金なしでご利用いただけます。 サポートされるデプロイ スロット数は、App Service プラン レベルごとに異なります。 アプリのレベルでサポートされているスロットの数については、「 App Service の制限」を参照してください。
アプリを別のレベルにスケーリングするには、アプリで既に使用されているスロットの数がターゲット層でサポートされていることを確認します。 たとえば、アプリに 5 つ以上のスロットがある場合、Standard レベルにスケールダウンすることはできません。 Standard レベルでは、5 つのデプロイ スロットのみがサポートされます。
次のビデオでは、Azure App Service でステージング環境を設定する方法を説明することで、この記事の手順を補完します。
前提条件
- 必要なスロット操作を実行するためのアクセス許可。 必要なアクセス許可については、「 リソース プロバイダーの操作」を参照してください。 たとえば、"スロット" を検索します。
スロットを追加する
複数のデプロイ スロットを有効にするには、アプリが Standard、Premium、または Isolated レベルで実行されている必要があります。
Azure portal で、アプリの管理ページに移動します。
左側のメニューで、 デプロイ>デプロイ スロットを選択します。 その後、追加を選択します。
注
アプリがまだ Standard、Premium、または Isolated レベルにない場合は、[アップグレード] を選択 します。 続行する前に、アプリの [スケール] タブに移動します。
[ スロットの追加 ] ダイアログで、スロットに名前を付け、別のデプロイ スロットからアプリ構成を複製するかどうかを選択します。 [追加] を選択して続行します。
構成は、既存のどのスロットからも複製できます。 複製できる設定には、アプリの設定、接続文字列、言語フレームワークのバージョン、Web ソケット、HTTP のバージョン、プラットフォームのビット数などがあります。
注
現時点では、プライベート エンドポイントはスロット間でクローンされません。
設定を入力したら、[ 閉じる ] を選択してダイアログを閉じます。 新しいスロットが [デプロイ スロット ] ページに表示されます。 既定では、Traffic % は新しいスロットに設定される値が 0 で、すべての顧客トラフィックが運用スロットにルーティングされます。
新しいデプロイ スロットを選択して、そのリソース ページを開きます。
ステージング スロットには、他の App Service アプリと同様に管理ページがあります。 スロットの構成を変更することができます。 デプロイ スロットを表示していることを通知するために、アプリ名とスロット名が URL に表示されます。 アプリの種類は App Service (スロット) です。 また、同じ指定先を使用して、リソース グループ内の別のアプリとしてスロットを表示することもできます。
スロットのリソース ページで、アプリの URL を選択します。 デプロイ スロットは独自のホスト名を持ち、ライブ アプリでもあります。 デプロイ スロットへのパブリック アクセスを制限するには、「 Azure App Service のアクセス制限を設定する」を参照してください。
別のスロットから設定を複製した場合でも、新しいデプロイ スロットには内容がありません。 たとえば、Git を使用してこのスロットに発行することができます。 スロットには、異なるリポジトリ分岐、または異なるリポジトリからデプロイできます。 「 Azure App Service から発行プロファイルを取得 する」の記事では、スロットにデプロイするために必要な情報を提供できます。 Visual Studio では、プロファイルをインポートして、コンテンツをスロットにデプロイできます。
スロットの URL の形式は http://sitename-slotname.azurewebsites.net です。 URL の長さを必要な DNS 制限内に維持するために、サイト名は 40 文字で切り捨てられます。 サイト名とスロット名は合わせて 59 文字未満でなければなりません。
スワップ中に何が起こるかを理解する
スワップ操作の手順
2 つのスロットをスワップすると、ターゲット スロットでダウンタイムが発生しないように、App Service によって次のことが行われます。
ターゲット スロット (たとえば運用スロット) からソース スロットのすべてのインスタンスに対して、以下の設定を適用します。
- スロット固有の アプリ設定と接続文字列 (該当する場合)
- 継続的配置 の設定 (有効な場合)
- App Service の認証 設定 (有効な場合)
いずれかの設定がソース スロットに適用されると、その変更によってソース スロット内のすべてのインスタンスの再起動がトリガーされます。 プレビューとのスワップ中、このアクションは最初のフェーズの終了をマークします。 スワップ操作は一時停止されます。 ソース スロットがターゲット スロットの設定で正しく動作することを検証できます。
ソース スロット内のすべてのインスタンスが再起動を完了するまで待機します。 いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。
ローカル キャッシュが有効になっている場合は、ソース スロットの各インスタンスでアプリケーション ルート (
/) に HTTP 要求を行って、ローカル キャッシュの初期化をトリガーします。 各インスタンスが何らかの HTTP 応答を返すまで待機します。 ローカル キャッシュの初期化により、各インスタンスでもう一度再起動が発生します。カスタム ウォームアップで自動スワップが有効になっている場合は、ソース スロットの各インスタンスでカスタム アプリケーションの初期化をトリガーします。
applicationInitializationが指定されていない場合は、各インスタンスのソース スロットのアプリケーション ルートへの HTTP 要求をトリガーします。インスタンスが任意の HTTP 応答を返すと、ウォームアップされたと見なされます。
ソース スロット上のすべてのインスタンスが正常にウォームアップされた場合は、ルーティング規則を切り替えて 2 つのスロットをスワップします。 この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。
ソース スロットに、以前はターゲット スロットにあった事前スワップ アプリが用意されたので、すべての設定を適用してインスタンスを再起動することで、同じ操作を実行します。
スワップ操作のどの時点でも、スワップされたアプリを初期化するすべての作業がソース スロットで行われます。 ソース スロットが準備され、ウォームアップされている間、スワップがどこで成功するか失敗するかに関わらず、ターゲット スロットはオンライン状態に留まります。 ステージング スロットと運用スロットを入れ換える場合は常に、運用スロットがターゲット スロットであるようにします。 こうすることで、スワップ操作が運用アプリに影響を及ぼしません。
注
以前の運用インスタンスは、このスワップ操作の後にステージングにスワップされます。 これらのインスタンスはスワップ プロセスの最後の手順でリサイクルされます。 アプリケーションで実行時間の長い操作がある場合、ワーカーがリサイクルすると破棄されます。 この事実は関数アプリにも適用されます。 アプリケーションコードが障害に強い方法で記述されていることを確認してください。
スロットを交換不可にする手順
別のデプロイ スロットから構成を複製する場合、複製された構成を編集することができます。 一部の構成要素は、スワップ全体のコンテンツに従います ( スロット固有ではありません)。 その他の構成要素は、スワップ後も同じスロットに残ります ( これらはスロット固有です)。
スロットをスワップすると、次の設定がスワップされます。
- 言語スタックとバージョン、32 ビットおよび 64 ビット
- アプリ設定 (スロット固有として構成可能)
- 接続文字列 (スロット固有として構成可能)
- マウントされたストレージ アカウント (スロット固有として構成可能)
- ハンドラー マッピング
- パブリック証明書
- Web ジョブ コンテンツ
- ハイブリッド接続 (現在)
- サービス エンドポイント (現在)
- Azure Content Delivery Network (現在)
- パスのマッピング
- 仮想ネットワーク統合
スロットをスワップする場合、これらの設定はスワップされません。
- 前の一覧に記載されていない全般設定
- 発行エンドポイント
- カスタム ドメイン名
- パブリックでない証明書と TLS/SSL 設定
- スケールの設定
- Web ジョブ スケジューラ
- IP 制限
- Always On
- 診断設定
- クロスオリジン リソース共有 (CORS)
- マネージド ID と関連する設定
- サフィックス
_EXTENSION_VERSIONで終わる設定 - Service Connector によって作成された設定
注
設定をスワップ可能にするには、アプリのすべてのスロットに WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS アプリ設定を追加します。 値を 0 または false に設定します。 これらの設定は、すべてスワップ可能であるか、すべてスワップ可能ではありません。 一部の設定だけをスワップ可能にして、他を不可にすることはできません。 マネージド ID がスワップされることはありません。 このオーバーライド アプリの設定はそれらには影響しません。
スワップされていない設定に適用されている特定のアプリ設定もスワップされません。 たとえば、診断設定はスワップされないため、スロット設定として表示されない場合でも、 WEBSITE_HTTPLOGGING_RETENTION_DAYS や DIAGNOSTICS_AZUREBLOBRETENTIONDAYS などの関連アプリ設定もスワップされません。
スワップされていない特定のスロットに対応するようにアプリ設定または接続文字列を構成するには:
そのスロットの 設定>Environment 変数 に移動します。
設定を追加または編集し、[デプロイ スロットの設定] を選択します。 このチェック ボックスをオンにすると、設定がスワップできないことが App Service に通知されます。
を選択してを適用します。
デプロイ スロットをスワップする
アプリの [デプロイ スロット] ページと [概要] ページで、デプロイ スロットをスワップできます。
アプリをデプロイ スロットから運用環境にスワップする前に、運用環境がターゲット スロットになっていること、およびソース スロットのすべての設定が、運用環境に反映させたい内容で正確に構成されていることを確認してください。
アプリの [デプロイ スロット] ページに移動し、[スワップ] を選択します。
[スワップ] ダイアログには、変更する選択したソース スロットとターゲット スロットの設定が表示されます。
目的の [ソース] および [ターゲット] スロットを選択します。 通常、ターゲットは運用スロットになります。 また、[ ソース スロットの変更 ] タブと [ ターゲット スロットの変更 ] タブを選択し、構成の変更が必要であることを確認します。 完了したら、[スワップの開始] を選択してスロットをすぐに スワップできます。
スワップが発生する前に、新しい設定でターゲット スロットがどのように実行されるかを確認するには、[ スワップの開始] を選択しないでください。 この記事の後半の「 プレビューでのスワップ」 の手順に従ってください。
閉じる を選択して、ダイアログ ボックスを閉じます。
問題がある場合は、この記事で後述 するスワップのトラブルシューティング を参照してください。
プレビューでのスワップ (複数フェーズスワップ)
ターゲット スロットとしての運用環境にスワップする前に、スワップ後の設定でアプリの実行を検証します。 ソース スロットは、スワップの完了前にウォームアップもされているため、ミッション クリティカルなアプリケーションに適しています。
プレビューでのスワップを実行すると、App Service は同じスワップ操作を実行しますが、最初の手順の後に、一時停止します。 その後、スワップを完了する前にステージング スロットでの結果を検証できます。
スワップをキャンセルすると、App Service によって構成要素がソース スロットに再適用されます。
注
いずれかのスロットでサイト認証が有効になっている場合、プレビューでスワップを使用することはできません。
「 デプロイ スロットのスワップ 」セクションの手順に従いますが、「 プレビューでスワップを実行する」を選択します。
ダイアログには、ソース スロットの構成が最初のフェーズでどのように変化するか、およびソース スロットとターゲット スロットが 2 番目のフェーズでどのように変化するかを示します。
スワップを開始する準備ができたら、[スワップの開始] を選択します。
最初のフェーズが完了すると、ダイアログに通知されます。
保留中のスワップを完了する準備ができたら、スワップ アクション内のスワップの完了を選択し、次にスワップの完了ボタンを選択してください。
保留中のスワップを取り消すには、代わりに [スワップの取り消 し] を選択し、[ スワップの取り消 し] ボタンを選択します。
完了したら、[ 閉じる ] を選択してダイアログを閉じます。
問題がある場合は、この記事で後述 するスワップのトラブルシューティング を参照してください。
スワップをロールバックする
スロットのスワップ後にターゲット スロット (運用スロットなど) でエラーが発生する場合は、同じ 2 つのスロットをすぐにスワップして、スロットをスワップ前の状態に復元します。
自動スワップを構成する
自動スワップを使うと、アプリのユーザーにコールド スタートを課したりダウンタイムを生じさせたりすることなく、アプリを連続的にデプロイする効率的な Azure DevOps シナリオを実現できます。 あるスロットから運用環境への自動スワップが有効になっていると、コードの変更をそのスロットにプッシュするたびに、ソース スロットでウォームアップされた後、App Service によって自動的に、アプリが運用環境にスワップされます。
注
自動スワップは、Linux 上の Web アプリと Web App for Containers ではサポートされていません。
運用スロットの自動スワップを構成する前に、非運用ターゲット スロットでテストすることを検討してください。
アプリのリソース ページに移動します。 [ デプロイ>デプロイ スロット] を選択し、目的のソース スロットを選択します。
左側のメニューで、 設定>構成>General 設定を選択します。
[自動スワップが有効] で [オン] を選択します。 [自動スワップ デプロイ スロット] で、ターゲット スロットを選択します。 次に、コマンド バーで [保存] を選択します。
ソース スロットへのコード プッシュを実行します。 しばらくすると自動スワップが行われます。 更新はターゲット スロットの URL に反映されます。
問題がある場合は、この記事で後述 するスワップのトラブルシューティング を参照してください。
カスタム ウォームアップを指定する
一部のアプリでは、スワップ前のカスタム ウォームアップ アクションが必要な場合があります。 これらのカスタム アクションは、applicationInitializationのWeb.config構成要素を使用して指定できます。 スワップ操作では、このカスタム ウォームアップの終了を待ってから、ターゲット スロットとのスワップが行われます。 Web.configフラグメントのサンプルを次に示します。
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
applicationInitialization要素のカスタマイズの詳細については、ブログ記事「最も一般的なデプロイ スロットスワップエラーとその修正方法」を参照してください。
次の アプリ設定を使用して、ウォームアップ動作をカスタマイズすることもできます。
WEBSITE_SWAP_WARMUP_PING_PATH: サイトをウォームアップするための、HTTP 経由での ping へのパス。 このアプリ設定を追加するには、値としてスラッシュで始まるカスタム パスを指定します。 たとえば/statuscheckです。 既定値は/です。WEBSITE_SWAP_WARMUP_PING_STATUSES: ウォームアップ操作の有効な HTTP 応答コード。 HTTP コードのコンマ区切りの一覧で、このアプリ設定を追加します。 たとえば200,202です。 返された状態コードが一覧にない場合、ウォームアップ操作とスワップ操作は停止されます。 既定で、すべての応答コードは有効です。WEBSITE_WARMUP_PATH: (スロット スワップ中だけでなく) サイトが再起動されるたびに ping を実行する必要があるサイトの相対パス。 サンプル値には、/statuscheckまたはルート パス、/が含まれます。
<applicationInitialization>構成要素は各アプリのスタートアップの一部ですが、ウォームアップ動作のアプリ設定はスロット スワップにのみ適用されます。
問題がある場合は、この記事で後述 するスワップのトラブルシューティング を参照してください。
スワップを監視する
スワップ操作が完了するまで長い時間がかかる場合、アクティビティ ログでスワップ操作に関する情報を取得できます。
ポータルのアプリのリソース ページで、左側のメニューで [ アクティビティ ログ] を選択します。
スワップ操作がログ クエリに
Swap Web App Slotsとして表示されます。 詳細を表示するには、詳細を展開し、サブ操作またはエラーのいずれかを選択します。
運用トラフィックを自動的にルーティングする
既定では、アプリの運用 URL に対するすべてのクライアント要求が運用スロットにルーティングされます。 トラフィックの一部を、別のスロットにルーティングできます。 この機能は、新しい更新プログラムのユーザー フィードバックが必要であっても、運用環境にリリースする準備ができていない場合に便利です。
Web アプリのリソース ページに移動し、 デプロイ>デプロイ スロットを選択します。
ルーティング先のスロットの [Traffic % ] 列で、ルーティングするトラフィックの合計量を表す割合 (0 ~ 100) を指定します。 次に、 [保存] を選択します。
設定を保存すると、指定した割合のクライアントが非運用スロットにランダムにルーティングされます。
クライアントが特定のスロットに自動的にルーティングされた後、そのスロットに 1 時間、または Cookie が削除されるまで "ピン留め" されます。 クライアントのブラウザーで、HTTP ヘッダー内の x-ms-routing-name Cookie を調べることにより、セッションが固定されているスロットを確認できます。 ステージング スロットにルーティングされる要求には、Cookie x-ms-routing-name=stagingがあります。 運用スロットにルーティングされる要求には、x-ms-routing-name=self という Cookie が設定されています。
運用トラフィックを手動でルーティングする
App Service では、トラフィックの自動ルーティングだけでなく、特定のスロットに要求をルーティングすることもできます。 このオプションは、ユーザーがベータ版アプリの利用を選択または拒否できるようにしたい場合に便利です。 運用トラフィックを手動でルーティングするには、x-ms-routing-name クエリ パラメーターを使用します。
ベータ版アプリの利用をユーザーが拒否できるようにするには、たとえば次のようなリンクを Web ページに配置します。
<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>
文字列 x-ms-routing-name=self に指定されているのは運用スロットです。 クライアント ブラウザーは、リンクにアクセスすると、運用スロットにリダイレクトされます。 以降のすべての要求には、セッションをその運用スロットに固定する x-ms-routing-name=self cookie が含まれます。
ベータ版アプリの利用をユーザーがオプトインできるようにするには、同じクエリ パラメーターを、非運用スロットの名前に対し設定します。 次に例を示します。
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
既定では、新しいスロットには 0%のルーティング規則があり、灰色で表示されます。 この値を明示的に 0% に設定すると (黒のテキストで表示されます)、ユーザーは x-ms-routing-name クエリ パラメーターを使用して、ステージング スロットに手動でアクセスできます。 ルーティングの割合が 0 に設定されているため、それらはスロットに自動的にルーティングされません。 この構成は、内部チームにスロットでの変更のテストを許可する一方で、ステージング スロットをパブリックから "非表示" にできる高度なシナリオです。
スロットを削除する
アプリを検索して選択します。
[ デプロイ>デプロイ スロット>削除するスロット>オーバービューを選択します。 アプリの種類が App Service (スロット) として表示され、デプロイ スロットを表示していることを通知します。
スロットを停止し、スロット内のトラフィックをゼロに設定します。
コマンド バーの [削除] を選択します。
Resource Manager テンプレートで自動化する
Azure Resource Manager テンプレート は、Azure リソースのデプロイと構成を自動化するための宣言型 JSON ファイルです。 Resource Manager テンプレートを使用してスロットをスワップするには、 Microsoft.Web/sites/slots リソースと Microsoft.Web/sites リソースに次の 2 つのプロパティを設定します。
buildVersion: スロットにデプロイされているアプリの現在のバージョンを表す文字列プロパティ。 例:v1、1.0.0.1、または2019-09-20T11:53:25.2887393-07:00。targetBuildVersion: スロットに必要なbuildVersion値を指定する文字列プロパティ。targetBuildVersion値が現在のbuildVersion値と等しくない場合は、指定したbuildVersion値を持つスロットを見つけることでスワップ操作をトリガーします。
Resource Manager テンプレートの例
次の Resource Manager テンプレートは、buildVersion スロットのstaging値を更新し、運用スロットにtargetBuildVersion値を設定することで、2 つのスロットをスワップします。 staging というスロットが必要です。
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"my_site_name": {
"defaultValue": "SwapAPIDemo",
"type": "String"
},
"sites_buildVersion": {
"defaultValue": "v1",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Web/sites/slots",
"apiVersion": "2018-02-01",
"name": "[concat(parameters('my_site_name'), '/staging')]",
"___location": "East US",
"kind": "app",
"properties": {
"buildVersion": "[parameters('sites_buildVersion')]"
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2018-02-01",
"name": "[parameters('my_site_name')]",
"___location": "East US",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
],
"properties": {
"targetBuildVersion": "[parameters('sites_buildVersion')]"
}
}
]
}
Resource Manager テンプレートはべき等です。 繰り返し実行し、スロットの同じ状態を生成できます。 テンプレートの変更をせずに、同じテンプレートで引き続き実行しても、スロットが既に目的の状態となっているため、スロットのスワップはトリガーされません。
スワップのトラブルシューティングを行う
スロットスワップ中にエラーが発生した場合、エラーはD:\home\LogFiles\eventlog.xmlに表示されます。 アプリケーション固有のエラー ログにも記録されます。
以下に、スワップの一般的なエラーをいくつか示します。
アプリケーション ルートへの HTTP 要求には時間枠が設けられています。 スワップ操作は、HTTP 要求ごとに 90 秒間待機し、最大 5 回再試行します。 すべての再試行がタイムアウトになると、スワップ操作は停止されます。
ローカル キャッシュの初期化は、アプリのコンテンツがローカル キャッシュに指定されているローカル ディスク クォータを超えると失敗する可能性があります。 詳細については、 Azure App Service のローカル キャッシュの概要に関するページを参照してください。
サイトの更新操作中に、"スロットの構成設定がスワップ用に準備されているため、スロットを変更できません" というエラーが発生する可能性があります。このエラーは、複数フェーズのスワップの最初のフェーズが終了しても、2 番目のフェーズが発生していない場合に発生する可能性があります。 また、スワップに失敗した場合にも発生する可能性があります。 この問題を解決するには、次の 2 つの方法があります。
- スワップ操作を取り消します。この操作により、サイトが古い状態にリセットされます。
- スワップ操作を完了すると、サイトが目的の新しい状態に更新されます。
スワップ操作をキャンセルまたは完了する方法については、この記事で前述した プレビューでのスワップ (複数フェーズスワップ) を参照してください。
カスタム ウォームアップ時には、HTTP 要求は外部 URL を経由することなく、内部的に作成されます。
Web.configの特定の URL 書き換え規則で失敗する可能性があります。 たとえば、ドメイン名のリダイレクトや HTTPS の適用に関する規則は、ウォームアップ要求がアプリ コードに到達するのを防ぐことができます。 この問題を回避するには、次の 2 つの条件を追加して書き換えルールを変更します。<conditions> <add input="{WARMUP_REQUEST}" pattern="1" negate="true" /> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>カスタム ウォームアップを行わなくても、URL 書き換えルールが HTTP 要求をブロックする場合があります。 この問題を回避するには、次の条件を追加して書き換えルールを変更します。
<conditions> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>スロットをスワップした後、アプリが予期せず再起動する可能性があります。 再起動は、スワップ後にホスト名のバインド構成が同期されないために発生します。この状況だけでは、再起動は発生しません。 ただし、記憶域ボリュームのフェールオーバーなど、基になる特定のストレージ イベントによってこれらの不一致が検出され、すべてのワーカー プロセスが強制的に再起動される可能性があります。
このような再起動を最小限に抑えるには、すべてのスロットで
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1アプリ設定を設定します。 ただし、このアプリケーション設定は Windows Communication Foundation (WCF) アプリでは動作しません。