.NET Framework 4 への移行に関する問題

この記事では、.NET Framework バージョン 3.5 Service Pack 1 と .NET Framework バージョン 4 の間の移行の問題について説明します。これには、修正プログラム、標準のコンプライアンスとセキュリティの変更、お客様からのフィードバックに基づく変更が含まれます。これらの変更のほとんどは、アプリケーションでプログラミングを変更する必要はありません。変更を伴う可能性がある場合は、表の 「推奨される変更 」列を参照してください。注目すべき変更は、ASP.NET や Windows Presentation Foundation (WPF) などの領域ごとに分類されます。

この記事の問題の概要については、「 .NET Framework 4 への移行ガイド」を参照してください。

新機能の詳細については、「 .NET Framework 4 の新機能」を参照してください。

ASP.NET と Web

名前空間: System.Web、 System.Web.Mobile、 System.Web.Security、 System.Web.UI.WebControls

アセンブリ: System.Web (System.Web.dll内)

特徴	3.5 SP1 との違い	推奨される変更
ブラウザー定義ファイル	ブラウザー定義ファイルが更新され、新しいブラウザーと更新されたブラウザーとデバイスに関する情報が含まれています。 Netscape Navigator などの古いブラウザーやデバイスが削除され、Google Chrome や Apple iPhone などの新しいブラウザーとデバイスが追加されました。削除されたブラウザー定義の 1 つを継承するカスタムブラウザー定義がアプリケーションに含まれている場合は、エラーが表示されます。 HttpBrowserCapabilities オブジェクト (ページの `Request.Browse` プロパティによって公開されます) は、ブラウザー定義ファイルによって駆動されます。したがって、ASP.NET 4 でこのオブジェクトのプロパティにアクセスすることによって返される情報は、以前のバージョンの ASP.NET で返された情報とは異なる場合があります。	アプリケーションが古いブラウザー定義ファイルに依存している場合は、次のフォルダーからコピーできます。 Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers ASP.NET 4 の対応する \CONFIG\Browsers フォルダーにファイルをコピーします。ファイルをコピーした後、 Aspnet_regbrowsers.exe コマンドラインツールを実行します。詳細については、 https://www.asp.net/mobile Web サイトを参照してください。
混合バージョンの ASP.NET で実行されている子アプリケーション	ASP.NET 以前のバージョンの ASP.NET を実行するアプリケーションの子として構成されている 4 つのアプリケーションは、構成エラーまたはコンパイルエラーが原因で起動できない場合があります。発生する特定のエラーは、アプリケーションが IIS 6.0 で実行されているか、IIS 7 または IIS 7.5 で実行されているかによって異なります。	影響を受けるアプリケーションの構成ファイルを変更して、構成システムが ASP.NET 4 アプリケーションを正しく認識できるようにすることができます。 ASP.NET Webサイトのドキュメント「ASP.NET 4 の破壊的変更」の中の「ASP.NET 4 の子アプリケーションが、ASP.NET 2.0 アプリケーションまたは ASP.NET 3.5 アプリケーションのもとで起動に失敗する」の項を参照して、行う必要がある変更の詳細をご確認ください。
ClientID の変更	ASP.NET 4 の新しい `clientIDMode` 設定では、HTML 要素の `id` 属性 ASP.NET 生成する方法を指定できます。以前のバージョンの ASP.NET では、既定の動作は`AutoID`の`clientIDMode`設定と同じでした。既定の設定が `Predictable`になりました。詳細については、「 ASP.NET Web サーバーコントロールの識別」を参照してください。	Visual Studio を使用してアプリケーションを ASP.NET 2.0 または ASP.NET 3.5 からアップグレードする場合、ツールは、以前のバージョンの .NET Framework の動作を保持する設定を Web.config ファイルに自動的に追加します。ただし、IIS のアプリケーションプールを .NET Framework 4 をターゲットに変更してアプリケーションをアップグレードする場合、ASP.NET は既定で新しいモードを使用します。新しいクライアント ID モードを無効にするには、Web.config ファイルに次の設定を追加します。 `<pages clientIDMode="AutoID" />`
コードアクセスセキュリティ (CAS)	ASP.NET 3.5 で追加された ASP.NET 2.0 NET 機能では、.NET Framework 1.1 および .NET Framework 2.0 コードアクセスセキュリティ (CAS) モデルが使用されます。しかし、ASP.NET 4 での CAS の実装は大幅に見直されました。その結果、グローバルアセンブリキャッシュで実行されている信頼されたコードに依存するアプリケーション ASP.NET 部分信頼は、さまざまなセキュリティ例外で失敗する可能性があります。部分信頼アプリケーションは、コンピュータの CAS ポリシーに対する大幅な変更に依存することで、失敗してセキュリティ例外が発生する可能性があります。	次の例に示すように、`legacyCasModel`構成要素の新しい`trust`属性を使用して、部分信頼の ASP.NET 4 アプリケーションを ASP.NET 1.1 および 2.0 の動作に復元することができます。 `<trust level= "Medium" legacyCasModel="true" />` 重要: 古い CAS モデルに戻す場合は、セキュリティが低下する可能性があります。新しい ASP.NET 4 コードアクセスセキュリティモデルの詳細については、「 ASP.NET 4 アプリケーションのコードアクセスセキュリティ」を参照してください。
構成ファイル	.NET Framework および 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 のプロジェクトアップグレードツールを使用して、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 ファイルを手動で変更する必要がある場合があります。行う必要がある具体的な変更は、Service Pack (SP) リリースなど、使用しているソフトウェアの組み合わせによって異なります。この変更の影響を受ける可能性のあるソフトウェアの組み合わせと、特定の組み合わせに関する問題を解決する方法については、ASP.NET Web サイトのドキュメント「ASP.NET 4 重大な変更」の「新しい ASP.NET 4 ルート構成に関連する構成エラー」セクションを参照してください。
レンダリングを制御する	以前のバージョンの ASP.NET では、一部のコントロールでマークアップが出力され、無効にできませんでした。既定では、この種類のマークアップは ASP.NET 4 では生成されなくなります。レンダリングの変更は、次のコントロールに影響します。 * `Image` コントロールと `ImageButton` コントロールは、 `border="0"` 属性をレンダリングしなくなりました。 * `BaseValidator` クラスとそこから派生した検証コントロールでは、既定で赤いテキストがレンダリングされなくなります。 * `HtmlForm` コントロールは、 `name` 属性をレンダリングしません。 * `Table` コントロールは、 `border="0"` 属性をレンダリングしなくなりました。ユーザー入力用に設計されていないコントロール (`Label` コントロールなど) では、`disabled="disabled"` プロパティが`Enabled`に設定されている場合 (またはコンテナーコントロールからこの設定を継承する場合) に、`false`属性がレンダリングされなくなります。	Visual Studio を使用してアプリケーションを ASP.NET 2.0 または ASP.NET 3.5 からアップグレードする場合、ツールは、レガシレンダリングを保持する Web.config ファイルに設定を自動的に追加します。ただし、IIS のアプリケーションプールを .NET Framework 4 をターゲットに変更してアプリケーションをアップグレードする場合、ASP.NET は既定で新しいレンダリングモードを使用します。新しいレンダリングモードを無効にするには、Web.config ファイルに次の設定を追加します。 `<pages controlRenderingCompatibilityVersion="3.5" />`
既定のドキュメントのイベントハンドラー	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 `DefaultDocumentModule` オブジェクトは、Default.aspxする子要求を作成します。ほとんどの場合、この子要求はアプリケーションコードに対して透過的であり、Default.aspx ページは正常に実行されます。ただし、マネージドコードと IIS 7 または IIS 7.5 統合モードの間で潜在的な相互作用が発生すると、子要求中にマネージド .aspx ページが正常に動作しなくなる可能性があります。次の条件が発生した場合、既定の.aspx ドキュメントに対する子要求は、エラーまたは予期しない動作になります。 * .aspxページは、 `form` 要素の `action` 属性が "" に設定された状態でブラウザーに送信されます。フォームは ASP.NET にポストバックされます。マネージド HTTP モジュールは、エンティティ本体の一部 ( `Request.Form` や `Request.Params`など) を読み取ります。これにより、POST 要求のエンティティ本文がマネージドメモリに読み取られます。その結果、エンティティ本体は、IIS 7 または IIS 7.5 統合モードで実行されているネイティブコードモジュールでは使用できなくなります。 * IIS `DefaultDocumentModule` オブジェクトは最終的に実行され、Default.aspx ドキュメントへの子要求が作成されます。ただし、エンティティボディはマネージドコードの一部によって既に読み取られたため、子要求に送信できるエンティティボディはありません。 * 子要求に対して HTTP パイプラインを実行すると、.aspx ファイルのハンドラーはハンドラー実行フェーズ中に実行されます。エンティティ本体がないため、フォーム変数もビューステートもありません。そのため、.aspx ページハンドラーには、どのイベント（存在する場合）を発生させるべきかを判断するための情報がありません。その結果、影響を受けるページのポストバックイベントハンドラー.aspx実行されません。	この変更によって発生する可能性がある問題を回避する方法については、ASP.NET Web サイトの ASP.NET 4 の変更点ドキュメント内の「IIS 7 または IIS 7.5 統合モードで既定のドキュメントにイベントハンドラーが発生しない可能性がある」を参照してください。
ハッシュアルゴリズム	ASP.NET では、暗号化アルゴリズムとハッシュアルゴリズムの両方を使用して、フォーム認証 Cookie やビューステートなどのデータをセキュリティで保護します。既定では、ASP.NET 4 では、cookie とビューステートに対するハッシュ操作に HMACSHA256 アルゴリズムが使用されます。以前のバージョンの ASP.NET では、以前の HMACSHA1 アルゴリズムが使用されていました。	フォーム認証 Cookie などのデータが .NET Framework バージョン間で動作する必要がある ASP.NET 2.0 と ASP.NET 4 を混在させるアプリケーションを実行する場合は、Web.config ファイルに次の設定を追加して、古い HMACSHA1 アルゴリズムを使用するように ASP.NET 4 Web アプリケーションを構成します。 `<machineKey validation="SHA1" />`
Internet Explorer でのコントロールのホスティング	Web 上でコントロールをホストするためのより優れたソリューションがあるため、Internet Explorer で Windows フォームコントロールをホストできなくなりました。そのため、IEHost.dll アセンブリと IEExec.exe アセンブリは .NET Framework から削除されています。	Web アプリケーションでのカスタムコントロール開発には、次のテクノロジを使用できます。 * Silverlight アプリケーションを作成し、ブラウザーの外部で実行するように構成できます。詳細については、「ブラウザー外のサポート」を参照してください。 * XAML ブラウザーアプリケーション (XBAP) を構築して、WPF 機能を利用できます (クライアントコンピューター上の .NET Framework が必要)。詳細については、「 WPF XAML ブラウザーアプリケーションの概要」を参照してください。
HtmlEncode メソッドと UrlEncode メソッド	`HtmlEncode` クラスと`UrlEncode` クラスのHttpUtilityメソッドとHttpServerUtility メソッドが更新され、単一引用符文字 (') が次のようにエンコードされました。 * `HtmlEncode` メソッドは、単一引用符のインスタンスを次のようにエンコードします。 `'` * `UrlEncode` メソッドは、単一引用符のインスタンスを次のようにエンコードします。 `%27`	`HtmlEncode`メソッドと`UrlEncode`メソッドを使用する場所をコードで確認し、エンコードの変更によってアプリケーションに影響する変更が生じないことを確認します。
ASP.NET 2.0 アプリケーションでの 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.`	* Web サイトを実行するために ASP.NET 4 が必要ない場合は、代わりに ASP.NET 2.0 を使用するようにサイトを再マップします。 -又は- * Web サイトを実行するために ASP.NET 4 が必要な場合は、子 ASP.NET 2.0 仮想ディレクトリを、ASP.NET 2.0 にマップされている別の Web サイトに移動します。 -又は- * 拡張子のない URL を無効にします。詳細については、「ASP.NET 2.0 アプリケーションで eurl.axd を参照する HttpException エラーが生成される可能性がある」ASP.NET 4 ASP.NET Web サイトの破壊的変更に関するドキュメントを参照してください。
メンバーシップの種類	ASP.NET メンバーシップで使用される一部の型 (MembershipProvider など) は、System.Web.dll アセンブリから System.Web.ApplicationServices.dll アセンブリに移動しました。型は、クライアント内の型と拡張 .NET Framework SKU の型間のアーキテクチャの階層化の依存関係を解決するために移動されました。	以前のバージョンの ASP.NET からアップグレードされ、移動されたメンバーシップの種類を使用するクラスライブラリは、ASP.NET 4 プロジェクトで使用するとコンパイルに失敗する可能性があります。その場合は、クラスライブラリプロジェクトの参照を System.Web.ApplicationServices.dllに追加します。
メニューコントロールの変更	Menu コントロールを変更すると、次の動作が発生します。 * MenuRenderingMode が `List`に設定されている場合、または MenuRenderingMode が `Default` に設定され、 ControlRenderingCompatibilityVersion が `4.0` 以降に設定されている場合、 PopOutImageUrl プロパティは無効です。 * StaticPopOutImageUrl プロパティおよび DynamicPopOutImageUrl プロパティで設定されたパスに円記号 (\) が含まれている場合、イメージはレンダリングされません。 (以前のバージョンの ASP.NET では、パスに円記号を含めることができます)。	* 個々のメニュー項目のPopOutImageUrlプロパティを設定する代わりに、親StaticPopOutImageUrl コントロールのDynamicPopOutImageUrlまたはMenuを設定します。 -又は- MenuRenderingModeを`Table`に設定するか、MenuRenderingModeを`Default`に設定し、ControlRenderingCompatibilityVersionを`3.5`に設定します。これらの設定により、 Menu コントロールは、以前のバージョンの ASP.NET で使用した HTML テーブルベースのレイアウトを使用します。 * StaticPopOutImageUrl または DynamicPopOutImageUrl プロパティのパスに円記号 (\) が含まれている場合は、スラッシュ (/) に置き換える必要があります。
Web.config ファイル内のモバイルアセンブリ	以前のバージョンの ASP.NET では、`assembliessystem.web`/の`compilation` セクションのルート Web.config ファイルに、System.Web.Mobile.dll アセンブリへの参照が含まれていました。パフォーマンスを向上させるために、このアセンブリへの参照が削除されました。注: System.Web.Mobile.dll アセンブリと ASP.NET モバイルコントロールは、ASP.NET 4 に含まれていますが、非推奨です。	このアセンブリの型を使用する場合は、ルート Web.config ファイルまたはアプリケーション Web.config ファイルでアセンブリへの参照を追加します。
出力キャッシュ	ASP.NET 1.0 では、キャッシュ設定として `Location="ServerAndClient"` を指定した際のバグにより、キャッシュされたページの応答に `Vary:` HTTP ヘッダーが出力されました。これは、ページをローカルにキャッシュしないようクライアントブラウザーに指示する効果がありました。 ASP.NET 1.1 では、 SetOmitVaryStar メソッドが追加されました。これは、 `Vary:` ヘッダーを抑制するために呼び出される可能性があります。ただし、バグレポートは、開発者が既存の `SetOmitVaryStar` 動作を認識されていないことを示唆しています。 ASP.NET 4 では、 `Vary:` HTTP ヘッダーは、次のディレクティブを指定する応答から出力されなくなります。 `<%@ OutputCache Location="ServerAndClient" %>` その結果、SetOmitVaryStar ヘッダーを抑制するために、`Vary:` メソッドは不要になります。 `Location`属性に "ServerAndClient" を指定するアプリケーションでは、SetOmitVaryStarを呼び出す必要なく、ページがブラウザーでキャッシュ可能になります。	アプリケーション内のページで `Vary:`を出力する必要がある場合は、次の例に示すように AppendHeader メソッドを呼び出します。 `System.Web.HttpResponse.AppendHeader("Vary","");` または、出力キャッシュ `Location` 属性の値を "Server" に変更することもできます。
ページ解析	ASP.NET Web ページ (.aspx ファイル) とユーザーコントロール (.ascx ファイル) のページパーサーは、ASP.NET 4 では以前のバージョンの ASP.NET よりも厳密であり、以前のバージョンよりも多くのマークアップに無効としてフラグを設定します。	ページの実行時に生成されるエラーメッセージを調べて、無効なマークアップの結果として発生するエラーを修正します。
パスポートの種類	ASP.NET 2.0 に組み込まれている Passport のサポートは廃止されており、Passport (現在の Live ID SDK) の変更によりサポートされていません。その結果、 System.Web.Security の Passport に関連する型は、 `ObsoleteAttribute` 属性でマークされるようになりました。	System.Web.Security名前空間 (PassportIdentity など) で Passport 型を使用するコードを、Windows Live ID SDK を使用するように変更します。
FilePath プロパティの PathInfo 情報	ASP.NET 4 では、`PathInfo`、FilePath、AppRelativeCurrentExecutionFilePathなどのプロパティからの戻り値にCurrentExecutionFilePath値が含まれなくなりました。代わりに、 `PathInfo` 情報は PathInfoで使用できます。たとえば、次の URL フラグメントを想像してみてください。 `/testapp/Action.mvc/SomeAction` 以前のバージョンの ASP.NET では、 HttpRequest プロパティの値は次のとおりです。 * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (空) ASP.NET 4 では、 HttpRequest プロパティの値は次のようになります。 * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	HttpRequest クラスのプロパティに依存してパス情報を返す場所をコードで調べます。パス情報の返し方の変更を反映するようにコードを変更します。
要求の検証	要求の検証を改善するために、要求のライフサイクルの早い段階で ASP.NET 要求の検証が呼び出されます。その結果、Web サービス呼び出しやカスタムハンドラーなど、.aspx ファイル用ではない要求に対して要求検証が実行されます。要求の検証は、カスタム HTTP モジュールが要求処理パイプラインで実行されている場合にもアクティブになります。この変更の結果、.aspx ファイル以外のリソースに対する要求では、要求検証エラーが発生する可能性があります。要求パイプラインで実行されるカスタムコード (カスタム HTTP モジュールなど) も、要求検証エラーをスローする可能性があります。	必要に応じて、Web 構成ファイルの次の設定を使用して、.aspx ページのみが要求検証をトリガーする古い動作に戻すことができます。 `<httpRuntime requestValidationMode="2.0" />` 警告: 以前の動作に戻す場合は、既存のハンドラー、モジュール、およびその他のカスタムコード内のすべてのコードが、XSS 攻撃ベクトルである可能性がある安全でない可能性がある HTTP 入力のチェックを実行していることを確認します。
ルーティング	Visual Studio 2010 でファイルシステム Web サイトを作成し、Web サイトがフォルダー名にドット (.) を含むフォルダー内にある場合、URL ルーティングは確実に機能しません。一部の仮想パスから HTTP 404 エラーが返されます。これは、Visual Studio 2010 がルート仮想ディレクトリの正しくないパスを使用して Visual Studio 開発サーバーを起動するためです。	* ファイルベースの Web サイトの [プロパティ] ページで、 `Virtual Path` 属性を "/" に変更します。 -又は- * Web サイトプロジェクトの代わりに Web アプリケーションプロジェクトを作成します。 Web アプリケーションプロジェクトにはこの問題はありません。URL ルーティングは、プロジェクトフォルダーの名前にドットが含まれている場合でも機能します。 -又は- * IIS でホストされている HTTP ベースの Web サイトを作成します。 IIS でホストされる Web サイトは、仮想パスとプロジェクトファイルフォルダーにドットを含めることができます。
SharePoint サイト	`WSS_Minimal`という名前のカスタム部分信頼レベルを含む SharePoint Web サイトの子として展開されている ASP.NET 4 Web サイトを実行しようとすると、次のエラーが表示されます。 `Could not find permission set named 'ASP.Net'.`	現在、ASP.NET と互換性のあるバージョンの SharePoint はありません。その結果、ASP.NET 4 Web サイトを SharePoint Web サイトの子として実行しないでください。
XHTML 1.1 標準	新しい Web サイトに対して XHTML 1.1 コンプライアンスを有効にするために、.NET Framework 4 の ASP.NET コントロールによって XHTML 1.1 準拠の HTML が生成されます。このレンダリングは、 `<system.Web>` 要素内の Web.config ファイルで次のオプションを使用して有効になります。 `<pages controlRenderingCompatibilityVersion="4.0"/>` このオプションは、既定で 4.0 に設定されています。 Visual Studio 2008 からアップグレードされた Web プロジェクトでは、互換性のために 3.5 設定が有効になっています。	なし。

コア