次の方法で共有

.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 Child Applications Fail to Start When ASP.NET 2.0 or ASP.NET 3.5 Applications」(ASP.NET Web サイトの 「ASP.NET 4 の破壊的変更 」を参照してください。
ClientID の変更 ASP.NET 4 の新しい clientIDMode 設定では、HTML 要素の id 属性 ASP.NET 生成する方法を指定できます。 以前のバージョンの ASP.NET では、既定の動作はclientIDModeのAutoID設定と同じでした。 既定の設定が 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 ポリシーに対する広範な変更に依存する部分信頼アプリケーションも失敗し、セキュリティ例外がスローされる可能性があります。 次の例に示すように、trust構成要素の新しいlegacyCasModel属性を使用して、4 つのアプリケーション ASP.NET 部分信頼を 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 コントロールなど) では、Enabled プロパティがfalseに設定されている場合 (またはコンテナー コントロールからこの設定を継承する場合) に、disabled="disabled"属性がレンダリングされなくなります。		 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 サイトの「4 重大な変更」の ASP.NET ドキュメントの「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 メソッド HttpUtility クラスとHttpServerUtility クラスのHtmlEncodeメソッドとUrlEncode メソッドが更新され、単一引用符文字 (') が次のようにエンコードされました。

* HtmlEncode メソッドは、単一引用符のインスタンスを次のようにエンコードします。 &#39;
* 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 サイトの 破壊的変更 に関するドキュメントを参照してください。
メンバーシップの種類 メンバーシップで使用される一部の型 ( MembershipProviderなど) は、System.Web.dll から System.Web.ApplicationServices.dll アセンブリに移動 ASP.NET。 型は、クライアント内の型と拡張 .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プロパティを設定する代わりに、親Menu コントロールのStaticPopOutImageUrlまたはDynamicPopOutImageUrlを設定します。

-又は-

MenuRenderingModeをTableに設定するか、MenuRenderingModeをDefaultに設定し、ControlRenderingCompatibilityVersionを3.5に設定します。 これらの設定により、 Menu コントロールは、以前のバージョンの ASP.NET で使用した HTML テーブル ベースのレイアウトを使用します。
* StaticPopOutImageUrl または DynamicPopOutImageUrl プロパティのパスに円記号 (\) が含まれている場合は、スラッシュ (/) に置き換える必要があります。
Web.config ファイル内のモバイル アセンブリ 以前のバージョンの ASP.NET では、system.web/compilationのassemblies セクションのルート 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" %>

その結果、Vary:* ヘッダーを抑制するために、SetOmitVaryStar メソッドは不要になります。 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 では、FilePath、AppRelativeCurrentExecutionFilePath、CurrentExecutionFilePathなどのプロパティからの戻り値にPathInfo値が含まれるようになりました。 代わりに、 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 サイトの [プロパティ ] ページで、 仮想パス 属性を "/" に変更します。

-又は-

* 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 設定が有効になっています。		 なし。

コア

一般的な機能

特徴 3.5 SP1 との違い 推奨される変更
CardSpace Windows CardSpace は .NET Framework に含まれません。これは個別に提供されます。 Microsoft ダウンロード センターから Windows CardSpace を ダウンロードします。
構成ファイル .NET Framework がアプリケーション構成ファイルにアクセスする方法が修正されました。 アプリケーション構成ファイルの名前が application-name.configの場合は、名前を application-name.exe.configに変更します。たとえば、 MyApp.config の名前をMyApp.exe.configに変更 します 。
C# コード コンパイラ Microsoft.CSharp名前空間にあったCompiler、CompilerError、およびErrorLevelクラスは使用できなくなり、そのアセンブリ (cscompmgd.dll) は .NET Framework に含まれません。 System.CodeDom.Compiler名前空間で、CodeDomProvider クラスとその他のクラスを使用します。 詳細については、「 CodeDOM の使用」を参照してください。
ホスティング (アンマネージド API) ホスティング機能を向上させるために、ホスティング アクティブ化 API の一部が非推奨になりました。 インプロセスの side-by-side 実行機能を使用すると、アプリケーションは同じプロセスで複数のバージョンの .NET Framework を読み込んで起動できます。 たとえば、.NET Framework 2.0 SP1 に基づくアドイン (またはコンポーネント) を読み込むアプリケーションと、.NET Framework 4 に基づくアドインを同じプロセスで実行できます。 古いコンポーネントでは引き続き以前の .NET Framework バージョンが使用され、新しいコンポーネントでは新しい .NET Framework バージョンが使用されます。 サイド バイ サイド実行のIn-Process で説明されている構成を使用します。
新しいセキュリティ モデル コード アクセス セキュリティ (CAS) ポリシーは、 .NET Framework 4 のセキュリティの変更に関する記事で説明されているように、オフにされ、簡略化されたモデルに置き換えられました。 アプリケーションで CAS に依存している場合は、変更が必要になる場合があります。 詳細については、「 コード アクセス セキュリティ ポリシーの互換性と移行」を参照してください。

日付と時刻

Namespace： System

アセンブリ: mscorlib (mscorlib.dll内)

特徴 3.5 SP1 との違い 推奨される変更
夏時間 システム クロックと一貫性を保つには、時間プロパティ ( Local や Nowなど) で、夏時間操作に他の .NET Framework データの代わりにオペレーティング システム ルールが使用されるようになりました。 なし。
文字列の書式設定 カルチャに依存する書式設定をサポートするために、TimeSpan構造体には、新しいParseExactメソッドとTryParseExactメソッドに加えて、ToString、Parse、およびTryParseメソッドの新しいオーバーロードが含まれています。 なし。

グローバリゼーション

新しいニュートラルカルチャと特定のカルチャの一覧については、「 グローバリゼーションとローカリゼーションの新機能」を参照してください。

Namespace： System.Globalization

アセンブリ: mscorlib (mscorlib.dll内)

特徴 3.5 SP1 との違い 推奨される変更
カルチャ名 次の名前の変更は、ドイツ、ディベヒ、アフリカの文化に影響します。

* CurrencyEnglishName: ドイツ語 (スイス) (de-CH) カルチャの通貨名が "sFr" から "Fr" に変更されました。
* LongDatePattern: Divehi (モルディブ) (dv-MV) カルチャの長い日付パターンが "dd/MMMM/yyyy" から "dd/MM/yyyy" に変更されました。
* PMDesignator:アフリカーンス(南アフリカ)(af-ZA)文化のPM指定者が「nm」から「PM」に変更されました。		 カルチャ名の変更に注意してください。
LCID パラメーター オートメーション サーバー設定での予期される動作と一貫性を保つため、CLR は、 LCID パラメーターの現在のカルチャをアンマネージ COM ベースのアプリケーションに渡さなくなりました。 代わりに、カルチャに対して 1033 (en-us) を渡します。 指定したカルチャを必要とするネイティブ アプリケーションを除き、変更は必要ありません。
古いカルチャの種類 CultureTypesとCultureTypesカルチャの種類は、現在は使用されていません。

下位互換性のために、 CultureTypes は以前の .NET Framework に含まれていたニュートラルカルチャと特定のカルチャを返し、 CultureTypes は空のリストを返すようになりました。		 CultureTypes列挙体の他の値を使用します。
カルチャの取得 Windows 7 以降、.NET Framework 4 では、データ自体を格納するのではなく、オペレーティング システムからカルチャ情報を取得します。 さらに、.NET Framework は、データの並べ替えと大文字と小文字の区別のために Windows と同期します。 なし。
Unicode 5.1 標準 .NET Framework では、すべての Unicode 5.1 文字 (約 1,400 文字を追加) がサポートされるようになりました。 その他の文字には、新しい記号、矢印、分音記号、句読点、数学記号、CJK ストロークとイデグラフ、追加のマラヤーラム文字とテルグ語の数字、およびミャンマー、ラテン、アラビア語、ギリシャ語、モンゴル語、キリル文字が含まれます。 次の新しいスクリプトは、Unicode 5.1 でサポートされています。Sundanese、Lepcha、Ol Chiki、Vai、Saurashtra、Kayah Li、Rejang、Gurmukhi、Odia、Tamil、Telugu、Malayalam の文字とチャム。 なし。

例外

名前空間: System、 System.Runtime.ExceptionServices

アセンブリ: mscorlib (mscorlib.dll内)

特徴 3.5 SP1 との違い 推奨される変更
破損したプロセス状態の例外 CLR は、破損したプロセス状態の例外をマネージド コードの例外ハンドラーに配信しなくなりました。 これらの例外は、プロセスの状態が破損していることを示します。 この状態でアプリケーションを実行することはお勧めしません。

詳細については、MSDN マガジンの「 HandleProcessCorruptedStateExceptionsAttribute 」と「 破損状態例外の処理 」のエントリを参照してください。
実行エンジンの例外 ExecutionEngineException は、キャッチ可能な例外によって不安定なプロセスを引き続き実行できるため、現在は廃止されています。 この変更により、実行時の予測可能性と信頼性が向上します。 InvalidOperationExceptionを使用して条件を通知します。

リフレクション

Namespace： System.Reflection

アセンブリ: mscorlib (mscorlib.dll内)

特徴 3.5 SP1 との違い 推奨される変更
アセンブリ ハッシュ アルゴリズム アセンブリが読み込まれていない場合、ランタイムは参照アセンブリのハッシュ アルゴリズムを認識しないため、 HashAlgorithm プロパティは AssemblyHashAlgorithmを返すようになりました。 (これは、 GetReferencedAssemblies メソッドによって返されるなど、参照されるアセンブリでプロパティを使用することを指します)。 なし。
アセンブリの読み込み アセンブリの冗長な読み込みを防ぎ、仮想アドレス空間を節約するために、CLR は Win32 MapViewOfFile 関数のみを使用してアセンブリを読み込むようになりました。 LoadLibrary関数も呼び出しなくなりました。

この変更は、次の方法で診断アプリケーションに影響します。

* ProcessModuleCollection には、 Process.GetCurrentProcess().Modulesの呼び出しから取得したクラス ライブラリ (.dll ファイル) のモジュールは含めなくなります。
* EnumProcessModules 関数を使用する Win32 アプリケーションには、一覧にすべてのマネージド モジュールが表示されません。		 なし。
型の宣言 DeclaringTypeプロパティは、型に宣言型がない場合に null を正しく返すようになりました。 なし。
代表者 デリゲートのコンストラクターに null 値が渡されたときに、デリゲートがNullReferenceExceptionの代わりにArgumentNullExceptionをスローするようになりました。 例外処理が ArgumentNullExceptionをキャッチしていることを確認します。
グローバル アセンブリ キャッシュの場所の変更 .NET Framework 4 アセンブリの場合、グローバル アセンブリ キャッシュは Windows ディレクトリ (%WINDIR%) から Microsoft.Net サブディレクトリ (%WINDIR%\Microsoft.Net) に移動されました。 以前のバージョンのアセンブリは、古いディレクトリに残ります。

アンマネージ ASM_CACHE_FLAGS 列挙には、新しい ASM_CACHE_ROOT_EX フラグが含まれています。 このフラグは、 GetCachePath 関数によって取得できる .NET Framework 4 アセンブリのキャッシュ場所を取得します。		 アプリケーションがアセンブリへの明示的なパスを使用していないと仮定すると、これは推奨される方法ではありません。
グローバル アセンブリ キャッシュ ツール Gacutil.exe (グローバル アセンブリ キャッシュ ツール) は、シェル プラグイン ビューアーをサポートしなくなりました。 なし。

相互運用性

Namespace： System.Runtime.InteropServices

アセンブリ: mscorlib (mscorlib.dll内)

特徴 3.5 SP1 との違い 推奨される変更
バッファーの長さ (アンマネージ API) メモリを節約するために、ICorProfilerInfo2::GetStringLayout メソッドの pBufferLengthOffset パラメーターの機能が、pStringLengthOffset パラメーターと一致するように変更されました。 両方のパラメーターが文字列の長さのオフセット位置を指すようになりました。 バッファーの長さが文字列クラスの表現から削除されました。 バッファーの長さに対する依存関係を削除します。
JIT デバッグ Just-In-Time (JIT) デバッグの登録を簡略化するために、.NET Framework デバッガーでは、ネイティブ コードの JIT デバッグ動作を制御する AeDebug レジストリ キーのみが使用されるようになりました。 この変更の結果、次のようになります。

* マネージド コードとネイティブ コードに対して 2 つの異なるデバッガーを登録できなくなりました。
* 非対話型プロセスに対してデバッガーを自動的に起動することはできなくなりましたが、ユーザーに対話型プロセスを求めることもできます。
* デバッガーの起動に失敗したとき、または起動する必要がある登録済みのデバッガーがない場合は、通知されなくなります。
* アプリケーションの対話機能に依存する自動起動ポリシーはサポートされなくなりました。		 必要に応じてデバッグ操作を調整します。
プラットフォーム呼び出し アンマネージ コードとの相互運用性のパフォーマンスを向上させるために、プラットフォーム呼び出しの呼び出し規則が正しくないと、アプリケーションが失敗するようになりました。 以前のバージョンでは、マーシャリング レイヤーによってこれらのエラーがスタック上で解決されました。 Microsoft Visual Studio でアプリケーションをデバッグすると、これらのエラーを修正できるように警告が表示されます。

更新できないバイナリがある場合は、アプリケーションの構成ファイルに <NetFx40_PInvokeStackResilience> 要素を含め、以前のバージョンと同様に呼び出しエラーをスタックで解決できます。 ただし、これはアプリケーションのパフォーマンスに影響する可能性があります。
削除されたインターフェイス (アンマネージド API) 開発者の混乱を避けるために、次のインターフェイスは便利なランタイム シナリオを提供しておらず、CLR は実装を提供または受け入れなかったため、削除されました。

* INativeImageINativeImageDependency
* INativeImageInstallInfo
* INativeImageEvaluate
* INativeImageConverter
* ICorModule
* IMetaDataConverter		 なし。

データ

このセクションでは、データ セットと SQL クライアント、Entity Framework、LINQ to SQL、WCF データ サーバー (旧称 ADO.NET Data Services) の使用に関する移行の問題について説明します。

DataSet と SQL Client

次の表では、以前は制限やその他の問題が発生していた機能の機能強化について説明します。

名前空間: System.Data、System.Data.Objects.DataClasses、System.Data.SqlClient

アセンブリ: System.Data (System.Data.dll)、System.Data.Entity (System.Data.Entity.dll内)

特徴 3.5 SP1 との違い
POCO シナリオ IRelatedEnd インターフェイスには、Plain Old CLR Object (POCO) シナリオでの使いやすさを向上させる新しいメソッドがあります。 これらの新しいメソッドは、パラメーターとしてIEntityWithRelationshipsエンティティの代わりにObjectを受け取ります。
行の編集 IndexOf メソッドは、DataView クラスによって実装されたとおり、-1 を返すのではなく、編集中の行の値を正しく返すようになりました。
イベント PropertyChanged イベントは、行が変更された状態にあり、RejectChanges メソッドが呼び出されたときに発生するようになりました。 この変更により、 DataSet オブジェクトの内容を公開する UI コントロールを簡単に作成できます。
例外 Prepare メソッドは、NullReferenceExceptionの代わりに接続が設定されていないか開かれたときに、InvalidOperationExceptionをスローするようになりました。
マッピング ビュー クエリ ビューマッピングエラーは、実行時に NullReferenceException をスローするのではなく、デザイン時にキャッチされるようになりました。

マッピング検証で、概念スキーマ (CSDL) の 2 つの関連付けセットが同じ列にマップされるというエラーがキャッチされるようになりました。
トランザクション トランザクションが完了した後 (中止またはロールバックを含む) 後にアプリケーションが接続に対してステートメントを実行しようとすると、 InvalidOperationException がスローされるようになりました。 以前のバージョンでは例外がスローされず、トランザクションが中止された場合でも追加のコマンドを実行できます。

エンティティ・フレームワーク（Entity Framework）

次の表では、以前は制限やその他の問題が発生していた機能の機能強化について説明します。

名前空間: System.Data、System.Data.Objects、System.Data.Objects.DataClasses

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

特徴 3.5 SP1 との違い
エンティティ オブジェクト SaveChanges メソッドが呼び出されたときに、Detach メソッドとエンティティ オブジェクトの状態の間にパリティが存在するようになりました。 これにより、一貫性が向上し、予期しない例外がスローされるのを防ぐことができます。
Entity SQL Entity SQL の識別子解決に関する規則が改善されました。

Entity SQL パーサーは、マルチパート識別子を解決するためのロジックを改善しました。
構造注釈 Entity Framework で構造注釈が認識されるようになりました。
クエリ クエリで次の機能強化が行われました。

* 空のコレクションに対して null キーを使用する GroupBy クエリでは、クエリに追加の選択があるかどうかに関係なく、行は返されません。
* LINQ クエリと Entity-SQL クエリで生成された SQL では、文字列パラメーターが既定で Unicode 以外の値として扱われます。

LINQ to SQL

次の表では、以前は制限やその他の問題が発生していた機能の機能強化について説明します。

Namespace： System.Data.Linq

Assembly: System.Data.Linq (System.Data.Linq.dll内)

特徴 3.5 SP1 との違い
イベント EntitySet<TEntity> コレクションでは、EntitySet<TEntity>がアンロードされた場合に追加および削除操作のListChanged イベントが発生し、コレクションが読み込まれるときにイベントが発生するようになりました。
クエリ Skip(0) は、LINQ to SQL クエリでは無視されなくなりました。 その結果、このメソッドを持つクエリの動作が異なる場合があります。 たとえば、場合によっては、Skip(0)でOrderBy句が必要になり、OrderBy句が含まれていない場合、クエリはNotSupportedException例外をスローします。

WCF Data Services

次の表では、以前は制限やその他の問題が発生していた機能の機能強化について説明します。

名前空間: System.Data.Services、 System.Data.Services.Client、 System.Data.Services.Common、 System.Data.Services.Providers

アセンブリ: System.Data.Services (System.Data.Services.dll)、System.Data.Services.Client (System.Data.Services.Client.dll内)

特徴 3.5 SP1 との違い
バッチバイナリコンテンツ WCF Data Services では、要求と応答でバッチバイナリ コンテンツがサポートされるようになりました。
変更インターセプター 削除要求に対して変更インターセプターが実行されるようになりました。

変更インターセプターは、エンティティ セット内のエンティティを変更するためにサーバーが要求を受信するたびに実行されるメソッドです。 受信要求が実行される前に実行されます。 変更インターセプターは、変更されるエンティティとそのエンティティに対して実行されている操作へのアクセスを提供します。
例外 次の条件では、 NullReferenceExceptionではなく、より便利な例外がスローされるようになりました。

* データ サービスの呼び出しがタイムアウトしたときの TimeoutException 。
* データ サービスに対して不適切な要求が行われた場合の DataServiceRequestException 。

アプリケーションでは、新しい例外をキャッチするように例外処理を変更する必要があります。
ヘッダー ヘッダーに対して次の機能強化が行われました。

* WCF Data Services が、未指定の値を持つ eTag ヘッダーを正しく拒否するようになりました。
* WCF Data Services はエラーを返すようになり、 if-* ヘッダーが要求内にある場合、リンクへの削除要求の要求は実行されません。
* WCF Data Services は、クライアントが Accept ヘッダーで指定した形式 (Atom、JSON) でクライアントにエラーを返すようになりました。
JSON リーダー JAVAScript Object Notation (JSON) リーダーは、WCF Data Service に送信された JSON ペイロードを処理するときに、単一の円記号 ("\") エスケープ文字を読み取るときにエラーを正しく返すようになりました。
マージ MergeOption列挙体に対して次の機能強化が行われました。

* MergeOption マージ オプションは、データ サービスからの後続の応答の結果として、クライアント上のエンティティを変更しなくなりました。
* MergeOption オプションは、動的 SQL とストアド プロシージャ ベースの更新の間で一貫しています。
リクエスト データ サービスへの要求が処理される前に、 OnStartProcessingRequest メソッドが呼び出されるようになりました。 これにより、 ServiceOperation サービスに対して要求が正しく機能します。
ストリーム WCF Data Services は、読み取りおよび書き込み操作のために基になるストリームを閉じなくなりました。
URI WCF Data Services クライアントによる URI のエスケープが修正されました。

Windows Communication Foundation (WCF)

次の表では、以前は制限やその他の問題が発生していた機能の機能強化について説明します。

特徴 3.5 SP1 との違い
構成ファイル 構成ファイル階層を介した動作の継承を有効にするために、WCF では構成ファイル間のマージがサポートされるようになりました。

構成継承モデルが拡張され、コンピューターで実行されているすべてのサービスに適用される動作をユーザーが定義できるようになりました。

階層のレベルが異なる同じ名前の動作がある場合、動作の変更が発生する可能性があります。
サービス ホスティング 属性allowDefinition="MachineToApplication"を要素定義に追加することで、サービス レベルで<serviceHostingEnvironment>構成要素を指定できなくなりました。

サービス レベルで <serviceHostingEnvironment> 要素を指定することは技術的に正しくがなく、動作に一貫性がありません。

Windows プレゼンテーション ファンデーション (WPF)

アプリケーション

名前空間: System.Windows、 System.Windows.Controls

アセンブリ: PresentationFramework (PresentationFramework.dll内)

特徴 3.5 SP1 との違い 推奨される変更
例外処理 エラーを前に検出できるように、WPF はTargetInvocationExceptionをスローし、元の例外をキャッチするのではなく、NullReferenceException、OutOfMemoryException、StackOverflowException、SecurityExceptionなどの重要な例外にInnerException プロパティを設定します。 なし。
リンクされたリソース リンクを容易にするために、プロジェクトのフォルダー構造以外の場所にあるリソース ファイル (画像など) は、アプリケーションのビルド時にリソース ID としてファイル名だけでなく、リソース ファイルの完全パスを使用します。 アプリケーションは、実行時にファイルを見つけることができます。 なし。
部分信頼アプリケーション セキュリティ上の考慮事項として、部分信頼で実行され、 WebBrowser コントロールまたは HTML を含む Frame コントロールを含む Windows ベースのアプリケーションは、コントロールの作成時に SecurityException をスローします。

ブラウザー アプリケーションは、次のすべての条件が満たされた場合に例外をスローし、メッセージを表示します。

* アプリケーションは Firefox で実行されています。
* アプリケーションは、信頼されていないサイトからインターネット ゾーンで部分信頼で実行されています。
* アプリケーションには、 WebBrowser コントロールまたは HTML を含む Frame コントロールが含まれています。

信頼済みサイトまたはイントラネット ゾーンから実行されるアプリケーションは影響を受けません。		 ブラウザー アプリケーションでは、次のいずれかの操作を行うことで、この変更を容易にできます。

* ブラウザー アプリケーションを完全に信頼して実行します。
* 顧客にアプリケーションのサイトを信頼済みサイト ゾーンに追加してもらう。
リソース ディクショナリ テーマ レベルのリソース ディクショナリを改善し、変更できないようにするために、リソース ディクショナリで定義され、テーマ レベルのディクショナリにマージされる freezable リソースは、常に固定としてマークされ、変更不可になりました。 これは、freezable リソースに対して想定される動作です。 テーマ レベルのマージされたディクショナリで定義されているリソースを変更するアプリケーションは、リソースを複製し、複製されたコピーを変更する必要があります。 または、リソースに x:Shared="false" マークを付け、リソースが照会されるたびに ResourceDictionary によって新しいコピーが作成されるようにすることもできます。
Windows 7 Windows 7 で WPF アプリケーションの動作を向上させるために、ウィンドウの動作を修正するために次の機能強化が行われました。

* ドックとジェスチャの状態が、ユーザーの操作に基づいて期待どおりに動作するようになりました。
* タスク バー コマンド の [ウィンドウのカスケード]、[ウィンドウの重ね合せの表示]、および [ウィンドウを並べて表示 ] が正しい動作になり、適切なプロパティが更新されるようになりました。
* 最大化または最小化されたウィンドウの Top、 Left、 Width、および Height プロパティに、モニターに応じて、他の値ではなく、ウィンドウの正しい復元場所が含まれるようになりました。		 なし。
Windows のスタイルと透明度 AllowsTransparencyがtrueされ、WindowStateがWindowStateされたときに、WindowStyleをWindowStyle以外の値に設定しようとすると、InvalidOperationExceptionがスローされます。 AllowsTransparencyがtrueされているときにWindowStyleを変更する必要がある場合は、Win32 SetWindowLongPtr関数を呼び出すことができます。
XPS ビューアー WPF には、Microsoft XML Paper Specification Essentials Pack (XPSEP) は含まれていません。 XPSEP は、Windows 7 と Windows Vista に含まれています。

.NET Framework 3.5 SP1 がインストールされていない Windows XP を実行しているコンピューターでは、 PrintDialog 以外の WPF API を使用した印刷は WINSPOOL に依存します。 一部のプリンター機能は報告されず、一部のプリンター設定は印刷中に適用されません。		 必要に応じて、Microsoft XML Paper Specification Essentials Pack をインストールします。

コントロール

名前空間: System.Windows、 System.Windows.Controls、 System.Windows.Data、 System.Windows.Input

アセンブリ: PresentationFramework (PresentationFramework.dll)、PresentationCore (PresentationCore.dll)、WindowsBase (WindowsBase.dll)

特徴 3.5 SP1 との違い 推奨される変更
ダイアログ ボックス 信頼性を向上させるために、 ShowDialog メソッドは、 FileDialog コントロールを作成したのと同じスレッドで呼び出されます。 必ず FileDialog コントロールを作成し、同じスレッドで ShowDialog メソッドを呼び出してください。
フローティング ウィンドウ フローティング ウィンドウを誤って再アクティブ化し続けるフォーカス復元ロジック (モーダル ダイアログ ボックスのように表示される) を修正するために、候補がウィンドウの子でない場合、フォーカスの復元が禁止されるようになりました。 なし。
コレクション内の項目 項目が移動または基になるコレクションに追加されると、CollectionViewが並べ替えられない場合は、同じ相対位置のCollectionViewに表示されます。 これにより、コレクション内の項目の位置と、関連付けられた CollectionView内での位置の間の一貫性が提供されます。 ContainerFromItemまたはIndexOfメソッドを使用して、アイテムの固定位置に依存するのではなく、CollectionView内の項目の場所を検索します。
レイアウト 不要な再レイアウトを排除するために、 ShowsNavigationUI を変更してもレイアウトが無効になったり、別のレイアウト パスが発生したりしなくなりました。 ShowsNavigationUIを変更すると別のレイアウト パスが発生すると予想される場合は、プロパティを設定した後にInvalidateVisualを呼び出します。
メニューの メニュー ポップアップで ClearType テキストを有効にするために、 ControlTemplate クラスと MenuItem コントロールおよびその他のコントロールに変更が加えられました。 アプリケーションは、コントロール テンプレートの視覚的な構造に依存しないでください。 ControlTemplateの名前付き部分のみがパブリック コントラクトの一部です。 アプリケーションが ControlTemplate内の特定のオブジェクトを見つける必要がある場合は、ツリー内のオブジェクトの固定位置に依存するのではなく、ビジュアル ツリーで特定の型を検索します。
移動 Frameが場所に直接移動すると、最初のナビゲーションの後にIsNavigationInitiator プロパティがtrueされます。 この変更により、スタートアップ シナリオ中に追加のイベントが発生するのを防ぐことができます。 なし。
ポップアップ CustomPopupPlacementCallback デリゲートは、1 回だけではなく、レイアウト パス中に複数回呼び出すようになりました。 CustomPopupPlacementCallbackデリゲートが前の位置に基づいてPopupの位置を計算する場合は、popupSize、targetSize、またはoffsetパラメーターの値が変更された場合にのみ位置を再計算します。
プロパティ値 SetCurrentValue メソッドを使用すると、プロパティに有効な値を設定できるようになりましたが、プロパティに影響を与えるバインディング、スタイル、トリガーは引き続き考慮されます。 コントロールの作成者は、プロパティ値がユーザー操作などの他のアクションの副作用として変更されるたびに、 SetCurrentValue を使用する必要があります。
テキスト ボックス セキュリティ上の考慮事項として、 Copy メソッドと Cut メソッドは、部分信頼で呼び出されると自動的に失敗します。

さらに、TextBoxBaseから継承するコントロールに対するCopyまたはCut プロパティのプログラムによる実行は、部分的な信頼でブロックされます。 ただし、 Command プロパティがこれらのコマンドのいずれかにバインドされているボタンをクリックするなど、ユーザーが開始するコピーおよび切り取りコマンドは機能します。 標準のコピーとキーボード ショートカットによる切り取り、コンテキスト メニューは、以前と同様に部分信頼で機能します。		 CopyまたはCutコマンドを、ボタンのクリックなど、ユーザーが開始するアクションにバインドします。

グラフィックス

名前空間: System.Windows、 System.Windows.Controls、 System.Windows.Data、 System.Windows.Input、 System.Windows.Media.Effects

アセンブリ: PresentationFramework (PresentationFramework.dll)、PresentationCore (PresentationCore.dll)、WindowsBase (WindowsBase.dll)

特徴 3.5 SP1 との違い 推奨される変更
ビットマップ効果 パフォーマンスを向上させるために、 BitmapEffect クラスと、 BitmapEffect クラスから継承するクラスは、まだ存在しますが、無効になります。 次の条件に該当する場合は、ハードウェアアクセラレータレンダリングパイプラインを使用して効果がレンダリングされます。

* アプリケーションは、半径プロパティが 100 DIU 未満に設定されている DropShadowBitmapEffect または BlurBitmapEffect を使用します。
* アプリケーションを実行するコンピューター上のビデオ カードは、ピクセル シェーダー 2.0 をサポートしています。

これらの条件が満たされていない場合、 BitmapEffect オブジェクトは無効になります。

また、 BitmapEffect オブジェクトまたはサブクラスが検出されると、Visual Studio によってコンパイラ警告が生成されます。

PushEffectメソッドは古い形式としてマークされています。		 従来の BitmapEffect クラスと派生クラスの使用を中止し、代わりに Effect から派生した新しいクラス ( BlurEffect、 DropShadowEffect、 ShaderEffect) を使用します。

ShaderEffect クラスから継承することで、独自の効果を作成することもできます。
ビットマップ フレーム 複製された BitmapFrame オブジェクトは、 DownloadProgress、 DownloadCompleted、および DownloadFailed イベントを受け取るようになりました。 これにより、Web からダウンロードされ、Styleを介してImage コントロールに適用されたイメージが正しく機能します。

次のステートメントがすべて当てはまる場合にのみ、動作の変更が表示されます。

* DownloadProgress、 DownloadCompleted、または DownloadFailed イベントをサブスクライブします。
* BitmapFrame のソースは Web からのソースです。
* BitmapFrame は、ダウンロードの進行中に複製されます。		 イベント ハンドラーで送信者を確認し、送信者が元の BitmapFrameである場合にのみアクションを実行します。
画像のデコード IOExceptionがイメージをデコードできない場合に処理されないようにするために、BitmapSource クラスは、イメージをデコードしない場合にDecodeFailed イベントを発生させます。 IOExceptionの例外処理を削除し、DecodeFailed イベントを使用してデコードエラーを確認します。

インプット

名前空間: System.Windows、 System.Windows.Controls、 System.Windows.Data、 System.Windows.Input

アセンブリ: PresentationFramework (PresentationFramework.dll)、PresentationCore (PresentationCore.dll)、WindowsBase (WindowsBase.dll)

特徴 3.5 SP1 との違い 推奨される変更
コマンド インスタンスのバインド View-Model ベースのコマンド インスタンスをビュー ベースの入力ジェスチャにバインドするメカニズムを提供するために、InputBinding クラスはDependencyObjectではなくFreezableから継承するようになりました。 次のプロパティが依存関係プロパティになりました。

* Command
* CommandParameter
* CommandTarget

この変更の結果、次のようになります。

* InputBinding オブジェクトは、変更可能なままではなく、登録時に固定されるようになりました。
* DependencyObject クラスの制限により、複数のスレッドからインスタンス レベルのInputBinding オブジェクトにアクセスすることはできません。
* Freezable クラスの制限により、登録後にクラス レベルの入力バインドを変更することはできません。
* View-Model で作成されたコマンド インスタンスでは、入力バインドを指定できません。		 バインドを変更可能にする場合は、 InputBinding クラスのインスタンスを個別のスレッドに作成するか、それ以外の場合は固定します。 登録後にクラス レベルの静的 InputBinding を変更しないでください。
ブラウザー アプリケーション WPF ブラウザー アプリケーション (.XBAP) は、オブジェクトが正しい順序でルーティングされたキー イベントを受け取るように、スタンドアロンの WPF アプリケーションと同様にキー イベントを処理するようになりました。 なし。
デッド キーの組み合わせ WPF は、非表示の文字を生成しないデッド キーを難読化しますが、代わりに、キーを次の文字キーと組み合わせて 1 つの文字を生成することを示します。 KeyDownEvent イベントなどのキー入力イベントは、Key プロパティを Key 値に設定して、キーがデッド キーの場合に報告します。 通常、これは予期される動作です。アプリケーションは通常、結合文字を作成するキーボード入力に応答する予定がないためです。 結合された文字の一部であるキーを読み取ることを想定しているアプリケーションでは、 DeadCharProcessedKey プロパティを使用して、難読化されたキーを取得できます。
フォーカス マネージャー FocusManager.GetFocusedElement(DependencyObject) メソッドが、isFocusScope 添付プロパティが true に設定されている要素を渡すと、返された要素がメソッドに渡される要素と同じPresentationSource オブジェクトに属している場合にのみ、そのフォーカス スコープ内の最後のキーボードフォーカス要素である要素が返されます。 なし。

ユーザーインターフェース自動化

名前空間: System.Windows、 System.Windows.Automation.Peers、 System.Windows.Automation.Provider、 System.Windows.Controls、 System.Windows.Data、 System.Windows.Input

アセンブリ: PresentationFramework (PresentationFramework.dll)、PresentationCore (PresentationCore.dll)、UIAutomationProvider (UIAutomationProvider.dll)、WindowsBase (WindowsBase.dll内)

特徴 3.5 SP1 との違い 推奨される変更
ビューのクラス階層 TreeViewAutomationPeerクラスとTreeViewItemAutomationPeer クラスは、FrameworkElementAutomationPeerではなくItemsControlAutomationPeerから継承されます。 TreeViewItemAutomationPeer クラスから継承し、GetChildrenCore メソッドをオーバーライドする場合は、新しいTreeViewDataItemAutomationPeer クラスから継承するオブジェクトを返す方法を検討してください。
画面外のコンテナー 正しくない戻り値を修正するために、 IsOffscreenCore メソッドは、ビュー外にスクロールされた項目コンテナーの false を正しく返すようになりました。 また、メソッドの値は、他のウィンドウによるオクルージョンや、要素が特定のモニターに表示されているかどうかの影響を受けません。 なし。
メニューと子オブジェクト MenuItem オブジェクト以外の子を含むメニューの UI オートメーションを有効にするために、GetChildrenCore メソッドは、MenuItemAutomationPeer オブジェクトではなく、子UIElement オブジェクトのAutomationPeer オブジェクトを返すようになりました。 なし。
新しいインターフェイスとアセンブリ UI オートメーションの新機能を有効にするために、次のインターフェイスが追加されました。

* IItemContainerProvider
* ISynchronizedInputProvider
* IVirtualizedItemProvider		 WPF オートメーション ピアをビルドするすべてのプロジェクトは、UIAutomationProvider.dllへの明示的な参照を追加する必要があります。
親指 GetClassNameCore メソッドは、null ではなく値を返します。 そのため、Thumb クラスから継承するGridSplitterなどのコントロールは、UI オートメーションに名前を報告します。 なし。
仮想化された要素 パフォーマンスを向上させるために、 GetChildrenCore メソッドは、仮想化されているかどうかに関係なく、すべての子オブジェクトではなく、ビジュアル ツリーに実際に存在する子オブジェクトのみを返します。 ItemContainerPatternを使用して、ItemsControlAutomationPeerのすべての項目を反復処理します。

XAML

名前空間: System.Windows、 System.Windows.Controls、 System.Windows.Data、 System.Windows.Input、 System.Windows.Markup

アセンブリ: PresentationFramework (PresentationFramework.dll)、PresentationCore (PresentationCore.dll)、WindowsBase (WindowsBase.dll)

特徴 3.5 SP1 との違い 推奨される変更
マークアップ拡張機能 WPF では、プロパティの設定やコレクション内の項目の作成にマークアップ拡張を使用する場合に、MarkupExtension オブジェクトを返す代わりに、ProvideValue メソッドの値が常に正しく使用されるようになりました。 マークアップ拡張機能は、場合によってはそれ自体を返す場合があります。 アプリケーションが以前のバージョンのMarkupExtension オブジェクトを返したリソースにアクセスする場合は、MarkupExtension オブジェクトではなく、ProvideValueから返されたオブジェクトを参照します。
属性の解析 XAML の属性に使用できるピリオドは 1 つだけになりました。 たとえば、有効な例を次に示します。

<Button Background="Red"/> (ピリオドなし)

<Button Button.Background = "Red"/> (1 つの期間)

次のコードは無効です。

<Button Control.Button.Background = "Red"/> (複数の期間)		 複数のピリオドを持つ XAML 属性を修正します。

XML

この表の行では、以前に制限やその他の問題が発生していた機能の機能強化について説明します。

スキーマと変換

名前空間: System.Xml.Linq; System.Xml.Schema、 System.Xml.XPath

アセンブリ: System.Xml (System.Xml.dll),System.Xml.Linq (System.Xml.Linq.dll内)

特徴 3.5 SP1 との違い
カメレオン スキーマ データの破損を防ぐために、複数のスキーマに含まれているときに、カメレオン スキーマが正しく複製されるようになりました。

カメレオン スキーマは、ターゲット名前空間を持たないスキーマであり、別の XSD に含まれている場合は、インポートするスキーマのターゲット名前空間を受け取ります。 多くの場合、共通の型をスキーマに含めるために使用されます。
ID 関数 オブジェクトが XLST に渡されると、XSLT id 関数は null ではなく正しい値を返すようになりました。

ユーザーがCreateReader メソッドを使用して LINQ to XML クラスからXmlReader オブジェクトを作成し、このXmlReader オブジェクトが XSLT に渡された場合、XSLT 内のid関数のインスタンスは以前に null を返していました。 これは、 id 関数に許可されている戻り値ではありません。
名前空間属性 データの破損を防ぐために、 XPathNavigator オブジェクトは、 x:xmlns 属性のローカル名を正しく返すようになりました。
名前空間宣言 サブツリー上の XmlReader オブジェクトは、1 つの XML 要素内に重複する名前空間宣言を作成しなくなりました。
スキーマの検証 スキーマ検証の誤りを防ぐために、 XmlSchemaSet クラスを使用すると、XSD スキーマを正しく一貫してコンパイルできます。 これらのスキーマには、他のスキーマを含めることができます。たとえば、A.xsdには、C.xsdを含めることができるB.xsdを含めることができます。 これらのいずれかをコンパイルすると、依存関係のこのグラフが走査されます。
スクリプト関数 関数が使用できる関数が実際に使用できる場合に、falseが誤って返されなくなりました。
URI Load メソッドは、LINQ クエリで正しい BaseURI を返すようになりました。

検証

名前空間: System.Xml.Linq; System.Xml.Schema、 System.Xml.XPath

アセンブリ: System.Xml (System.Xml.dll),System.Xml.Linq (System.Xml.Linq.dll内)

特徴 3.5 SP1 との違い
名前空間リゾルバー ReadContentAs メソッドは、渡されたIXmlNamespaceResolverリゾルバーを無視しなくなりました。

以前のバージョンでは、指定された名前空間リゾルバーは無視され、代わりに XmlReader が使用されていました。
空白 リーダーの作成時にデータが失われるのを防ぐために、 Create メソッドは重要な空白を破棄しなくなりました。

XML 検証では、テキストを XML マークアップと混ぜ合わせて使用できる混合コンテンツ モードが認識されます。 混合モードでは、すべての空白が重要であり、報告する必要があります。

書き込み

名前空間: System.Xml.Linq; System.Xml.Schema、 System.Xml.XPath

アセンブリ: System.Xml (System.Xml.dll),System.Xml.Linq (System.Xml.Linq.dll内)

特徴 3.5 SP1 との違い
エンティティ参照 データの破損を防ぐために、XML 属性でエンティティ参照が 2 回エンティティ化されなくなりました。

ユーザーが WriteEntityRef メソッドを使用してエンティティを xmlns 属性に書き込もうとした場合、または xml:lang または xml:space 属性にエンティティを書き込もうとすると、エンティティが出力で 2 回エンティティ化され、データが破損します。
新しい行の処理 データの破損を防ぐために、 XmlWriter オブジェクトは NewLineHandling オプションを優先します。

こちらも参照ください