ASP.NET 4 の破壊的変更
このドキュメントでは、以前のリリース (ASP.NET 4 Beta 1、Beta 2 リリースなど) を使用して作成されたアプリケーションに影響する可能性がある .NET Framework バージョン 4 リリースに対して行われた変更について説明します。
内容
Web.config ファイルの ControlRenderingCompatibilityVersion 設定
ClientIDMode の変更
HtmlEncode と UrlEncode で単一引用符をエンコードするようになりました
ASP.NET ページ (.aspx) パーサーの厳格化
ブラウザー定義ファイルの更新
ルート Web 構成ファイルから削除された System.Web.Mobile.dll
ASP.NET 要求の検証
既定のハッシュ アルゴリズムが HMACSHA256 になりました
新しい ASP.NET 4 ルート構成に関連する構成エラー
ASP.NET 4 の子アプリケーションが、ASP.NET 2.0 または ASP.NET 3.5 アプリケーションの場合に起動できない
SharePoint がインストールされているコンピューターで ASP.NET 4 Web サイトを起動できない
HttpRequest.FilePath プロパティに PathInfo 値が含まれない
ASP.NET 2.0 アプリケーションで eurl.axd を参照する HttpException エラーが生成される可能性がある
IIS 7 または IIS 7.5 統合モードの既定のドキュメントでイベント ハンドラーが発生しない可能性がある
ASP.NET コード アクセス セキュリティ (CAS) の実装に対する変更
System.Web.Security 名前空間の MembershipUser とその他の型が移動されました
Vary * HTTP ヘッダーへの出力キャッシュの変更
Passport の System.Web.Security の種類は廃止されました
MenuItem.PopOutImageUrl プロパティが ASP.NET 4 でイメージをレンダリングできない
Menu.StaticPopOutImageUrl と Menu.DynamicPopOutImageUrl は、パスに円記号が含まれている場合にイメージをレンダリングできない
免責事項
Web.config ファイルの ControlRenderingCompatibilityVersion 設定
ASP.NET コントロールは、マークアップのレンダリング方法をより正確に指定できるように、.NET Framework バージョン 4 で変更されています。 以前のバージョンの .NET Framework では、無効にする方法がないマークアップを生成するコントロールがありました。 ASP.NET 4 では、この種類のマークアップが既定で生成されなくなりました。
Visual Studio 2010 を使用して ASP.NET 2.0 または ASP.NET 3.5 からアプリケーションをアップグレードする場合は、レガシ レンダリングを維持する設定が、ツールによって Web.config ファイルに自動的に追加されます。 ただし、IIS のアプリケーション プールを変更して .NET Framework 4 をターゲットにするようにアプリケーションをアップグレードする場合、ASP.NET では新しい表示モードが既定で使用されます。 新しいレンダリング モードを無効にするには、Web.config ファイルに次の設定を追加します。
<pages controlRenderingCompatibilityVersion="3.5" />
新しい動作によって生み出されるレンダリングの主な変更は次のとおりです。
- Image と ImageButton コントロールでは、
border="0"属性はレンダリングされなくなりました。 - BaseValidator クラスとそこから派生する検証コントロールでは、既定で赤いテキストがレンダリングされなくなりました。
- HtmlForm コントロールでは、name 属性はレンダリングされません。
- Table コントロールでは、
border="0"属性は表示されなくなりました。 - ユーザー入力用にデザインされていないコントロール (たとえば、Label コントロール) では、Enabled プロパティが false に設定されている場合 (または、コンテナー コントロールからこの設定を継承する場合) に
disabled="disabled"属性が表示されなくなりました。
ClientIDMode の変更
ASP.NET 4 の新しい ClientIDMode 設定では、ASP.NET が HTML 要素の id 属性を生成する方法を指定できます。 以前のバージョンの ASP.NET では、既定の動作は ClientIDMode の AutoID 設定と同じでした。 しかし、既定の設定は Predictable になりました。
Visual Studio 2010 を使用して ASP.NET 2.0 または ASP.NET 3.5 からアプリケーションをアップグレードする場合は、以前のバージョンの .NET Framework の動作を維持する設定が、ツールによって Web.config ファイルに自動的に追加されます。 ただし、IIS のアプリケーション プールを変更して .NET Framework 4 をターゲットにするようにアプリケーションをアップグレードする場合、ASP.NET では新しいモードが既定で使用されます。 新しいクライアント ID モードを無効にするには、Web.config ファイルに次の設定を追加します。
<pages clientIDMode="AutoID" />
HtmlEncode と UrlEncode で単一引用符をエンコードするようになりました
ASP.NET 4 では、HttpUtility クラスと HttpServerUtility クラスの HtmlEncode メソッドと UrlEncode メソッドが更新され、単一引用符文字 (') が次のようにエンコードされるようになっています。
- HtmlEncode メソッドは、単一引用符のインスタンスを ' のようにエンコードします。
- UrlEncode メソッドは、単一引用符のインスタンスを %27 のようにエンコードします。
ASP.NET ページ (.aspx) パーサーの厳格化
ASP.NET ページ (.aspx ファイル) とユーザー コントロール (.ascx ファイル) のページ パーサーは、ASP.NET 4 ではより厳密であり、無効なマークアップのより多くのインスタンスを拒否します。 たとえば、次の 2 つのスニペットは、以前のリリースの ASP.NET で正常に解析されますが、ASP.NET 4 ではパーサー エラーが発生するようになりました。
<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue" ; />
HiddenField タグの末尾に無効なセミコロンがあることに注意してください。
<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
style="display:inline; CssClass="searchLink" />
CssClass 属性に実行される閉じていない style 属性に注目してください。
ブラウザー定義ファイルの更新
ブラウザー定義ファイルは、新しいブラウザーとデバイスや、更新されたブラウザーとデバイスに関する情報を含むように、更新されました。 Netscape Navigator などの古いブラウザーとデバイスは削除され、Google Chrome や Apple iPhone などの新しいブラウザーとデバイスが追加されました。
削除されたブラウザー定義の 1 つを継承するカスタム ブラウザー定義がご利用のアプリケーションに含まれている場合は、エラーが表示されます。 たとえば、IE2 ブラウザー定義から継承するブラウザー定義が App_Browsers フォルダーに含まれている場合は、次の構成エラー メッセージが表示されます。
- ID 'IE2' のブラウザーまたはゲートウェイ要素が見つかりません。
Note
HttpBrowserCapabilities オブジェクト (ページの Request.Browser プロパティによって公開されます) は、ブラウザー定義ファイルによって駆動されます。 そのため、ASP.NET 4 でこのオブジェクトのプロパティにアクセスすることで返される情報は、以前のバージョンの ASP.NET で返された情報とは異なる場合があります。
次のフォルダーからブラウザー定義ファイルをコピーすることで、以前のブラウザー定義ファイルに戻すことができます。
Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
ASP.NET 4 の対応する \CONFIG\Browsers フォルダーにファイルをコピーします。 ファイルをコピーしたら、Aspnet_regbrowsers.exe コマンドライン ツールを実行します。
ルート Web 構成ファイルから削除された System.Web.Mobile.dll
以前のバージョンの ASP.NET では、System.Web.Mobile.dll アセンブリへの参照は、assemblies セクションにある、ルートの Web.config ファイルに含まれていました。 パフォーマンスを向上させるために、このアセンブリへの参照は削除されました。
System.Web.Mobile.dll アセンブリは ASP.NET 4 に含まれていますが、非推奨です。 System.Web.Mobile.dll アセンブリに含まれる型を使用する場合は、ルートの Web.config ファイルまたはアプリケーションの Web.config ファイルにアセンブリへの参照を追加します。 たとえば、(非推奨の) ASP.NET モバイル コントロールのいずれかを使用する場合は、System.Web.Mobile.dll アセンブリへの参照を Web.config ファイルに追加する必要があります。
ASP.NET 要求の検証
ASP.NET の要求検証機能は、クロスサイト スクリプティング (XSS) 攻撃に対する特定のレベルの既定の保護を提供します。 以前のバージョンの ASP.NET では、要求の検証は既定で有効でした。 ただし、ASP.NET ページ (.aspx ファイルとそのクラス ファイル) にのみ適用され、それらのページが実行されている場合にのみ適用されます。
ASP.NET 4 では、HTTP 要求の BeginRequest フェーズの前に要求検証が有効になっているため、既定では、すべての要求に対して要求の検証が有効になっています。 その結果、要求の検証は、.aspx ページ要求だけでなく、すべての ASP.NET リソースの要求に適用されます。 これには、Web サービス呼び出しやカスタム HTTP ハンドラーなどの要求が含まれます。 カスタム HTTP モジュールが HTTP 要求の内容を読み取っている場合も、要求の検証がアクティブになります。
その結果、以前にエラーをトリガーしなかった要求に対して要求検証エラーが発生する可能性があります。 ASP.NET 2.0 の要求検証機能の動作に戻すには、Web.config ファイルに次の設定を追加します。
<httpRuntime requestValidationMode="2.0" />
しかし、要求検証エラーを分析して、既存のハンドラー、モジュール、またはその他のカスタム コードが、XSS 攻撃ベクトルである可能性のある安全でない可能性のある HTTP 入力にアクセスするかどうかを判断することをお勧めします。
既定のハッシュ アルゴリズムが HMACSHA256 になりました
ASP.NET では、暗号化とハッシュ アルゴリズムの両方を使用して、フォーム認証 Cookie やビュー ステートなどのデータをセキュリティで保護します。 既定では、ASP.NET 4 は Cookie とビュー状態のハッシュ操作に HMACSHA256 アルゴリズムを使用するようになりました。 以前のバージョンの ASP.NET は、以前の HMACSHA1 アルゴリズムを使用していました。
フォーム認証 Cookie などのデータが複数の .NET Framework バージョンにわたって動作する必要がある、ASP.NET 2.0 と ASP.NET 4 が混在する環境を実行すると、アプリケーションが影響を受ける可能性があります。 以前の HMACSHA1 アルゴリズムを使用するように ASP.NET 4 Web アプリケーションを構成するには、Web.config ファイルに次の設定を追加します。
<machineKey validation="SHA1" />
新しい ASP.NET 4 ルート構成に関連する構成エラー
.NET Framework 4 (と、したがって ASP.NET 4) のルート構成ファイル (machine.config ファイルとルート Web.config ファイル) は、ASP.NET 3.5 のアプリケーション Web.config ファイルに記述されていた定型構成情報の大部分を含むように更新されました。 マネージド IIS 7 と IIS 7.5 構成システムは複雑であるため、ASP.NET 4 の下で、また IIS 7 と IIS 7.5 の下で ASP.NET 3.5 アプリケーションを実行すると、ASP.NET または IIS 構成のエラーが発生することがあります。
実用的な場合は、Visual Studio 2010 のプロジェクト アップグレード ツールを使用して、ASP.NET 3.5 アプリケーションを ASP.NET 4 にアップグレードすることをお勧めします。 Visual Studio 2010 は、ASP.NET 4 の適切な設定を含むように ASP.NET 3.5 アプリケーションの Web.config ファイルを自動的に変更します。
しかし、再コンパイルしないで .NET Framework 4 を使用して、ASP.NET 3.5 アプリケーションを実行するシナリオはサポートされます。 その場合は、アプリケーションの Web.config ファイルを手動で変更してから、.NET Framework 4 の下で、および IIS 7 または IIS 7.5 の下でアプリケーションの実行が必要になる場合があります。
次の 2 つのセクションでは、さまざまなソフトウェアの組み合わせに対して行う必要がある変更について説明します。
修正プログラム KB958854 も SP2 もインストールされていない Windows Vista SP1 または Windows Server 2008 SP1。 この構成では、IIS 7 構成システムは、アプリケーション レベル Web.config のファイルと ASP.NET 2.0 machine.config ファイルを比較することで、アプリケーションのマネージド構成を誤ってマージします。 このため、IIS 7 の検証エラーが発生しないようにするには、.NET Framework 3.5 以降のアプリケーション レベル Web.config のファイルに system.web.extensions 構成セクション定義 (要素) が必要です。
ただし、Visual Studio 2008 で導入された元の定型構成セクション定義と正確に一致しないアプリケーション レベル Web.config のファイル エントリを手動で変更すると、ASP.NET 構成エラーが発生します。 (Visual Studio 2008 によって生成される既定の構成エントリは正しく機能します)。一般的な問題は、Web.config ファイルを手動で変更すると、さまざまな構成セクション定義で見つかった構成属性 allowDefinition と requirePermission が除外されることです。 これにより、アプリケーション レベルの Web.config ファイルの省略された構成セクションと、ASP.NET 4 machine.config ファイル内の完全な定義が一致しません。 その結果、実行時に、ASP.NET 4 構成システムによって構成エラーがスローされます。
Windows Vista SP2、Windows Server 2008 SP2、Windows 7、Windows Server 2008 R2、および修正プログラム KB958854 がインストールされている Windows Vista SP1 と Windows Server 2008 SP1。
このシナリオでは、IIS 7 と IIS 7.5 ネイティブ構成システムは、マネージド構成セクション ハンドラーに対して定義されている type 属性に対してテキスト比較を実行するため、構成エラーを返します。 Visual Studio 2008 と Visual Studio 2008 SP1 によって生成されるすべての Web.config ファイルは、system.web.extensions (および関連する) 構成セクション ハンドラーの型文字列に "3.5" が含まれているため、また、ASP.NET 4 machine.config ファイルには、同じ構成セクション ハンドラーの type 属性に "4.0" が含まれているため、Visual Studio 2008 または Visual Studio 2008 SP1 で生成されたアプリケーションは、IIS 7 と IIS 7.5 で構成検証に常に失敗します。
これらの問題を解決する
最初のシナリオの回避策は、Visual Studio 2008 によって自動的に生成された Web.config ファイルから定型構成テキストを含めることによって、アプリケーション レベルの Web.config ファイルを更新することです。
最初のシナリオに対するもう 1 つの回避策は、Vista または Windows Server 2008 用 Service Pack 2 をコンピューターにインストールし、IIS 構成システムの不適切な構成マージ動作を修正することです。 ただし、これらのアクションのいずれかを実行すると、2 番目のシナリオで説明されている問題が原因で、アプリケーションで構成エラーが発生する可能性があります。
2 番目のシナリオの回避策は、すべての system.web.extensions 構成セクション定義と構成セクション グループ定義をアプリケーション レベルの Web.config ファイルから削除またはコメントアウトすることです。 これらの定義は通常、アプリケーション レベルの Web.config ファイルの先頭にあり、configSections 要素とその子によって識別できます。
どちらのシナリオでも、system.codedom セクションも手動で削除することをお勧めしますが、これは必須ではありません。
ASP.NET 4 の子アプリケーションが、ASP.NET 2.0 または ASP.NET 3.5 アプリケーションの場合に起動できない
旧バージョンの ASP.NET を実行する子アプリケーションとして構成されている ASP.NET 4 アプリケーションは、構成エラーまたはコンパイル エラーにより起動しない場合があります。 次の例は、影響を受けるアプリケーションのディレクトリ構造を示しています。
/parentwebapp (ASP.NET 2.0 または ASP.NET 3.5 を使用するように構成)
/childwebapp (ASP.NET 4 を使用するように構成)
childwebapp フォルダー内のアプリケーションは IIS 7 または IIS 7.5 で起動できず、構成エラーが報告されます。 エラー テキストには、次のようなメッセージが含まれます。
The requested page cannot be accessed because the related configuration data for the page is invalid.The configuration section 'configSections' cannot be read because it is missing a section declaration.
IIS 6 では、childwebapp フォルダー内のアプリケーションも起動に失敗しますが、別のエラーが報告されます。 たとえば、エラー テキストには次のようなメッセージが表示される場合があります。
The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file
これらのシナリオは、parentwebapp フォルダー内の親アプリケーションからの構成情報が、childwebapp フォルダー内の子 Web アプリケーションによって使用される最終的なマージされた構成設定を決定する構成情報の階層の一部であるために発生します。 ASP.NET 4 Web アプリケーションが IIS 7 (または IIS 7.5) または IIS 6 で実行されているかどうかに応じて、IIS 構成システムまたは ASP.NET 4 コンパイル システムのいずれかがエラーを返します。
この問題を解決し、子 ASP.NET 4 アプリケーションを動作させる手順は、IIS 6 または IIS 7 (または IIS 7.5) で ASP.NET 4 アプリケーションが実行されているかどうかによって異なります。
手順 1 (IIS 7 または IIS 7.5 のみ)
この手順は、Windows Vista、Windows Server 2008、Windows 7、Windows Server 2008 R2 を含む IIS 7 または IIS 7.5 を実行するオペレーティング システムでのみ必要です。
親アプリケーション (ASP.NET 2.0 または ASP.NET 3.5 を実行するアプリケーション) の Web.config ファイル内の configSections 定義を、.NET Framework 2.0 のルートの Web.config ファイルに移動します。 IIS 7 および IIS 7.5 ネイティブ構成システムは、構成ファイルの階層をマージするときに configSections 要素をスキャンします。 configSections 定義を親 Web アプリケーションの Web.config ファイルからルート ファイル Web.config に移動すると、子 ASP.NET 4 アプリケーションで発生する構成マージ プロセスから要素が実質的に非表示になります。
32 ビット オペレーティング システムまたは 32 ビット アプリケーション プールの場合、ASP.NET 2.0 と ASP.NET 3.5 のルート ファイル Web.config は通常、次のフォルダーにあります。
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG
64 ビット オペレーティング システムまたは 64 ビット アプリケーション プールの場合、ASP.NET 2.0 と ASP.NET 3.5 のルート ファイル Web.config は通常、次のフォルダーにあります。
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG
64 ビット コンピューターで 32 ビットと 64 ビットの両方の Web アプリケーションを実行する場合は、configSections 要素を 32 ビット システムと 64 ビット システムの両方のルート ファイル Web.config に移動する必要があります。
configSections 要素をルート ファイル Web.config に配置する場合は、configuration 要素の直後にセクションを貼り付けます。 次の例は、要素の移動が完了したときのルート ファイル Web.config の先頭部分の外観を示しています。
Note
次の例では、読みやすくするために行がラップされています。
<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
<configSections>
<sectionGroup name="system.web.extensions"
type="System.Web.Configuration.SystemWebExtensionsSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting"
type="System.Web.Configuration.ScriptingSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="scriptResourceHandler"
type="System.Web.Configuration.ScriptingScriptResourceHandlerSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<sectionGroup name="webServices"
type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="jsonSerialization"
type="System.Web.Configuration.ScriptingJsonSerializationSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="Everywhere" />
<section name="profileService"
type="System.Web.Configuration.ScriptingProfileServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="authenticationService"
type="System.Web.Configuration.ScriptingAuthenticationServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="roleService"
type="System.Web.Configuration.ScriptingRoleServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
</configSections>
手順 2 (IIS のすべてのバージョン)
この手順は、ASP.NET 4 の子 Web アプリケーションが IIS 6 または IIS 7 (または IIS 7.5) で実行されているかどうかに関係なく必要です。
ASP.NET 2 または ASP.NET 3.5 を実行している親 Web アプリケーションの Web.config ファイルに、構成エントリが親 Web アプリケーションにのみ適用されることを明示的に指定する location タグ (IIS と ASP.NET 構成システムの両方) を追加します。 次の例は、追加する location 要素の構文を示しています。
<location path="" inheritInChildApplications="false" >
<!-- Additional settings -->
</location>
次の例は、appSettings セクションから始まり、system.webServer セクションで終わるすべての構成セクションをラップするために location タグを使用する方法を示しています。
<location path="" inheritInChildApplications="false" >
<appSettings />
<connectionStrings />
<system.web>
<!-- Removed for brevity -->
</system.web>
<system.codedom>
<!-- Removed for brevity -->
</system.codedom>
<system.webServer>
<!-- Removed for brevity -->
</system.webServer>
</location>
手順 1 と 2 を完了すると、ASP.NET 4 の子 Web アプリケーションがエラーなしで起動します。
SharePoint がインストールされているコンピューターで ASP.NET 4 Web サイトを起動できない
SharePoint を実行する Web サーバーには、SharePoint Web サイトのルートに展開される Web.config ファイルがあります (既定の Web サイト用の c:\inetpub\wwwroot\web.config など)。 この Web.config ファイルでは、SharePoint は WSS_Minimal という名前のカスタム部分信頼レベルを設定します。
この種類の SharePoint Web サイトの子として配置された ASP.NET 4 Web サイトを実行しようとすると、次のエラーが表示されます。
Could not find permission set named 'ASP.NET'.
このエラーは、ASP.NET 4 コード アクセス セキュリティ (CAS) インフラストラクチャが ASP.NET という名前のアクセス許可セットを探しているために発生します。 ただし、WSS_Minimal によって参照される部分信頼構成ファイルには、その名前の権限セットは含まれません。
現在、ASP.NET と互換性のある SharePoint のバージョンは使用できません。 このため、ASP.NET 4 Web サイトを、SharePoint Web サイトの下の子サイトとして実行しないでください。
HttpRequest.FilePath プロパティに PathInfo 値が含まれるようになりました
以前のバージョンの ASP.NET には、HttpRequest.FilePath、HttpRequest.AppRelativeCurrentExecutionFilePath、HttpRequest.CurrentExecutionFilePath など、さまざまなファイル パス関連のプロパティから返される値に PathInfo 値が含まれていました。 ASP.NET 4 では、これらのプロパティからの戻り値に PathInfo 値が含まれなくなりました。 代わりに、PathInfo 情報は HttpRequest.PathInfo で使用できます。 たとえば、次のような URL フラグメントがあるとします。
/testapp/Action.mvc/SomeAction
以前のバージョンの ASP.NET では、HttpRequest プロパティは次の値を持ちます。
HttpRequest.FilePath: /testapp/Action.mvc/SomeAction
HttpRequest.PathInfo: (空)
ASP.NET 4 では、HttpRequest プロパティは代わりに次の値を持ちます。
HttpRequest.FilePath: /testapp/Action.mvc
HttpRequest.PathInfo: SomeAction
ASP.NET 2.0 アプリケーションで eurl.axd を参照する HttpException エラーが生成される可能性がある
ASP.NET 4 を IIS 6 で有効にした後、(Windows Server 2003 または Windows Server 2003 R2 の) IIS 6 で実行された ASP.NET 2.0 アプリケーションで次のようなエラーが発生する可能性があります。
System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.
このエラーが発生するのは、ASP.NET が Web サイトが ASP.NET 4 を使用するように構成されていることを検出すると、ASP.NET 4 のネイティブ コンポーネントが、ASP.NET のマネージド部分に拡張なしの URL を渡して、さらに処理するためです。 ただし、ASP.NET 4 Web サイトの下にある仮想ディレクトリが ASP.NET 2.0 を使用するように構成されている場合、この方法で拡張なしの URL を処理すると、"eurl.axd" という文字列を含む URL が変更されます。 その後、この変更された URL は、ASP.NET 2.0 アプリケーションに送信されます。 ASP.NET 2.0 は "eurl.axd" 形式を認識できません。 したがって、ASP.NET 2.0 は eurl.axd という名前のファイルを検索して実行しようとします。 このようなファイルが存在しないため、要求は HttpException 例外で失敗します。
この問題は、次のいずれかの方法を使用して回避できます。
オプション 1
Web サイトの実行に ASP.NET 4 が必要ない場合は、サイトを再マップして ASP.NET 2.0 が代わりに使用されるようにします。
オプション 2
Web サイトの実行に ASP.NET 4 が必要な場合は、ASP.NET 2.0 の子仮想ディレクトリをすべて、ASP.NET 2.0 にマップされた別の Web サイトに移動させます。
オプション 3
Web サイトを ASP.NET 2.0 に再マップしたり、仮想ディレクトリの場所を変更したりするのが実用的でない場合は、ASP.NET 4 で拡張なしの URL 処理を明示的に無効にします。 次の手順に従います。
- Windows レジストリで、次のノードを開きます。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0
- EnableExtensionlessUrls という名前の新しい DWORD 値を作成します。
- EnableExtensionlessUrls を 0 に設定します。 これにより、拡張なしの URL の動作が無効になります。
- レジストリ値を保存し、レジストリ エディターを閉じます。
- iisreset コマンド ライン ツールを実行すると、IIS は新しいレジストリ値を読み取ります。
Note
EnableExtensionlessUrls を 1 に設定すると、拡張なしの URL 動作が有効になります。 これは、値が指定されていないときの既定の設定です。
IIS 7 または IIS 7.5 統合モードの既定のドキュメントでイベント ハンドラーが発生しない可能性がある
ASP.NET 4 には、拡張なしの URL が既定のドキュメントに解決されたときに HTML の form 要素の action 属性がどのようにレンダリングされるかを変更する更新が含まれています。 既定のドキュメントに解決する拡張なしの URL の例は http://contoso.com/ になり、その結果、http://contoso.com/Default.aspx への要求が発生します。
ASP.NET 4 では、既定のドキュメントがマップされている拡張子なしの URL に対して要求が行われた場合に、HTML form 要素の action 属性の値を空の文字列としてレンダリングするようになりました。 たとえば、以前のリリースの ASP.NET では、http://contoso.com に対して要求すると、Default.aspx に対する要求が生成されました。 そのドキュメントでは、form 開始タグが次の例のようにレンダリングされました。
<form action="Default.aspx" />
ASP.NET 4 では、http://contoso.com への要求も Default.aspx に対する要求になります。 ただし、ASP.NET では、次の例のように HTML 開始タグ form がレンダリングされるようになりました。
<form action="" />
action 属性のレンダリング方法のこの違いにより、IIS と ASP.NET によるフォーム投稿の処理方法が微妙に変化する可能性があります。 action 属性が空の文字列の場合、IIS の DefaultDocumentModule オブジェクトは、Default.aspx への子要求を作成します。 ほとんどの状況では、この子要求はアプリケーション コードに対して透過的であり、Default.aspx ページは正常に実行されます。
ただし、マネージド コードと IIS 7 または IIS 7.5 統合モードとの間のやり取りによって、マネージド .aspx ページが子要求中に正常に動作を停止することがあります。 次の状況が発生した場合、Default.aspx ドキュメントへの子要求は、エラーになるか予期しない動作をします。
- form 要素の action 属性が "" に設定されて .aspx ページがブラウザーに送信された場合。
- フォームが ASP.NET にポストバックされた場合。
- マネージド HTTP モジュールが、エンティティ本体の一部を読み取った場合。 たとえば、モジュールは Request.Form または Request.Params を読み取ります。 これにより、POST 要求のエンティティ本体がマネージド メモリに読み込まれます。 その結果、エンティティ本体は、IIS 7 または IIS 7.5 統合モードで実行されているネイティブ コード モジュールから使用できなくなります。
- IIS の DefaultDocumentModule オブジェクトが最終的に実行され、
Default.aspxドキュメントへの子要求を作成する場合。 ただし、エンティティ本体はマネージド コードの一部によって既に読み取られているため、子要求に対する送信に使用できるエンティティ本体はありません。 - HTTP パイプラインが子要求に対して実行されたときに、
.aspxファイルのハンドラーがハンドラー実行フェーズ中に実行された場合。 - エンティティ本体がないため、フォーム変数もビュー状態もないため、.aspx ページ ハンドラーで発生する予定のイベント (存在する場合) を判断するための情報はありません。 その結果、影響を受ける .aspx ページのポストバック イベント ハンドラーは実行されません。
この動作を回避するには、次の方法があります。
既定のドキュメント要求中に要求のエンティティ本文にアクセスしている HTTP モジュールを特定し、マネージド要求に対してのみ実行するように構成できるかどうかを判断します。 IIS 7 と IIS 7.5 の両方の統合モードでは、HTTP モジュールは、モジュールの system.webServer/modules エントリに次の属性を追加することで、マネージド要求に対してのみ実行するようにマークできます。
precondition="managedHandler"この設定では、IIS 7 および IIS 7.5 が管理要求でないと判断する要求のモジュールを無効にします。 既定のドキュメント要求の場合、最初の要求は拡張なしの URL に対するものになります。 したがって、IIS では、初期要求処理中にマネージド ハンドラーの前提条件でマークされたマネージド モジュールは実行されません。 その結果、マネージド モジュールは誤ってエンティティ本体を読み取らないので、エンティティ本体は引き続き使用でき、子要求と既定のドキュメントに渡されます。
問題のある HTTP モジュールをすべての要求に対して実行する必要がある場合 (静的ファイルの場合、DefaultDocumentModule オブジェクトに解決される拡張子のない URL、マネージド要求の場合など)、ページの System.Web.UI.HtmlControls.HtmlForm コントロールの Action プロパティを空でない文字列に明示的に設定して、影響を受ける .aspx ページを変更します。 たとえば、既定のドキュメントが
Default.aspxの場合は、ページのコードを変更して、HtmlForm コントロールの Action プロパティを "Default.aspx" に明示的に設定します。
ASP.NET コード アクセス セキュリティ (CAS) の実装に対する変更
ASP.NET 2.0、さらには 3.5 で追加された ASP.NET 機能は、.NET Framework 1.1 と .NET Framework 2.0 のコード アクセス セキュリティ (CAS) モデルを使用します。 ただし、ASP.NET 4 での CAS の実装は大幅に見直されました。 その結果、グローバル アセンブリ キャッシュ (GAC) で実行されている信頼されるコードに依存する、部分的に信頼された ASP.NET アプリケーションの実行は、さまざまなセキュリティ例外で失敗することがあります。 マシンの CAS ポリシーに対する広範な変更に依存する、部分的に信頼されたアプリケーションも、セキュリティ例外で失敗することもあります。
次の例に示すように、trust 構成要素の新しい legacyCasModel 属性を使用して、部分的に信頼された ASP.NET 4 アプリケーションを ASP.NET 1.1 および 2.0 の動作に戻すことができます。
<trust level= "Medium" legacyCasModel="true" />
レガシ CAS モデルに戻すと、次の以前の CAS 動作が有効になります。
- マシン CAS ポリシーが適用されます。
- 1 つのアプリケーション ドメインで複数の異なるアクセス許可セットを使用できます。
- ASP.NET またはその他の.NET Framework コードのみがスタック上にある場合にのみ呼び出される GAC 内のアセンブリには、明示的なアクセス許可アサーションは必要ありません。
.NET Framework 4 では 1 つのシナリオを元に戻すことができません。Web 以外の部分信頼アプリケーションは、System.Web.dll と System.Web.Extensions.dll の特定の API を呼び出すことができなくなります。 以前のバージョンの .NET Framework では、Web 以外の部分信頼アプリケーションに AspNetHostingPermission アクセス許可を明示的に付与する可能性があります。 これらのアプリケーションでは、System.Web.HttpUtility、System.Web.ClientServices.* 名前空間の型、およびメンバーシップ、ロール、プロファイルに関連する型を使用できます。 Web 以外の部分信頼アプリケーションからのこれらの型の呼び出しは、.NET Framework 4 ではサポートされなくなりました。
Note
System.Web.HttpUtility クラスの HtmlEncode と HtmlDecode 機能は、新しい .NET Framework 4 の System.Net.WebUtility クラスに移動されました。 それが使用されていた唯一の ASP.NET 機能である場合は、代わりに新しい WebUtility クラスを使用するようにアプリケーションのコードを変更します。
ASP.NET 4 の既定の CAS 実装に対する変更の概要を次に示します。
- ASP.NET アプリケーション ドメインは、同種のアプリケーション ドメインになりました。 アプリケーション ドメインでは、部分信頼と完全信頼の許可セットのみを使用できます。
- ASP.NET 部分信頼許可セットは、エンタープライズ レベル、コンピューター レベル、またはユーザー レベルの CAS ポリシーから独立しています。
- 3.5 および 3.5 SP1 に出荷された ASP.NET アセンブリは、.NET Framework 4 透過性モデルを使用するように変換されています。
- ASP.NET AspNetHostingPermission 属性の使用が大幅に削減されました。 この属性のインスタンスのほとんどは、パブリック ASP.NET API から削除されました。
- ASP.NET ビルド プロバイダーによって作成された動的にコンパイルされたアセンブリは、アセンブリを透過的として明示的にマークするように更新されました。
- すべての ASP.NET アセンブリは、APTCA 属性が Web ホスティング環境でのみ適用されるようにマークされるようになりました。 ClickOnce などの部分的に信頼された Web 以外のホスティング環境では、ASP.NET アセンブリを呼び出すことができなくなります。
新しい ASP.NET 4 コード アクセス セキュリティ モデルの詳細については、MSDN Web サイトの ASP.NET アプリケーションのコード アクセス セキュリティの使用に関するページをご覧ください。
System.Web.Security 名前空間の MembershipUser とその他の型が移動されました
ASP.NET メンバーシップで使用される一部の型は、System.Web.dll から新しい System.Web.ApplicationServices.dll アセンブリに移動されました。 これらのタイプは、クライアントのタイプと拡張 .NET Framework SKU のタイプとの間のアーキテクチャ層の依存関係を解決するために移動しました。
System.Web.ApplicationServices.dll は、ASP.NET コンパイル システムによって既定で使用される参照アセンブリの一覧に追加されているため、これらの型を移動しても、Web サイト プロジェクトには問題はありません。 以前のバージョンの ASP.NET を使用して作成された Web サイト プロジェクトを Visual Studio 2010 で開いて ASP.NET 4 にアップグレードすると、そのプロジェクトはエラーなしでコンパイルされます。
同様に、以前のバージョンの ASP.NET で作成された Web アプリケーション プロジェクトを Visual Studio 2010 で開いて ASP.NET 4 にアップグレードすると、アップグレード プロセスによってプロジェクトに System.Web.ApplicationServices.dll への参照が追加されます。 そのため、アップグレードされた Web アプリケーション プロジェクトもエラーなしでコンパイルされます。
以前のバージョンの ASP.NET を使用して作成されたコンパイル済み (バイナリ) ファイルも、メンバーシップの種類が別のアセンブリに移動された場合でも、ASP.NET 4 でエラーなしで実行されます。 型の転送情報が、ASP.NET 4 バージョンの System.Web.dll に追加されました。これにより、これらの型の実行時参照が型の新しい場所に自動的にルーティングされます。
しかし、特定のメンバーシップ タイプを使用する、以前のバージョンの ASP.NET からアップグレードされたクラス ライブラリを ASP.NET 4 プロジェクトで使用すると、コンパイルに失敗します。 たとえば、クラス ライブラリ プロジェクトがコンパイルに失敗し、次のようなエラーが報告されることがあります。
The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.
この問題を回避するには、クラス ライブラリ プロジェクトの参照をSystem.Web.ApplicationServices.dll に追加します。
次の一覧は、System.Web.dll から System.Web.ApplicationServices.dll に移動された System.Web.Security の種類を示しています。
- System.Web.Security.MembershipCreateStatus
- System.Web.Security.Membership.CreateUserException
- System.Web.Security.MembershipPasswordException
- System.Web.Security.MembershipPasswordFormat
- System.Web.Security.MembershipProvider
- System.Web.Security.MembershipProviderCollection
- System.Web.Security.MembershipUser
- System.Web.Security.MembershipUserCollection
- System.Web.Security.MembershipValidatePasswordEventHandler
- System.Web.Security.ValidatePasswordEventArgs
- System.Web.Security.RoleProvider
- System.Web.Configuration.MembershipPasswordCompatibilityMode
Vary * HTTP ヘッダーへの出力キャッシュの変更
ASP.NET 1.0 のバグが原因で、出力キャッシュの設定として Location="ServerAndClient" が指定されたキャッシュ ページでは、応答に Vary:* HTTP ヘッダーが生成されていました。 その結果、クライアント ブラウザーに対して、ローカルにページをキャッシュしないように指示がなされていました。
ASP.NET 1.1 では、System.Web.HttpCachePolicy.SetOmitVaryStar メソッドが追加されました。このメソッドを呼び出して Vary:* ヘッダーを抑制できます。 出力された HTTP ヘッダーの変更は、その時点で破壊的変更の可能性があると見なされていたため、このメソッドが選択されました。 しかし、開発者は ASP.NET での動作に混乱しており、バグ レポートでは、開発者が既存の SetOmitVaryStar の動作を認識されていないことが示唆されています。
ASP.NET 4 では、根本問題を修正することが決定されました。 次のディレクティブを指定する応答から Vary:* HTTP ヘッダーは生成されなくなりました。
<%@OutputCache Location="ServerAndClient" %>
そのため、Vary:* ヘッダーを無効にするための SetOmitVaryStar メソッドは不要になりました。
ページの @ OutputCache ディレクティブで Location="ServerAndClient" を指定するアプリケーションでは、Location 属性の値の名前によって暗黙的に示される動作が表示されます。つまり、SetOmitVaryStar メソッドを呼び出すことなく、ページはブラウザーでキャッシュ可能になります。
アプリケーション内のページで Vary:* を生成する必要がある場合は、次の例に示すように AppendHeader メソッドを呼び出します。
HttpResponse.AppendHeader("Vary","*");
または、出力キャッシュ Location 属性の値を "Server" に変更できます。
Passport の System.Web.Security の種類は廃止されました
Passport (現在の Live ID) の変更により、ASP.NET 2.0 に組み込まれた Passport のサポートは廃止され、数年間サポートされなくなりました。 その結果、System.Web.Security の Passport に関連する 5 つの種類が、ObsoleteAttribute 属性でマークされるようになりました。
MenuItem.PopOutImageUrl プロパティが ASP.NET 4 でイメージをレンダリングできない
ASP.NET 3.5 では、MenuItem.PopOutImageUrl プロパティを使用すると、メニュー項目に表示されるイメージの URL を指定して、メニュー項目に動的サブメニューがあることを示すことができます。 次の例は、ASP.NET 3.5 のマークアップでこのプロパティを指定する方法を示しています。
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
PopOutImageUrl="~/Images/Popout.gif"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
ASP.NET 4 でデザインが変更された結果、プロパティが MenuItem クラスに設定されている場合、PopOutImageUrl の出力はレンダリングされません。 代わりに、StaticPopOutImageUrl プロパティまたは DynamicPopOutImageUrl プロパティのいずれかを使用して、Menu コントロールでイメージ URL を直接指定する必要があります。 静的メニューを操作する場合、Menu.StaticPopOutImageUrl プロパティは、次の例に示すように、静的メニュー項目にサブメニューがあることを示すために表示されるイメージの URL を指定します。
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
動的メニューを操作している場合は、Menu.DynamicPopOutImageUrl プロパティを使用して、動的メニュー項目にサブメニューがあることを示すイメージの URL を指定します。 次の例は前の例と似ていますが、動的メニューの DynamicPopOutImageUrl プロパティを設定する方法を示しています。
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical"
target="_blank"
DynamicPopOutImageTextFormatString="More..."
DynamicPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
Menu.DynamicPopOutImageUrl プロパティが設定されておらず、Menu.DynamicEnableDefaultPopOutImage プロパティが false に設定されている場合、イメージは表示されません。 同様に、StaticPopOutImageUrl プロパティが設定されておらず、StaticEnableDefaultPopOutImage プロパティが false に設定されている場合、イメージは表示されません。
これらのプロパティのパスを設定する場合は、円記号 () ではなくスラッシュ (/) を使用します。 詳細については、このドキュメントの別の場所にある「Menu.StaticPopOutImageUrl と Menu.DynamicPopOutImageUrl は、パスに円記号が含まれている場合にイメージをレンダリングできない」を参照してください。
Menu.StaticPopOutImageUrl と Menu.DynamicPopOutImageUrl は、パスに円記号が含まれている場合にイメージをレンダリングできない
ASP.NET 4 では、パスに円記号 () が含まれている場合、Menu.StaticPopOutImageUrl プロパティと Menu.DynamicPopOutImageUrl プロパティを使用して指定したイメージはレンダリングされません。 これは、ASP.NET の以前のバージョンからの変更です。
次の Menu コントロール マークアップの例は、円記号を含むパスを使用して設定された StaticPopOutImageUrl プロパティを示しています。 ASP.NET 4 では、プロパティで指定されたイメージはレンダリングされません。
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images\Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
この問題を解決するには、StaticPopOutImageUrl プロパティと DynamicPopOutImageUrl プロパティで指定されているパス値を、スラッシュ (/) を使用するように変更します。 次の例は、この変更を示しています。
<asp:menu id="NavigationMenu"
staticdisplaylevels="1"
staticsubmenuindent="10"
orientation="Vertical
target="_blank"
StaticPopOutImageTextFormatString="More..."
StaticPopOutImageUrl="Images/Popout.gif"
runat="server">
<items>
<asp:menuitem navigateurl="default2.aspx"
text="Home"
tooltip="Home">
<asp:menuitem navigateurl="default3.aspx"
text="Movies"
tooltip="Movies">
</asp:menuitem>
</asp:menuitem>
</items>
</asp:menu>
MenuItem.PopOutImageUrl プロパティが変更されたため、以前のバージョンの ASP.NET から ASP.NET 4 に移行されたアプリケーションも影響を受ける可能性があることに注意してください。 詳細については、このドキュメントの別の場所にある「MenuItem.PopOutImageUrl プロパティが ASP.NET 4 でイメージをレンダリングできない」を参照してください。
免責情報
このドキュメントは暫定版であり、ここで説明するソフトウェアの最終的な商業リリースより前に大幅に変更される可能性があります。
このドキュメントに含まれる情報は、取り上げている問題についての、公開時点における Microsoft Corporation の見解を表します。 Microsoft は変化する市場状況に対応する必要があるため、これを Microsoft による確約と解釈しないでください。Microsoft は、記載されている情報の公開後の正確さを保証できません。
このホワイト ペーパーは、情報提供のみを目的としています。 明示、黙示または法律の規定にかかわらず、これらの情報について Microsoft はいかなる責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用をお願いします。 このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、検索システムに複製、格納、導入したり、その目的を問わず、いかなる形態や手段であっても、転送することは禁じられています。ここでいう手段とは、電子的、機械的、複写、録音など、すべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。
Microsoft は、このドキュメントに記載されている内容に関して、特許、特許申請、商標、著作権、またはその他の知的財産権を有する場合があります。 Microsoft による使用許諾契約書によって明示的に許可されている場合を除き、このドキュメントの提供によって、これらの特許権、商標、著作権、またはその他の知的財産権のライセンスが貴社に供与されることはありません。
別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものであり、実在する会社、組織、商品名、ドメイン名、メール アドレス、ロゴ、個人、場所、イベントなどとは一切関係ありません。
© 2010 Microsoft Corporation. All rights reserved.
Microsoft および Windows は、米国および他の国における Microsoft Corporation の登録商標または商標です。
本ドキュメントで説明する実際の製造元および製品名は、それぞれの所有者の商標である場合があります。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示