次の方法で共有

ASP.NET 4 重大な変更

このドキュメントでは、以前のリリースを使用して作成されたアプリケーション (ASP.NET 4 Beta 1 および Beta 2 リリースなど) に影響する可能性がある .NET Framework バージョン 4 リリースに対して行われた変更について説明します。

このホワイトペーパーをダウンロードする

内容

Web.config ファイルの ControlRenderingCompatibilityVersion 設定
ClientIDMode の変更
HtmlEncode と UrlEncode で単一引用符をエンコードするようになりました
ASP.NET ページ (.aspx) パーサーの厳格化
ブラウザー定義ファイルの更新
System.Web.Mobile.dll がルート Web 構成ファイルから削除されました
ASP.NET 要求の検証
既定のハッシュ アルゴリズムがHMACSHA256になりました
新しい ASP.NET 4 ルート構成に関連する構成エラー
ASP.NET 4 つの子アプリケーションが、ASP.NET 2.0 または ASP.NET 3.5 アプリケーションの場合に起動できない
ASP.NET 4 SharePoint がインストールされているコンピューターで 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 コントロールは、名前属性をレンダリングしません。
  • Table コントロールは、border="0"属性をレンダリングしなくなりました。
  • ユーザー入力用に設計されていないコントロール (Label コントロールなど) では、disabled="disabled" プロパティが false に設定されている場合 (またはコンテナー コントロールからこの設定を継承している場合) に、属性がレンダリングされなくなります。

ClientIDMode の変更

ASP.NET 4 の ClientIDMode 設定では、HTML 要素の id 属性 ASP.NET 生成する方法を指定できます。 以前のバージョンの ASP.NET では、既定の動作は ClientIDMode の AutoID 設定と同じでした。 ただし、既定の設定は [予測可能] になりました。

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"  />

閉じていない style 属性が CssClass 属性に続いていることに注目してください。

ブラウザー定義ファイルの更新

ブラウザー定義ファイルが更新され、新しいブラウザーと更新されたブラウザーとデバイスに関する情報が含まれています。 Netscape Navigator などの古いブラウザーやデバイスが削除され、Google Chrome や Apple iPhone などの新しいブラウザーとデバイスが追加されました。

削除されたブラウザー定義の 1 つを継承するカスタム ブラウザー定義がアプリケーションに含まれている場合は、エラーが表示されます。 たとえば、 App_Browsers フォルダーに IE2 ブラウザー定義を継承するブラウザー定義が含まれている場合、次の構成エラー メッセージが表示されます。

  • ID 'IE2' のブラウザーまたはゲートウェイ要素が見つかりません。

注

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 では、アセンブリ セクションのルート Web.config ファイルに、System.Web.Mobile.dll アセンブリ への参照が含まれていました。 パフォーマンスを向上させるために、このアセンブリへの参照は削除されました。

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 アルゴリズムが使用されていました。

ASP.NET 2.0 と ASP.NET 4 を組み合わせた環境で、フォーム認証クッキーなどのデータが異なる .NET Framework バージョン間で動作する必要がある場合、アプリケーションに影響を及ぼす可能性があります。 古いHMACSHA1 アルゴリズムを使用するように ASP.NET 4 Web アプリケーションを構成するには、 Web.config ファイルに次の設定を追加します。

<machineKey validation="SHA1" />

.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 3.5 アプリケーションの Web.config ファイルが自動的に変更され、ASP.NET 4 の適切な設定が含まれます。

ただし、再コンパイルなしで .NET Framework 4 を使用して ASP.NET 3.5 アプリケーションを実行することがサポートされているシナリオです。 その場合は、.NET Framework 4 および IIS 7 または IIS 7.5 でアプリケーションを実行する前に、アプリケーションの Web.config ファイルを手動で変更する必要がある場合があります。

次の 2 つのセクションでは、さまざまなソフトウェアの組み合わせに対して行う必要がある変更について説明します。

Windows Vista SP1 または Windows Server 2008 SP1。修正プログラムKB958854も SP2 もインストールされていません。 この構成では、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 ネイティブ構成システムは、マネージド構成セクション ハンドラーに対して定義されている 型 属性に対してテキスト比較を実行するため、構成エラーを返します。 Visual Studio 2008 および Visual Studio 2008 SP1 によって生成されるすべての Web.config ファイルは 、system.web.extensions (および関連する) 構成セクション ハンドラーの型文字列に "3.5" を持っているため、 また、ASP.NET 4 machine.config ファイルには同じ構成セクション ハンドラーの 型 属性に "4.0" が含まれているため、Visual Studio 2008 または Visual Studio 2008 SP1 で生成されたアプリケーションは、IIS 7 と IIS 7.5 で構成検証に常に失敗します。

これらの問題の解決

最初のシナリオの回避策は、Visual Studio 2008 によって自動的に生成されたWeb.config ファイルから定型構成テキストを含めることで、アプリケーション レベルのWeb.config ファイルを更新することです。

最初のシナリオの別の回避策として、Vista または Windows Server 2008 用 Service Pack 2 をコンピューターにインストールし、IIS 構成システムの不適切な構成マージ動作を修正します。 ただし、これらのアクションのいずれかを実行すると、2 番目のシナリオで説明されている問題が原因で、アプリケーションで構成エラーが発生する可能性があります。

2 番目のシナリオの回避策は、アプリケーション レベルの ファイルからすべての 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 アプリケーションを動作させるには、ASP.NET 4 アプリケーションが IIS 6 または IIS 7 (または IIS 7.5) で実行されているかどうかによって異なります。

手順 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 定義を、the.NET Framework 2.0 のルート Web.config ファイルに移動します。 IIS 7 および IIS 7.5 ネイティブ構成システムは、構成ファイルの階層をマージするときに 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 アプリケーションを実行する場合は、32 ビット システムと 64 ビット システムの両方のルート ファイルに Web.config 要素を移動する必要があります。

configSections 要素をルート Web.config ファイルに配置する場合は、構成要素の直後にセクションを貼り付けます。 次の例は、要素の移動が完了したときに、ルート Web.config ファイルの上部の部分の外観を示しています。

注

次の例では、読みやすくするために行がラップされています。

<?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 アプリケーションにのみ適用されることを明示的に指定する 場所 タグ (IIS と ASP.NET 構成システムの両方) を追加します。 次の例は、追加する location 要素の構文を示しています。

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

次の例は、appSettings セクションから始まり、system.webServer セクションで終わるすべての構成セクションをラップするために場所タグを使用する方法を示しています。

<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 アプリケーションがエラーなしで起動します。

ASP.NET 4 SharePoint がインストールされているコンピューターで 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 エラーが生成される可能性がある

IIS 6 で ASP.NET 4 が有効になった後、IIS 6 (Windows Server 2003 または Windows Server 2003 R2) で実行される 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 処理を明示的に無効にします。 次の手順に従います。

  1. Windows レジストリで、次のノードを開きます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. EnableExtensionlessUrls という名前の新しい DWORD 値を作成します。
  2. EnableExtensionlessUrls を 0 に設定します。 これにより、拡張機能のない URL の動作が無効になります。
  3. レジストリ値を保存し、レジストリ エディターを閉じます。
  4. iisreset コマンド ライン ツールを実行すると、IIS は新しいレジストリ値を読み取ります。

注

EnableExtensionlessUrls を 1 に設定すると、拡張なしの URL 動作が有効になります。 これは、値が指定されていない場合の既定の設定です。

IIS 7 または IIS 7.5 統合モードの既定のドキュメントでイベント ハンドラーがトリガーされない可能性がある

ASP.NET 4 には、拡張なしの URL が既定のドキュメントに解決されたときに HTML フォーム要素の action 属性をレンダリングする方法を変更する変更が含まれています。 拡張子のない URL が既定のドキュメントに解決される例は http://contoso.com/ であり、その結果として http://contoso.com/Default.aspx へのリクエストが発生します。

ASP.NET 4 では、既定のドキュメントがマップされている拡張なしの URL に対して要求が行われると、HTML フォーム 要素の アクション 属性値が空の文字列としてレンダリングされるようになりました。 たとえば、以前のリリースの ASP.NET では、 http://contoso.com 要求によって Default.aspx要求が発生します。 このドキュメントでは、次の例のように、開始 フォーム タグがレンダリングされます。

<form action="Default.aspx" />

ASP.NET 4 では、 http://contoso.com 要求も Default.aspx要求になります。 ただし、ASP.NET では、次の例のように HTML 開始 フォーム タグがレンダリングされるようになりました。

<form action="" />

アクション属性のレンダリング方法のこの違いにより、IIS と ASP.NET によるフォーム投稿の処理方法が微妙に変化する可能性があります。 アクション属性が空の文字列の場合、IIS DefaultDocumentModule オブジェクトはDefault.aspxする子要求を作成します。 ほとんどの場合、この子要求はアプリケーション コードに対して透過的であり、 Default.aspx ページは正常に実行されます。

ただし、マネージド コードと IIS 7 または IIS 7.5 統合モードの間で潜在的な相互作用が発生すると、子要求中にマネージド .aspx ページが正常に動作しなくなる可能性があります。 次の条件が発生した場合、 Default.aspx ドキュメントに対する子要求によってエラーまたは予期しない動作が発生します。

  1. フォーム要素の action 属性が "" に設定された状態で、.aspx ページがブラウザーに送信されます。
  2. フォームは ASP.NET にポストバックされます。
  3. マネージド HTTP モジュールは、エンティティ本体の一部を読み取ります。 たとえば、モジュールは Request.Form または Request.Params を読み取ります。 これにより、POST 要求のエンティティ本文がマネージド メモリに読み取られます。 その結果、エンティティ本体は、IIS 7 または IIS 7.5 統合モードで実行されているネイティブ コード モジュールでは使用できなくなります。
  4. IIS DefaultDocumentModule オブジェクトは最終的に実行され、 Default.aspx ドキュメントに対する子要求が作成されます。 ただし、エンティティボディはマネージドコードの一部によって既に読み取られたため、子要求に送信できるエンティティボディはありません。
  5. 子要求に対して HTTP パイプラインが実行されると、 .aspx ファイルのハンドラーは、ハンドラー実行フェーズ中に実行されます。
  6. エンティティ本体がないため、フォーム変数とビューステートがないため、.aspx ページ ハンドラーが発生する予定のイベント (存在する場合) を判断するための情報は使用できません。 その結果、影響を受けるページのポストバック イベント ハンドラー.aspx実行されません。

この動作は、次の方法で回避できます。

  • 既定のドキュメント要求中に要求のエンティティ本文にアクセスしている HTTP モジュールを特定し、管理された要求に対してのみ実行するように構成できるかどうかを判断します。 IIS 7 と IIS 7.5 の両方の統合モードでは、モジュールの system.webServer/modules エントリに次の属性を追加することで、HTTP モジュールをマネージド要求に対してのみ実行するようにマークできます。

  • precondition="managedHandler"

  • この設定により、IIS 7 および IIS 7.5 が管理要求でないと判断した要求のモジュールが無効になります。 既定のドキュメント要求の場合、最初の要求は拡張なしの URL です。 そのため、IIS では、初期要求処理中にマネージド ハンドラーの前提条件としてマークされたマネージド モジュールは実行されません。 その結果、マネージド モジュールはエンティティ本体を誤って読み取らないので、エンティティ本体は引き続き使用でき、子要求と既定のドキュメントに渡されます。

  • 問題のある HTTP モジュールをすべての要求に対して実行する必要がある場合 (静的ファイルの場合、DefaultDocumentModule オブジェクトに解決される拡張子のない URL、マネージド要求など)、影響を受ける.aspx ページを変更するには、ページの System.Web.UI.HtmlControls.HtmlForm コントロールの Action プロパティを空でない文字列に明示的に設定します。 たとえば、既定のドキュメントが Default.aspxされている場合は、 HtmlForm コントロールの Action プロパティを "Default.aspx" に明示的に設定するようにページのコードを変更します。

ASP.NET コード アクセス セキュリティ (CAS) の実装に対する変更

ASP.NET 2.0、および 3.5 で追加された ASP.NET 機能は、.NET Framework 1.1 および 2.0 コード アクセス セキュリティ (CAS) モデルを使用します。 しかし、ASP.NET 4 での CAS の実装は大幅に見直されました。 その結果、グローバル アセンブリ キャッシュ (GAC) で実行されている信頼されたコードに依存するアプリケーション ASP.NET 部分信頼は、さまざまなセキュリティ例外で失敗する可能性があります。 コンピューターの CAS ポリシーに対する広範な変更に依存する部分信頼アプリケーションも、セキュリティ例外で失敗する可能性があります。

次の例に示すように、新しい legacyCasModel 属性を trust 構成要素で使用することで、部分信頼 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 ではサポートされなくなりました。

注

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 でエラーなしで実行されます。 型転送情報は、これらの型の実行時参照を型の新しい場所に自動的にルーティングする System.Web.dll の ASP.NET 4 バージョンに追加されました。

ただし、特定のメンバーシップの種類を使用し、以前のバージョンの 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.ApplicationServices.dllに移動された System.Web.dll の種類を示しています。

  • 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:* は不要になります。

ページの Location="ServerAndClient" ディレクティブでを指定するアプリケーションでは、Location 属性の値の名前によって暗黙的に示される動作が表示されます。つまり、SetOmitVaryStar メソッドを呼び出すことなく、ブラウザーでページをキャッシュできます。

アプリケーション内のページで Vary:*を出力する必要がある場合は、次の例のように AppendHeader メソッドを呼び出します。

HttpResponse.AppendHeader("Vary","*");

または、出力キャッシュ の Location 属性の値を "Server" に変更することもできます。

Passport の System.Web.Security の種類は廃止されました

ASP.NET 2.0 に組み込まれている Passport のサポートは、Passport (現在の LiveID) の変更により、数年間は廃止され、サポートされていません。 その結果、 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 は、パスに円記号が含まれている場合にイメージをレンダリングできません 。

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 に移行されたアプリケーションも影響を受ける可能性があることに注意してください。 詳細については、「 The 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 の登録商標または商標です。

ここに記載されている実際の企業および製品の名前は、それぞれの所有者の商標である場合があります。

  • Last updated on