ASP.NET では行わないことと、その代わりに行うことWhat not to do in ASP.NET, and what to do instead

このトピックでは、ASP.NET web プロジェクト内での複数のよくある間違いについて説明します。This topic describes several common mistakes people make within ASP.NET web projects. これらの一般的な誤りを回避するための推奨事項について説明します。It provides recommendations for what you should do to avoid these common mistakes. これは、ノルウェーの開発者のカンファレンスでDamian Edwardsによるプレゼンテーションに基づいています。It is based on a presentation by Damian Edwards at Norwegian Developers Conference.

免責事項Disclaimer

このトピックは、アプリケーションの安全性と効率性を確保するための完全なガイドではありません。This topic is not intended as a complete guide to ensure your application is secure and efficient. このトピックでは説明されていないセキュリティとパフォーマンスについては、ベストプラクティスに従う必要があります。You still need to follow best practices for security and performance that are not outlined in this topic. .NET のクラスとプロセスに関連する一般的な間違いを回避する方法についてのみ説明します。It only suggests how to avoid common mistakes related to .NET classes and processes.

概要Overview

このトピックには、次のセクションが含まれます。This topic contains the following sections:

標準への準拠Standards Compliance

コントロールアダプターControl adapters

推奨事項: アダプティブレンダリングのためにコントロールアダプターの使用を停止し、代わりに CSS メディアクエリと標準準拠の HTML を使用します。Recommendation: Stop using control adapters for adaptive rendering, and instead use CSS media queries and standards-compliant HTML.

.NET 2.0 では、さまざまなデバイスや環境用にカスタマイズされたプレゼンテーションコードをレンダリングするために、コントロールアダプターが導入されました。Controls Adapters were introduced in .NET 2.0 to render presentation code that was customized for different devices and environments. これで、このアダプティブレンダリングは CSS と HTML で実現できます。Now, this adaptive rendering can be accomplished with CSS and HTML. コントロールアダプターの使用を停止し、既存のアダプターを CSS と HTML に変換する必要があります。You should stop using Control Adapters and convert any existing adapters to CSS and HTML.

詳細については、「メディアクエリ」と「方法: モバイルページを ASP.NET WEB フォーム/MVC アプリケーションに追加する」を参照してください。For more information, see Media Queries and How To: Add Mobile Pages to Your ASP.NET Web Forms / MVC Application.

コントロールのスタイルプロパティStyle properties on controls

推奨事項: コントロールマークアップでのスタイル値の設定を停止します。代わりに、CSS スタイルシートで書式設定値を設定します。Recommendation: Stop setting style values in the control markup, and instead set formatting values in CSS stylesheets.

Web サーバーコントロールには、インラインスタイルプロパティの設定に使用できる多数のプロパティが含まれています。Web server controls contain dozens of properties which can be used to set in-line style properties. たとえば、ForeColor プロパティは、コントロールのテキストの色を設定します。For example, the ForeColor property sets the color of the text for a control. CSS スタイルシートを使用すると、これと同じ効果をより効率的に行うことができます。You can accomplish this same effect more efficiently through CSS stylesheets. スタイルシートを使用すると、スタイル値を一元化し、アプリケーション全体でこれらの値を設定しないようにすることができます。Stylesheets enable you to centralize style values and avoid setting these values throughout your application.

次の例は、テキストを赤に設定する CSS クラスを示しています。The following example shows a CSS class the sets text to red.

.CautionRow {
    color: red;
}

次の例では、CSS クラスを動的に適用する方法を示します。The next example shows how to dynamically apply the CSS class.

protected void CustomersGridView_RowDataBound(object sender, GridViewRowEventArgs e)
{
    if (e.Row.Cells[2].Text == "Unconfirmed")
    {
        e.Row.CssClass = "CautionRow";
    }
}

ページとコントロールのコールバックPage and control callbacks

推奨事項: ページとコントロールのコールバックの使用を停止し、代わりに、AJAX、UpdatePanel、MVC アクションメソッド、Web API、または SignalR のいずれかを使用します。Recommendation: Stop using page and control callbacks, and instead use any of the following: AJAX, UpdatePanel, MVC action methods, Web API, or SignalR.

以前のバージョンの ASP.NET では、ページとコントロールのコールバックメソッドを使用して、ページ全体を更新せずに web ページの一部を更新できました。In earlier versions of ASP.NET, Page and Control callback methods enabled you to update part of the web page without refreshing an entire page. AJAXUpdatePanelMVCWeb API 、またはSignalRを使用して部分ページ更新を実行できるようになりました。You can now accomplish partial-page updates through AJAX, UpdatePanel, MVC, Web API or SignalR. わかりやすい Url とルーティングに関する問題が発生する可能性があるため、コールバックメソッドの使用を停止する必要があります。You should stop using callback methods because they can cause issues with friendly URLs and routing. 既定では、コントロールはコールバックメソッドを有効にしませんが、コントロールでこの機能を有効にした場合は、無効にする必要があります。By default, controls do not enable callback methods, but if you enabled this feature in a control, you should disable it.

ブラウザー機能の検出Browser capability detection

推奨: 静的なブラウザー機能の検出の使用を停止し、代わりに動的な機能の検出を使用します。Recommendation: Stop using static browser capability detection, and instead use dynamic feature detection.

以前のバージョンの ASP.NET では、各ブラウザーでサポートされている機能は、XML ファイルに格納されていました。In earlier versions of ASP.NET, the supported features for each browser were stored in an XML file. 静的参照を使用した機能サポートの検出は、最適な方法ではありません。Detecting feature support through a static lookup is not the best approach. これで、 Modernizrなどの機能検出フレームワークを使用して、ブラウザーのサポートされている機能を動的に検出できます。Now, you can dynamically detect a browser's supported features by using a feature detection framework, such as Modernizr. 機能の検出では、メソッドまたはプロパティを使用して、ブラウザーが目的の結果を生成したかどうかを確認することによって、サポートが決定されます。Feature detection determines support by attempting to use a method or property and then checking to see if the browser produced the desired result. 既定では、Modernizr は Web アプリケーションテンプレートに含まれています。By default, Modernizr is included in the Web application templates.

SecuritySecurity

要求の検証Request validation

推奨事項: ユーザー入力を検証し、ユーザーからの出力をエンコードします。Recommendation: Validate user input, and encode output from users.

要求の検証は、ASP.NET の機能の1つであり、認識された脅威が見つかると、各要求を調べ、要求を停止します。Request validation is a feature of ASP.NET that inspects each request and stops the request if a perceived threat is found. クロスサイトスクリプティング攻撃に対してアプリケーションをセキュリティで保護するための要求の検証に依存しないでください。Do not depend on request validation for securing your application against cross-site scripting attacks. 代わりに、ユーザーからのすべての入力を検証し、出力をエンコードします。Instead, validate all input from users and encode the output. 一部のケースでは、正規表現を使用して入力を検証できますが、より複雑なケースでは、値が許可された値と一致するかどうかを判断する .NET クラスを使用してユーザー入力を検証する必要があります。In some limited cases, you can use regular expressions to validate the input, but in more complicated cases you should validate user input by using .NET classes that determine if the value matches allowed values.

次の例は、Uri クラスの静的メソッドを使用して、ユーザーが指定した Uri が有効かどうかを判断する方法を示しています。The following example shows how to use a static method in the Uri class to determine whether the Uri provided by a user is valid.

var isValidUri = Uri.IsWellFormedUriString(passedUri, UriKind.Absolute);

ただし、Uri を十分に検証するには、http または httpsが指定されていることを確認する必要もあります。However, to sufficiently verify the Uri, you should also check to make sure it specifies http or https. 次の例では、インスタンスメソッドを使用して、Uri が有効であることを確認します。The following example uses instance methods to verify that the Uri is valid.

var uriToVerify = new Uri(passedUri);
var isValidUri = uriToVerify.IsWellFormedOriginalString();
var isValidScheme = uriToVerify.Scheme == "http" || uriToVerify.Scheme == "https";

ユーザー入力を HTML として、または SQL クエリにユーザー入力を含めて表示する前に、その値をエンコードして、悪意のあるコードが含まれていないことを確認します。Before rendering user input as HTML or including user input in a SQL query, encode the values to ensure malicious code is not included.

次に示すように、<%:%> 構文を使用してマークアップの値を HTML エンコードできます。You can HTML encode the value in markup with the <%: %> syntax, as shown below.

<span><%: userInput %></span>

また、Razor 構文では、次に示すように、@ を使用して HTML エンコードできます。Or, in Razor syntax, you can HTML encode with @, as shown below.

<span>@userInput</span>

次の例は、コードビハインドで値を HTML エンコードする方法を示しています。The next example shows how to HTML encode a value in code-behind.

var encodedInput = Server.HtmlEncode(userInput);

SQL コマンドの値を安全にエンコードするには、 SqlParameterなどのコマンドパラメーターを使用します。To safely encode a value for SQL commands, use command parameters such as the SqlParameter.

Cookie なしのフォーム認証とセッションCookieless forms authentication and session

推奨: cookie が必要です。Recommendation: Require cookies.

クエリ文字列で認証情報を渡すことは、セキュリティで保護されていません。Passing authentication information in the query string is not secure. そのため、アプリケーションに認証が含まれている場合は、cookie が必要です。Therefore, require cookies when your application includes authentication. Cookie に機密情報が格納されている場合は、cookie に SSL を要求することを検討してください。If your cookie stores sensitive information, consider requiring SSL for the cookie.

次の例は、web.config ファイルでを指定する方法を示しています。フォーム認証では、SSL を使用して送信される cookie が必要です。The following example shows how to specify in the Web.config file that Forms Authentication requires a cookie that is transmitted over SSL.

<authentication mode="Forms">
  <forms loginUrl="member_login.aspx"
    cookieless="UseCookies"
    requireSSL="true"
    path="/MyApplication" />
</authentication>

EnableViewStateMacEnableViewStateMac

推奨: false に設定しないでください。Recommendation: Never set to false.

既定では、EnableViewStateMac は true に設定されています。By default, EnableViewStateMac is set to true. アプリケーションがビューステートを使用していない場合でも、EnableViewStateMac を false に設定しないでください。Even if your application is not using view state, do not set EnableViewStateMac to false. この値を false に設定すると、アプリケーションはクロスサイトスクリプトに対して脆弱になります。Setting this value to false will make your application vulnerable to cross-site scripting.

ASP.NET 4.5.2 以降では、ランタイムによってEnableViewStateMac = trueが適用されます。Starting with ASP.NET 4.5.2, the runtime enforces EnableViewStateMac=true. False に設定した場合でも、ランタイムはこの値を無視し、true に設定された値を使用して処理を続行します。Even if you set it to false, the runtime ignores this value and proceeds with the value set to true. 詳細については、「 ASP.NET 4.5.2 And EnableViewStateMac」を参照してください。For more information, see ASP.NET 4.5.2 and EnableViewStateMac.

次の例は、EnableViewStateMac を true に設定する方法を示しています。The following example shows how to set EnableViewStateMac to true. この値は、既定で true に設定されているため、実際に true に設定する必要はありません。You do not need to actually set this value to true because it is true by default. ただし、アプリケーションの任意のページで false に設定した場合は、すぐにこの値を修正する必要があります。However, if you have set it to false on any page in your application, you must immediately correct this value.

<%@ Page language="C#" EnableViewStateMac="true" %>

中程度の信頼Medium trust

推奨: セキュリティ境界として中程度の信頼 (またはその他の信頼レベル) に依存しないでください。Recommendation: Do not depend on Medium Trust (or any other trust level) as a security boundary.

部分信頼では、アプリケーションを適切に保護することはできないため、使用しないでください。Partial trust does not adequately protect your application and should not be used. 代わりに、完全信頼を使用して、信頼されていないアプリケーションを別のアプリケーションプールに分離します。Instead, use Full Trust, and isolate untrusted applications in separate application pools. また、各アプリケーションプールを一意の id で実行します。Also, run each application pool under a unique identity. 詳細については、「 ASP.NET 部分信頼ではアプリケーションの分離が保証されない」を参照してください。For more information, see ASP.NET Partial Trust does not guarantee application isolation.

<appSettings><appSettings>

推奨: <appSettings> 要素のセキュリティ設定を無効にしないでください。Recommendation: Do not disable security settings in <appSettings> element.

AppSettings 要素には、セキュリティ更新プログラムに必要な多くの値が含まれています。The appSettings element contains many values which are required for security updates. これらの値は変更したり無効にしたりしないでください。You should not change or disable these values. 更新プログラムを展開するときにこれらの値を無効にする必要がある場合は、展開の完了後すぐに再度有効にしてください。If you must disable these values when deploying an update, immediately re-enable after completing deployment.

詳細については、「 ASP.NET AppSettings 要素」を参照してください。For details, see ASP.NET appSettings Element.

UrlPathEncodeUrlPathEncode

推奨: 代わりにUrlEncodeを使用してください。Recommendation: Use UrlEncode instead.

UrlPathEncode メソッドが .NET Framework に追加され、特定のブラウザーの互換性の問題を解決します。The UrlPathEncode method was added to the .NET Framework to resolve a very specific browser compatibility problem. URL を適切にエンコードすることはできず、クロスサイトスクリプトからアプリケーションを保護することもありません。It does not adequately encode a URL, and does not protect your application from cross-site scripting. アプリケーションでは使用しないでください。You should never use it in your application. 代わりに、 UrlEncodeを使用してください。Instead, use UrlEncode.

次の例は、エンコードされた URL をハイパーリンクコントロールのクエリ文字列パラメーターとして渡す方法を示しています。The following example shows how to pass an encoded URL as a query string parameter for a hyperlink control.

string destinationURL = "http://www.contoso.com/default.aspx?user=test";
NextPage.NavigateUrl = "~/Finish?url=" + Server.UrlEncode(destinationURL);

信頼性とパフォーマンスReliability and performance

PreSendRequestHeaders と PreSendRequestContentPreSendRequestHeaders and PreSendRequestContent

推奨: これらのイベントをマネージモジュールで使用しないでください。Recommendation: Do not use these events with managed modules. 代わりに、必要なタスクを実行するネイティブ IIS モジュールを記述します。Instead, write a native IIS module to perform the required task. ネイティブコード HTTP モジュールの作成」を参照してください。See Creating Native-Code HTTP Modules.

ネイティブ IIS モジュールでは、 PreSendRequestHeadersおよびPresendrequestcontentイベントを使用できます。You can use the PreSendRequestHeaders and PreSendRequestContent events with native IIS modules.

Warning

IHttpModuleを実装するマネージモジュールで PreSendRequestHeaders および PreSendRequestContent を使用しないでください。Do not use PreSendRequestHeaders and PreSendRequestContent with managed modules that implement IHttpModule. これらのプロパティを設定すると、非同期要求に関する問題が発生する可能性があります。Setting these properties can cause issues with asynchronous requests. アプリケーションで要求されたルーティング (ARR) と websocket を組み合わせると、w3wp.exe がクラッシュする原因となるアクセス違反例外が発生する可能性があります。The combination of Application Requested Routing (ARR) and websockets might lead to access violation exceptions that can cause w3wp to crash. たとえば、iiscore のようになります。Iiscore .dll の W3_CONTEXT_BASE:: GetIsLastNotification + 68 で、アクセス違反例外 (0xC0000005) が発生しました。For example, iiscore!W3_CONTEXT_BASE::GetIsLastNotification+68 in iiscore.dll has caused an access violation exception (0xC0000005).

Web フォームを使用した非同期ページイベントAsynchronous page events with web forms

推奨事項: Web フォームでは、ページのライフサイクルイベントに対して非同期の void メソッドを記述しないでください。代わりに、非同期コード用にRegisterAsyncTaskを使用します。Recommendation: In Web Forms, avoid writing async void methods for Page lifecycle events, and instead use Page.RegisterAsyncTask for asynchronous code.

Asyncvoidを使用してページイベントをマークすると、非同期コードがいつ終了したかを判断できません。When you mark a page event with async and void, you cannot determine when the asynchronous code has finished. 代わりに、Page. RegisterAsyncTask を使用して非同期コードを実行し、その完了を追跡できるようにします。Instead, use Page.RegisterAsyncTask to run the asynchronous code in a way that enables you to track its completion.

次の例は、非同期コードを含むボタンクリックハンドラーを示しています。The following example shows a button click handler that contains asynchronous code. この例では、非同期タスクの簡略化された例としてのみ提供される文字列値を非同期に読み取り、推奨される方法としては使用しません。This example includes reading a string value asynchronously, which is provided only as a simplified example of an asynchronous task and not as a recommended practice.

protected void StartAsync_Click(object sender, EventArgs e)
{
    Page.RegisterAsyncTask(new PageAsyncTask(async() =>
    {
        string stringToRead = "Long text value";

        using (StringReader reader = new StringReader(stringToRead))
        {
            string readText = await reader.ReadToEndAsync();
            Result.Text = readText;
        }
    }));
}

非同期タスクを使用している場合は、web.config ファイルで Http ランタイムターゲットフレームワークを 4.5 (またはそれ以降) に設定します。If you are using asynchronous Tasks, set the Http runtime target framework to 4.5 (or later) in the Web.config file. ターゲットフレームワークを4.5 に設定すると、.NET 4.5 で追加された新しい同期コンテキストが有効になります。Setting the target framework to 4.5 turns on the new synchronization context that was added in .NET 4.5. この値は、Visual Studio の新しいプロジェクトで既定で設定されますが、既存のプロジェクトを操作している場合は設定されません。This value is set by default in new projects in Visual Studio, but is not be set if you are working with an existing project.

<system.web>
    <httpRuntime TargetFramework="4.5" />
</system.web>

起動と破棄の作業Fire-and-forget work

推奨事項: ASP.NET 内で要求を処理する場合は、起動と破棄の作業 (QueueUserWorkItem メソッドの呼び出し、デリゲートを繰り返し呼び出すタイマーの作成など) を行わないようにしてください。Recommendation: When handling a request within ASP.NET, avoid launching fire-and-forget work (such calling the ThreadPool.QueueUserWorkItem method or creating a timer that repeatedly calls a delegate).

アプリケーションの ASP.NET 内で実行される作業を忘れることがある場合、アプリケーションは同期されない可能性があります。いつでも、アプリドメインを破棄できます。つまり、進行中のプロセスがアプリケーションの現在の状態と一致しなくなる可能性があります。If your application has fire-and-forget work that runs within ASP.NET, your application can get out of sync. At any time, the app domain can be destroyed which means your ongoing process may no longer match the current state of the application.

この種類の作業は、ASP.NET の外部で移動する必要があります。You should move this type of work outside of ASP.NET. Azure の Web ジョブ、Windows サービス、または Worker ロールを使用して、進行中の作業を実行し、別のプロセスからそのコードを実行できます。You can use a Web Jobs, Windows Service or a Worker role in Azure to perform ongoing work, and run that code from another process.

ASP.NET 内でこの作業を実行する必要がある場合は、 WebBackgrounderという名前の Nuget パッケージを追加してコードを実行できます。If you must perform this work within ASP.NET, you can add the Nuget package called WebBackgrounder to run the code.

要求エンティティ本体Request entity body

推奨事項: ハンドラーの execute イベントの前に、InputStream または要求を読み取らないようにします。Recommendation: Avoid reading Request.Form or Request.InputStream before the handler's execute event.

最初に、要求. フォームまたは InputStream から読み取る必要があります。The earliest you should read from Request.Form or Request.InputStream is during the handler's execute event. MVC では、コントローラーはハンドラーであり、アクションメソッドが実行されるときに execute イベントです。In MVC, the Controller is the handler and the execute event is when the action method runs. Web フォームでは、ページはハンドラーであり、execute イベントは、ページの Init イベントが発生したときに発生します。In Web Forms, the Page is the handler and the execute event is when the Page.Init event fires. Execute イベントより前に要求エンティティ本体を読み取ると、要求の処理が妨げられます。If you read the request entity body earlier than the execute event, you interfere with the processing of the request.

Execute イベントの前に要求エンティティ本体を読み取る必要がある場合は、 GetBufferlessInputStreamまたはhttprequest.getbufferedinputstreamを使用します。If you need to read the request entity body before the execute event, use either Request.GetBufferlessInputStream or Request.GetBufferedInputStream. GetBufferlessInputStream を使用する場合は、要求から生のストリームを取得し、要求全体を処理する必要があると想定します。When you use GetBufferlessInputStream, you get the raw stream from the request, and assume responsibility for processing the entire request. GetBufferlessInputStream を呼び出した後、InputStream は ASP.NET によって設定されていないため、使用できません。After calling GetBufferlessInputStream, Request.Form and Request.InputStream are not available because they have not been populated by ASP.NET. Httprequest.getbufferedinputstream を使用すると、要求からストリームのコピーが取得されます。When you use GetBufferedInputStream, you get a copy of the stream from the request. 要求の形式と InputStream は、ASP.NET が他のコピーを設定するため、後で要求の中でも使用できます。Request.Form and Request.InputStream are still available later in the request because ASP.NET populates the other copy.

応答。リダイレクトと応答終了Response.Redirect and Response.End

推奨事項: Response を呼び出した後のスレッドの処理方法の違いに注意してください。リダイレクト (String)Recommendation: Be aware of differences in how thread is handled after calling Response.Redirect(String).

Response. Redirect (String)メソッドは、Response. End メソッドを呼び出します。The Response.Redirect(String) method calls the Response.End method. 同期プロセスでは、要求を呼び出します。リダイレクトを実行すると、現在のスレッドがすぐに中止されます。In a synchronous process, calling Request.Redirect causes the current thread to immediately abort. ただし、非同期プロセスでは、Response を呼び出すと、現在のスレッドが中止されないため、要求に対してコードの実行が続行されます。However, in an asynchronous process, calling Response.Redirect does not abort the current thread, so code execution continues for the request. 非同期プロセスでは、メソッドからタスクを返してコードの実行を停止する必要があります。In an asynchronous process, you must return the Task from the method to stop the code execution.

MVC プロジェクトでは、Response. Redirect を呼び出すことはできません。In an MVC project, you should not call Response.Redirect. 代わりに、RedirectResult を返します。Instead, return a RedirectResult.

EnableViewState と ViewStateModeEnableViewState and ViewStateMode

推奨事項: ビューステートを使用するコントロールをきめ細かく制御できるように、EnableViewState ではなく ViewStateMode を使用します。Recommendation: Use ViewStateMode, instead of EnableViewState, to provide granular control over which controls use view state.

Page ディレクティブで EnableViewState を false に設定すると、ページ内のすべてのコントロールに対してビューステートが無効になり、有効にすることはできません。When you set EnableViewState to false in the Page directive, view state is disabled for all controls within the page and cannot be enabled. ページの特定のコントロールに対してのみビューステートを有効にする場合は、ページの ViewStateMode を Disabled に設定します。If you want to enable view state for only certain controls in your page, set ViewStateMode to Disabled for the Page.

<%@ Page ViewStateMode="Disabled" . . . %>

次に、ビューステートを実際に必要とするコントロールに対してのみ ViewStateMode を Enabled に設定します。Then, set ViewStateMode to Enabled on only the controls that actually need view state.

<asp:GridView ViewStateMode="Enabled" runat="server">

必要なコントロールに対してのみビューステートを有効にすることで、web ページのビューステートのサイズを縮小できます。By enabling view state for only the controls that need it, you can shrink the size of the view state for your web pages.

SqlMembershipProviderSqlMembershipProvider

推奨事項: ユニバーサルプロバイダーを使用します。Recommendation: Use Universal Providers.

現在のプロジェクトテンプレートでは、SqlMembershipProvider がASP.NET ユニバーサルプロバイダーに置き換えられました。これは NuGet パッケージとして利用できます。In the current project templates, SqlMembershipProvider has been replaced by ASP.NET Universal Providers, which is available as a NuGet package. 以前のバージョンのテンプレートを使用してビルドされたプロジェクトで SqlMembershipProvider を使用している場合は、ユニバーサルプロバイダーに切り替える必要があります。If you are using SqlMembershipProvider in a project that was built with an earlier version of the templates, you should switch to Universal Providers. ユニバーサルプロバイダーは、Entity Framework によってサポートされているすべてのデータベースで動作します。The Universal Providers work with all databases that are supported by Entity Framework.

詳細については、「 ASP.NET ユニバーサルプロバイダーの概要」を参照してください。For more information, see Introducing ASP.NET Universal Providers.

実行時間の長い要求 (> 110 秒)Long-running requests (>110 seconds)

推奨事項: 接続されたクライアントにwebsocketまたはSignalRを使用し、非同期 i/o 操作を使用します。Recommendation: Use WebSockets or SignalR for connected clients, and use asynchronous I/O operations.

実行時間の長い要求では、web アプリケーションで予期しない結果が発生し、パフォーマンスが低下する可能性があります。Long-running requests can cause unpredictable results and poor performance in your web application. 要求の既定のタイムアウト設定は110秒です。The default timeout setting for a request is 110 seconds. 実行時間の長い要求でセッション状態を使用している場合、ASP.NET は110秒後にセッションオブジェクトのロックを解除します。If you are using session state with a long-running request, ASP.NET will release the lock on the Session object after 110 seconds. ただし、ロックが解除され、操作が正常に完了しない可能性がある場合、アプリケーションはセッションオブジェクトに対する操作の途中である可能性があります。However, your application might be in the middle of an operation on the Session object when the lock is released, and the operation might not complete successfully. 最初の要求の実行中にユーザーからの2番目の要求がブロックされた場合、2番目の要求では、不整合な状態にあるセッションオブジェクトにアクセスする可能性があります。If a second request from the user is blocked while the first request is running, the second request might access the Session object in an inconsistent state.

アプリケーションにブロッキング (または同期) i/o 操作が含まれている場合は、アプリケーションが応答しなくなります。If your application includes blocking (or synchronous) I/O operations, the application will be unresponsive.

パフォーマンスを向上させるには、.NET Framework で非同期 i/o 操作を使用します。To improve performance, use the asynchronous I/O operations in the .NET Framework. また、Websocket または SignalR を使用して、クライアントをサーバーに接続します。Also, use WebSockets or SignalR for connecting clients to the server. これらの機能は、実行時間の長い要求を効率的に処理するように設計されています。These features are designed to efficiently handle long-running requests.