次の方法で共有

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

  • [アーティクル]

更新 : 2010 年 8 月

このトピックでは、修正、標準への準拠とセキュリティに関する変更点、顧客フィードバックに基づく変更点など、.NET Framework Version 3.5 Service Pack 1 と .NET Framework Version 4 の間の移行に関する問題について説明します。 これらの変更点のほとんどは、アプリケーションのプログラミング変更を必要としません。 プログラミング変更が必要になる可能性のある変更点については、表の "推奨される変更" 列を参照してください。

このトピックでは、次の分野の主な変更点について説明します。

  • ASP.NET と Web

  • コア

  • データ

  • Windows Communication Foundation (WCF)

  • Windows Presentation Foundation (WPF)

  • XML

このトピックで説明する問題の概要については、「.NET Framework 4 移行ガイド」を参照してください。

Beta 2 より後の移行問題については、「Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM (.NET Framework 4 アプリケーションの移行に関する問題: Beta 2 から RTM へ)」を参照してください。

新しい機能の詳細については、「.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.Browser プロパティで公開されます) は、ブラウザー定義ファイルによって実行されます。 したがって、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、7、または 7.5) によって異なります。

影響を受けるアプリケーションの構成ファイルを変更して、構成システムが ASP.NET 4 アプリケーションを適切に認識するように設定できます。 実行する必要がある変更については、ASP.NET Web サイトの「ASP.NET 4 Breaking Changes (ASP.NET 4 の互換性に影響する変更点)」の「ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications (ASP.NET 2.0 または ASP.NET 3.5 アプリケーションで ASP.NET 4 の子アプリケーションが起動しない)」を参照してください。

ClientID の変更

ASP.NET 4 の新しい ClientIDMode 設定では、ASP.NET が HTML 要素の id 属性を生成する方法を指定できます。 以前のバージョンの ASP.NET では、既定の動作は ClientIDMode の AutoID 設定と同じでした。 現在の既定の設定は Predictable です。 詳細については、「ASP.NET Web サーバー コントロールの識別」を参照してください。

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

コード アクセス セキュリティ (CAS: code access security)

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 属性を使用して、部分的に信頼された 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 3.5 アプリケーションを ASP.NET 4 の下および IIS 7 と IIS 7.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 ファイルを自動的に変更します。

ただし、ASP.NET 3.5 アプリケーションは、再コンパイルしないで .NET Framework 4 を使用して実行できます。 その場合は、.NET Framework 4 の下および IIS 7 または IIS 7.5 の下でアプリケーションを実行する前に、アプリケーションの Web.config ファイルを手動で変更することが必要な場合があります。 行う必要のある具体的な変更は、Service Pack (SP) リリースなど、使用しているソフトウェアの組み合わせによって決まります。 この変更点の影響を受ける可能性のあるソフトウェアの組み合わせ、および特定の組み合わせでの問題を解決する方法については、ASP.NET Web サイトの「ASP.NET 4 Breaking Changes (ASP.NET 4 の互換性に影響する変更点)」の「Configuration Errors Related to New ASP.NET 4 Root Configuration (新しい 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 2010 を使用して 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 では、https://contoso.com に対して要求すると Default.aspx に対する要求が生成されました。 そのドキュメントでは、form 開始タグが次の例のようにレンダリングされます。

<form action="Default.aspx" />

ASP.NET 4 では、https://contoso.com に対する要求によって同じく Default.aspx に対する要求が生成されますが、ASP.NET は現在 HTML の form 開始タグを次の例のようにレンダリングします。

<form action="" />

action 属性が空の文字列の場合、IIS DefaultDocumentModule オブジェクトは Default.aspx への子要求を作成します。 ほとんどの状況では、この子要求はアプリケーション コードに対して透過的であり、Default.aspx ページは正常に実行されます。 ただし、マネージ コードと IIS 7 または IIS 7.5 統合モード間のやり取りによって、マネージ .aspx ページが子要求中に正常に動作を停止することがあります。 次の条件が発生した場合、既定の .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 ページのポストバック イベント ハンドラーは実行されません。

この変更点の結果として発生する可能性のある問題の対処方法については、ASP.NET Web サイトの「ASP.NET 4 Breaking Changes (ASP.NET 4 の互換性に影響する変更点)」の「Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode (IIS 7 または IIS 7.5 統合モードの既定のドキュメントで起動しない可能性のあるイベント ハンドラー)」を参照してください。

ハッシュ アルゴリズム

ASP.NET では、暗号化とハッシュ アルゴリズムの両方を使用して、フォーム認証 Cookie やビューステートなどのデータをセキュリティで保護します。 既定では、ASP.NET 4 は Cookie とビューステートのハッシュ操作に HMACSHA256 アルゴリズムを使用します。 旧バージョンの ASP.NET は、古い HMACSHA1 アルゴリズムを使用していました。

ASP.NET 2.0 と ASP.NET 4 が混在し、フォーム認証 Cookie などのデータが複数の .NET Framework バージョンで動作する必要のあるアプリケーションを実行する場合は、次の設定を Web.config ファイルに追加することで、古い HMACSHA1 アルゴリズムを使用するように ASP.NET 4 Web アプリケーションを構成します。

<machineKey validation="SHA1" />

Internet Explorer でのコントロールのホスティング

Web でコントロールをホストするための優れたソリューションが存在するので、Internet Explorer で Windows フォーム コントロールをホストすることはできなくなりました。 このため、IEHost.dll および IEExec.exe アセンブリは .NET Framework から削除されています。

Web アプリケーションのカスタム コントロールを開発するための次のテクノロジを使用できます。

  • Silverlight アプリケーションを作成し、ブラウザーの外部で実行されるように構成する。 詳細については、「Out-of-Browser Support」を参照してください。

  • XAML ブラウザー アプリケーション (XBAP) を構築し、WPF 機能を活用する (クライアント コンピューター上に .NET Framework が必要です)。 詳細については、「WPF XAML ブラウザー アプリケーションの概要」を参照してください。

HtmlEncode メソッドと UrlEncode メソッド

HttpUtility クラスと HttpServerUtility クラスの HtmlEncode メソッドと UrlEncode メソッドは、次のように単一引用符文字 (') をエンコードするように更新されました。

  • HtmlEncode メソッドは、単一引用符のインスタンスを &#39; としてエンコードします。

  • UrlEncode メソッドは、単一引用符のインスタンスを %27 としてエンコードします。

コードで HtmlEncode メソッドと UrlEncode メソッドを使用している場所を調べて、エンコーディングの変更点によってアプリケーションに影響する変化がないことを確認してください。

ASP.NET 2.0 アプリケーションでの HttpException エラー

ASP.NET 4 を IIS 6 で有効にした後、IIS 6 で実行された ASP.NET 2.0 アプリケーションで次のようなエラーが発生する可能性があります (Windows Server 2003 または Windows Server 2003 R2)。

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 Web サイトの「ASP.NET 4 Breaking Changes (ASP.NET 4 の互換性に影響する変更点)」の「ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd (ASP.NET 2.0 アプリケーションで eurl.axd を参照する HttpException エラーが発生することがある)」を参照してください。

メンバーシップ タイプ

ASP.NET メンバーシップで使用される一部のタイプ (例: System.Web.Security.MembershipProvider) は、System.Web.dll から System.Web.ApplicationServices.dll アセンブリに移動されています。 これらのタイプは、クライアントと拡張 .NET Framework SKU の間のアーキテクチャ層の依存関係を解決するために移動されました。

旧バージョンの ASP.NET からアップグレードされたクラス ライブラリで、移動されたメンバーシップ タイプを使用するクラス ライブラリを ASP.NET 4 プロジェクトで使用すると、コンパイルに失敗することがあります。 この場合は、System.Web.ApplicationServices.dll への参照をクラス ライブラリ プロジェクトに追加します。

メニュー コントロールの変更

Menu コントロールの変更によって、以下の動作が発生します。

Web.config ファイル内の Mobile アセンブリ

旧バージョンの ASP.NET では、ルートにある Web.config ファイルの assemblies セクションの system.web/compilation に 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 では、HttpCachePolicy.SetOmitVaryStar メソッドが追加され、Vary:* ヘッダーを抑制するためにこのメソッドを呼び出すことができました。 ただし、バグ報告では、開発者が既存の SetOmitVaryStar の動作を認識していないことが示唆されています。

ASP.NET 4 では、次のディレクティブを指定する応答から Vary:* HTTP ヘッダーは生成されなくなりました。

<%@ OutputCache Location="ServerAndClient" %>

その結果、Vary:* ヘッダーを抑制するために HttpCachePolicy.SetOmitVaryStar メソッドは不要になりました。 Location 属性に "ServerAndClient" を指定するアプリケーションでは、HttpCachePolicy.SetOmitVaryStar を呼び出す必要なくページをブラウザーにキャッシュできます。

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

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

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

ページの解析

ASP.NET Web ページ (.aspx ファイル) とユーザー コントロール (.ascx ファイル) のページ パーサーは、ASP.NET 4 では旧バージョンの ASP.NET よりも厳密であり、旧バージョンに比べ、無効になるマークアップが多くなります。

ページの実行時に出力されたエラー メッセージを調べて、無効なマークアップが原因で発生したエラーを修正します。

Passport の型

Passport (現在の Live ID SDK) の変更により、ASP.NET 2.0 に組み込まれた Passport のサポートは廃止され、サポートされなくなりました。 その結果、System.Web.Security の Passport に関連する型は、ObsoleteAttribute 属性としてマークされるようになりました。

System.Web.Security 名前空間の Passport 型 (たとえば、System.Web.Security.PassportIdentity) を使用するコードは、Windows Live ID SDK を使用するように変更してください。

FilePath プロパティの PathInfo 情報

ASP.NET 4 では、HttpRequest.FilePath、HttpRequest.AppRelativeCurrentExecutionFilePath、HttpRequest.CurrentExecutionFilePath などのプロパティからの戻り値に PathInfo 値が含まれません。 代わりに、HttpRequest.PathInfo 内の PathInfo 情報を使用できます。 たとえば、次のような URL フラグメントがあるとします。

/testapp/Action.mvc/SomeAction

旧バージョンの ASP.NET では、System.Web.HttpRequest プロパティは次の値を持ちます。

ASP.NET 4 では、System.Web.HttpRequest プロパティは代わりに次の値を持ちます。

コードで System.Web.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 開発サーバー (Cassini) を起動するためです。

  • ファイル ベースの 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 が生成されます。このレンダリングは、Web.config ファイルで次のオプションを使用することで有効にできます。

<system.Web>

<pages controlRenderingCompatibilityVersion="4.0"/>

</system.Web>

このオプションは、既定で 4.0 に設定されます。 Visual Studio 2008 から Visual Studio にアップグレードされた Web プロジェクトでは、互換性のために 3.5 の設定が有効になります。

なし。

ページのトップへ

コア

一般機能

機能

3.5 SP1 との相違

推奨される変更

CardSpace

Windows CardSpace は、.NET Framework には含まれる形ではなく、単独で提供されるようになりました。

Microsoft ダウンロード センターから Windows CardSpace をダウンロードします。

構成ファイル

.NET Framework によるアプリケーション構成ファイルへのアクセス方法が修正されています。

アプリケーション構成ファイルの名前が <アプリケーション名>.config の場合は、<アプリケーション名>.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 を使用します。

「インプロセスの side-by-side 実行」で説明している構成を使用します。

新しいセキュリティ モデル

「.NET Framework 4 におけるセキュリティの変更点」で説明するように、コード アクセス セキュリティ (CAS) ポリシーはオフになり、簡略化されたモデルで置換されています。

アプリケーションで CAS に依存している場合は、変更が必要になることがあります。 詳細については、「コード アクセス セキュリティ ポリシーの互換性と移行」を参照してください。

ページのトップへ

日付と時刻

名前空間: System、アセンブリ: mscorlib (mscorlib.dll 内)

機能

3.5 SP1 との相違

推奨される変更

夏時間

システム クロックと一貫させるために、時間プロパティ (TimeZoneInfo.Local や DateTime.Now など) では、夏時間操作に他の .NET Framework データではなくオペレーティング システム規則を使用するようになりました。

なし。

書式指定文字列

カルチャ依存の書式設定をサポートするために、新しい ParseExact メソッドと TryParseExact メソッドに加えて、ToString、Parse、および TryParse の各メソッドの新しいオーバーロードが TimeSpan 構造体に含まれています。

なし。

ページのトップへ

グローバリゼーション

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

名前空間: System.Globalization、アセンブリ: mscorlib (mscorlib.dll 内)

機能

3.5 SP1 との相違

推奨される変更

カルチャ名

次の名前変更は、ドイツ語、ディベヒ語、およびアフリカーンス語のカルチャに影響します。

  • CurrencyEnglishName: ドイツ語 (スイス) (de-CH) カルチャの通貨名は "sFr." から "Fr." に変更されています。

  • LongDatePattern: ディベヒ語 (モルディブ) (dv-MV) カルチャの長い日付パターンは、"dd/MMMM/yyyy" から "dd/MM/yyyy" に変更されています。

  • PMDesignator: アフリカーンス語 (南アフリカ) カルチャの午後指定子は、 "nm" から "PM" に変更されています。

カルチャ名の変更に注意してください。

LCID パラメーター

自動サーバー設定で予期される動作と一貫させるために、CLR はアンマネージ COM ベースのアプリケーションに対する LCID パラメーターに現在のカルチャを渡さなくなりました。 代わりに、カルチャとして 1033 (en-us) が渡されます。

指定したカルチャを必要とするネイティブ アプリケーションを除き、変更は不要です。

互換性のために残されているカルチャ タイプ

FrameworkCultures および WindowsOnlyCultures のカルチャ タイプは互換性のために残されています。

下位互換性を維持するために、FrameworkCultures は以前の .NET Framework に含まれていたニュートラル カルチャと特定カルチャを返し、WindowsOnlyCultures は空のリストを返すようになりました。

CultureTypes 列挙体の他の値を使用します。

カルチャの取得

Windows 7 以降では、.NET Framework 4 はデータ自体を格納する代わりにオペレーティング システムからカルチャ情報を取得します。 また、.NET Framework は、データの並べ替えおよび大文字と小文字の指定を行うために Windows と同期します。

なし。

Unicode 5.1 規格

.NET Framework は、すべての Unicode 5.1 文字をサポートするようになり、約 1400 文字が追加されました。 追加の文字には、新しい記号、矢印、分音記号、句読点、算術記号、CJK ストローク、漢字、追加のマラヤラム文字、テルグ語の数字、ミャンマー語、ラテン語、アラビア語、ギリシャ語、モンゴル語、キリル語の文字などがあります。 また、Unicode 5.1 では、新しいスクリプトとして、スンダ文字、レプチャ文字、オル チキ文字、ヴァイ文字、サウラーシュトラー文字、カヤーリー文字、ルジャン文字、グルムキー文字、オリヤー文字、タミール文字、テルグ文字、マラヤラム文字、およびチャム文字のサポートが追加されました。

なし。

ページのトップへ

例外

名前空間: System、System.Runtime.ExceptionServices、アセンブリ: mscorlib (mscorlib.dll 内)

機能

3.5 SP1 との相違

推奨される変更

破損状態のプロセスに対する例外

CLR は、破損したプロセス状態に対する例外をマネージ コード内の例外ハンドラーに伝達しなくなりました。

これらの例外は、プロセスの状態が破損していることを示します。 この状態にあるアプリケーションの実行はお勧めしません。

詳細については、HandleProcessCorruptedStateExceptionsAttribute および CLR 徹底解剖ブログの「破損状態例外を処理する」を参照してください。

実行エンジンの例外

キャッチ可能な例外によって不安定なプロセスの実行を継続できるため、ExecutionEngineException は旧式になりました。 この変更により、実行時の予測可能性と信頼性が向上します。

条件を通知するには InvalidOperationException を使用します。

ページのトップへ

リフレクション

名前空間: System.Reflection、アセンブリ: mscorlib (mscorlib.dll 内)

機能

3.5 SP1 との相違

推奨される変更

アセンブリ ハッシュ アルゴリズム

ランタイムはアセンブリが読み込まれていない場合に参照アセンブリのハッシュ アルゴリズムを認識しないため、AssemblyName.HashAlgorithm プロパティは AssemblyHashAlgorithm.None を返すようになりました (これは、Assembly.GetReferencedAssemblies メソッドによって返されるような参照アセンブリでのプロパティの使用を表します)。

なし。

アセンブリの読み込み

アセンブリの冗長な読み込みを防ぎ、仮想アドレス空間を節約するために、CLR は Win32 MapViewOfFile 関数のみ使用してアセンブリを読み込むようになりました。 LoadLibrary 関数も呼び出さなくなりました。

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

  • ProcessModuleCollection は、クラス ライブラリ (.dll ファイル) のモジュールを含まなくなりました。これらのモジュールは Process.GetCurrentProcess().Modules の呼び出しから取得されるためです。

  • EnumProcessModules 関数を使用する Win32 アプリケーションは、一覧にあるすべてのマネージ モジュールを参照しなくなりました。

なし。

宣言する型

Type.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 (グローバル アセンブリ キャッシュ ツール) は、シェル プラグイン ビューアーをサポートしなくなりました。

なし。

相互運用性

名前空間: System.Runtime.InteropServices、アセンブリ: mscorlib (mscorlib.dll 内)

機能

3.5 SP1 との相違

推奨される変更

バッファーの長さ

(アンマネージ API)

メモリを節約するために、ICorProfilerInfo2::GetStringLayout メソッドの pBufferLengthOffset パラメーターの機能は、pStringLengthOffset パラメーターと一致するように変更されました。 両方のパラメーターが文字列の長さのオフセット位置を指すようになりました。 バッファーの長さは、文字列クラスの表現から削除されました。

バッファーの長さへの依存を除去します。

JIT デバッグ

Just-In-Time (JIT) デバッグの登録を簡略化するために、.NET Framework デバッガーは、ネイティブ コードの JIT デバッグの動作を制御する AeDebug レジストリ キーのみ使用するようになりました。 この変更の結果は次のとおりです。

  • マネージ コードとネイティブ コードに 2 つの異なるデバッガーを登録することはできなくなりました。

  • 非対話形式のプロセスに対してデバッガーを自動的に開始することはできなくなりましたが、対話形式のプロセスについてはユーザーにプロンプトを表示できます。

  • デバッガーの起動に失敗した場合、または起動する必要のある登録済みデバッガーがない場合の通知は、行われなくなりました。

  • アプリケーションの対話機能に依存する自動起動ポリシーは、サポートされなくなりました。

必要に応じてデバッグ操作を調整します。

プラットフォーム呼び出し

アンマネージ コードとの相互運用性のパフォーマンスを向上させるために、プラットフォーム呼び出しに不適切な呼び出し規約があると、アプリケーションが失敗するようになりました。 以前のバージョンでは、マーシャリング レイヤーがこれらのエラーを 1 つずつ解決しました。

Microsoft Visual Studio 2010 でアプリケーションをデバッグすると、これらのエラーが警告されるため、エラーを修正できます。

更新できないバイナリがある場合は、アプリケーションの構成ファイルに <NetFx40_PInvokeStackResilience> 要素を含めて、旧バージョンのように呼び出しエラーを 1 つずつ解決できるようにすることができます。 ただし、この処理はアプリケーションのパフォーマンスに影響することがあります。

削除されたインターフェイス

(アンマネージ API)

開発者の混乱を避けるために、次のインターフェイスが削除されました。これらのインターフェイスで有用な実行時シナリオが提供されることはなく、CLR でも実装の提供または受け入れを行っていませんでした。

  • INativeImageINativeImageDependency

  • INativeImageInstallInfo

  • INativeImageEvaluate

  • INativeImageConverter

  • ICorModule

  • IMetaDataConverter

なし。

ページのトップへ

データ

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

データセットと SQL クライアント

次の表に、以前は制限やその他の問題があった機能に対する改善点を示します。

名前空間: 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 のシナリオ

System.Data.Objects.DataClasses.IRelatedEnd インターフェイスには、Plain Old CLR Object (POCO) シナリオでのその使用性を向上させる新しいメソッドがあります。 これらの新しいメソッドは、IEntityWithRelationships エンティティではなく Object をパラメーターとして受け取ります。

行の編集

DataView クラスで実装されているような IndexOf メソッドは、-1 を返す代わりに、編集されている行の値を正しく返すようになりました。

イベント

DataRowView.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 との相違

エンティティ オブジェクト

ObjectContext.SaveChanges メソッドが呼び出された場合、現在は ObjectContext.Detach メソッドとエンティティ オブジェクトの状態の間にパリティがあります。 この一貫性の向上により、予期しない例外がスローされなくなります。

Entity SQL

Entity SQL の識別子解決の規則が改善されました。

Entity SQL パーサーで、マルチパート識別子の解決ロジックが改善されました。

構造的な注釈

エンティティ フレームワークは、構造的な注釈を認識するようになりました。

クエリ

クエリでは次の改良が行われました。

  • 空のコレクションに対する NULL キーを使用した GroupBy クエリは、クエリに追加の選択があるかどうかにかかわらず、行を返しません。

  • LINQ および Entity-SQL クエリで生成された SQL は、文字列パラメーターを既定で非 Unicode 値として扱うようになりました。

ページのトップへ

LINQ to SQL

次の表に、以前は制限やその他の問題があった機能に対する改善点を示します。

名前空間: System.Data.Linq、アセンブリ: System.Data.Linq (System.Data.Linq.dll 内)

機能

3.5 SP1 との相違

イベント

System.Data.Linq.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 ではなく、より役に立つ例外がスローされるようになりました。

アプリケーションでは、新しい例外をキャッチするように例外処理を変更する必要があります。

Headers

ヘッダーに対して次の改良が行われました。

  • WCF Data Services は、指定されていない値を持つ eTag ヘッダーを正しく拒否するようになりました。

  • WCF Data Services は、要求に if-* ヘッダーがある場合にエラーを返すようになり、リンクへの削除要求に対する要求を実行しなくなりました。

  • WCF Data Services は、クライアントが Accept ヘッダーに指定したフォーマット (Atom、JSON) でエラーをクライアントに返すようになりました。

JSON リーダー

JavaScript Object Notation (JSON) リーダーは、WCF Data Service に送信された JSON ペイロードを処理する場合に、単一の円記号 ("\") エスケープ文字を読み取ったときにエラーを正しく返すようになりました。

マージ

MergeOption 列挙に対して次の改良が行われました。

  • AppendOnly マージ オプションは、データ サービスからの後続の応答の結果としてクライアントのエンティティを変更しなくなりました。

  • PreserveChanges オプションは、動的 SQL とストアド プロシージャ ベースの更新の間で一貫性を持つようになりました。

要求

データ サービスへの要求が処理される前に、DataService<T>.OnStartProcessingRequest メソッドが呼び出されるようになりました。 これにより、ServiceOperation サービスに対する要求の動作が正しくなります。

ストリーム

WCF Data Services は、読み取り操作と書き込み操作の基になるストリームを閉じなくなりました。

URI

WCF Data Services クライアントによる URI のエスケープが修正されました。

Windows Communication Foundation (WCF)

次の表に、以前は制限やその他の問題があった機能に対する改善点を示します。

機能

3.5 SP1 との相違

構成ファイル

構成ファイル階層を通じた動作の継承を有効にするために、WCF は構成ファイル間でのマージをサポートするようになりました。

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

異なる階層レベルに同じ名前の動作がある場合は、動作の変更が検出されることがあります。

サービス ホスティング

allowDefinition="MachineToApplication" 属性を要素定義に追加することにより、サービス レベルで <serviceHostingEnvironment> 要素を指定することはできなくなりました。

サービス レベルで <serviceHostingEnvironment> 要素を指定することは技術的に不適切であり、一貫性のない動作の原因になります。

ページのトップへ

Windows Presentation Foundation (WPF)

アプリケーション

名前空間: System.Windows、System.Windows.Controls、アセンブリ: PresentationFramework (PresentationFramework.dll 内)

機能

3.5 SP1 との相違

推奨される変更

例外処理

エラーを早く検出できるように、WPF では、元の例外をキャッチする代わりに、TargetInvocationException をスローし、InnerException プロパティを重大な例外 (NullReferenceException、OutOfMemoryException、StackOverflowException、SecurityException など) に設定します。

なし。

リンク リソース

リンクを簡単にするために、プロジェクト フォルダー構造以外の場所にあるリソース ファイル (イメージなど) では、アプリケーションがビルドされるときに、ファイル名だけでなくリソース ファイルの完全パスをリソース ID として使用します。 これにより、アプリケーションが実行時にファイルを見つけられるようになります。

なし。

部分信頼アプリケーション

セキュリティを考慮して、部分信頼で実行される Windows ベース アプリケーション、および WebBrowser コントロールまたは HTML を格納する Frame コントロールを含む Windows ベース アプリケーションは、コントロールが作成されるときに SecurityException をスローします。

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

  • アプリケーションを Firefox で実行している。

  • アプリケーションを、信頼されていないサイトのインターネット ゾーンで部分信頼によって実行している。

  • アプリケーションに WebBrowser コントロール、または HTML を格納する Frame コントロールが含まれている。

信頼されたサイトまたはイントラネット ゾーンから実行するアプリケーションは影響を受けません。

ブラウザー アプリケーションで、次のいずれかを実行することでこの変更の影響を軽減できます。

  • ブラウザー アプリケーションを完全信頼で実行します。

  • 顧客に依頼して、アプリケーションのサイトを信頼されたサイト ゾーンに追加してもらいます。

  • 顧客に依頼して、Internet Explorer を使用してアプリケーションを実行してもらいます。

リソース ディクショナリ

テーマ レベルのリソース ディクショナリを改善し、その変更を防ぐために、リソース ディクショナリで定義された固定可能リソース、およびテーマ レベル ディクショナリにマージされた固定可能リソースは、常に固定され、変更できなくなりました。 これは、固定可能リソースで予測される動作です。

アプリケーションで、テーマ レベルでマージされたディクショナリで定義されたリソースを変更する場合は、リソースを複製して、複製した方のコピーを変更する必要があります。 または、リソースを x:Shared="false" とマークして、リソースが必要になるたびに ResourceDictionary が新しいコピーを作成できるようにします。

Windows 7

WPF アプリケーションを Windows 7 でより適切に動作させるために、ウィンドウの動作を修正する次の改良が行われました。

  • ドッキングとジェスチャは、ユーザーとのやり取りに基づいて予想どおりに動作するようになりました。

  • タスク バー コマンド [ウィンドウを重ねて表示]、[ウィンドウを上下に並べて表示]、および [ウィンドウを左右に並べて表示] は正しく動作し、適切なプロパティを更新するようになりました。

  • 最大化または最小化されたウィンドウの Top、Left、Width、および Height の各プロパティには、モニターに応じて、他の値ではなくウィンドウの適切な復元場所が含まれるようになりました。

なし。

ウィンドウのスタイルと透過性

AllowsTransparency が true で、WindowState が Minimized のときに、WindowStyle を None 以外の値に設定しようとすると、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 との相違

推奨される変更

ダイアログ ボックス

信頼性を高めるために、CommonDialog.ShowDialog メソッドは、Microsoft.Win32.FileDialog コントロールを作成したのと同じスレッド上で呼び出されます。

必ず FileDialog コントロールを作成して、同じスレッド上で ShowDialog メソッドを呼び出すようにしてください。

フローティング ウィンドウ

フローティング ウィンドウの再アクティブ化が間違って保持される (モーダル ダイアログ ボックスのように表示する) フォーカス復元ロジックを修正するために、候補がウィンドウの子でない場合にはフォーカスの復元が阻止されるようになりました。

なし。

コレクションの項目

基になるコレクションに項目が移動または追加されたときは、CollectionView を並べ替えない限り、その項目は CollectionView でも同じ場所に表示されます。 この処理により、コレクション内の項目の場所と、関連付けられた CollectionView 内の項目の場所との間で一貫性が保たれます。

固定された場所にある項目に依存する代わりに、ItemContainerGenerator.ContainerFromItem メソッドまたは CollectionView.IndexOf メソッドを使用して、CollectionView 内で項目の場所を検索します。

レイアウト

不要な再レイアウトを排除するために、Page.ShowsNavigationUI を変更しても、レイアウトが無効にされたり別のレイアウト パスが実行されたりすることがなくなりました。

ShowsNavigationUI を変更して別のレイアウト パスを実行する場合は、プロパティの設定後に UIElement.InvalidateVisual を呼び出します。

メニュー

メニュー ポップアップで ClearType テキストを有効にするために、ControlTemplate クラス、および MenuItem コントロールとその他のコントロールが変更されました。

アプリケーションを、コントロール テンプレートの視覚的な構造に依存させないでください。 パブリック コントラクトの一部であるのは ControlTemplate の名前付きパーツのみです。 アプリケーションで ControlTemplate 内の任意のオブジェクトを検索する必要がある場合は、ツリー内で固定されたオブジェクトの場所に依存するのではなく、視覚的なツリーで特定の型を検索するようにします。

ナビゲーション

Frame で、ある場所に直接移動する場合、IsNavigationInitiator プロパティは最初の移動後に true になります。 この変更により、起動シナリオ中に他のイベントが発生しなくなります。

なし。

ポップアップ

CustomPopupPlacementCallback デリゲートは、レイアウト パスの実行中に複数回 (従来は 1 回のみ) 呼び出すことができるようになりました。

CustomPopupPlacementCallback デリゲートで Popup の場所を以前の場所に基づいて計算する場合は、popupSize、targetSize パラメーターまたは offset パラメーターの値が変更された場合にのみ場所を再計算します。

プロパティの値

DependencyObject.SetCurrentValue メソッドでは、バインディング、スタイルまたはトリガーによるプロパティへの影響を維持したまま、プロパティに有効な値を設定できるようになりました。

コントロールの作成で、ユーザー操作などの他のアクションに影響を与えるプロパティ値の変更が伴う場合は、常に SetCurrentValue を使用する必要があります。

テキスト ボックス

セキュリティを考慮して、TextBoxBase.Copy メソッドおよび TextBoxBase.Cut メソッドは、部分信頼で呼び出されるとエラーなしで失敗します。

また、TextBoxBase から継承するコントロールで、ApplicationCommands.Copy プロパティまたは ApplicationCommands.Cut プロパティをプログラムによって実行すると、部分信頼が原因でブロックされます。 ただし、ユーザーが起動したコピーおよび切り取りのコマンド (ButtonBase.Command プロパティがこれらのコマンドにバインドされているボタンをクリックする場合など) は動作します。 ショートカット キーおよびコンテキスト メニューを使用した標準的なコピーと切り取りも、同様に部分信頼で機能します。

ApplicationCommands.Copy コマンドまたは ApplicationCommands.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 を使用する。

  • アプリケーションを実行するコンピューター上のビデオ カードが Pixel Shader 2.0 をサポートしている。

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

また、Visual Studio 2010 では、BitmapEffect オブジェクトまたはサブクラスが見つかった場合にコンパイラの警告が生成されます。

PushEffect メソッドは現在は使用されていません。

従来の BitmapEffect と派生クラスの使用を中止し、Effect、BlurEffect、DropShadowEffect および ShaderEffect から派生した新しいクラスを使用します。

ShaderEffect クラスから継承することで、独自の効果を作成することもできます。

ビットマップ フレーム

複製された BitmapFrame オブジェクトは DownloadProgress イベント、DownloadCompleted イベント、および DownloadFailed イベントを受け取るようになりました。 この処理により、Web からダウンロードされ、Image コントロールに適用されたイメージが Style で適切に動作するようになります。

次の状況のすべてに当てはまる場合にのみ、動作が変化します。

イベント ハンドラーで送信元をチェックして、送信元が元の 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 との相違

推奨される変更

コマンド インスタンスのバインディング

ビュー モデル ベースのコマンド インスタンスをビュー ベースの入力ジェスチャにバインドするメカニズムを提供するために、InputBinding クラスは、DependencyObject ではなく Freezable から継承するようになりました。 次のプロパティは依存関係プロパティになりました。

この変更の結果は次のとおりです。

  • InputBinding オブジェクトは、登録時に固定され、変更できない状態になります。

  • DependencyObject クラスの制限により、複数のスレッドからインスタンス レベルの InputBinding オブジェクトにアクセスすることはできません。

  • Freezable クラスの制限により、登録後にクラス レベルの入力バインディングを変更することはできません。

  • ビュー モデルで作成されたコマンド インスタンスに入力バインディングを指定することはできません。

バインディングを変更可能にする場合は、スレッドごとに InputBinding クラスのインスタンスを作成します。それ以外の場合は、バインディングを固定します。 クラス レベルの静的 InputBinding は、登録後に変更しないでください。

ブラウザー アプリケーション

WPF ブラウザー アプリケーション (.XBAP) では、スタンドアロン WPF アプリケーションと同じようにキー イベントを処理することで、オブジェクトが正しい順序でルーティング キー イベントを受け取れるようになりました。

なし。

デッド キーの組み合わせ

WPF ではデッド キーが難読化されています。デッド キーとは、そのキーを押しても文字は表示されませんが、続けて文字キーを押してその文字と組み合わせることで、1 つの文字を生成するキーのことです。 KeyDown イベントなどのキー入力イベントでは、Key プロパティを DeadCharProcessed 値に設定することで、入力されたキーがデッド キーであることを通知します。 これは予期される動作です。アプリケーションは一般に、1 つの文字を組み合わせて作成する場合のキーボード入力に応答しないためです。

組み合わせ文字の一部になり得るキーの読み取りが予測されるアプリケーションでは、DeadCharProcessedKey プロパティを使用して、難読化されたキーを取得できるようになりました。

フォーカス マネージャー

IsFocusScope 添付プロパティが true に設定されている要素が FocusManager.GetFocusedElement メソッドに渡されると、このメソッドは、そのフォーカス スコープ内で最後にキーボード フォーカスされた要素を返します。ただしこれは、返される要素が、メソッドに渡された要素と同じ PresentationSource オブジェクトに属する場合に限られます。

なし。

ページのトップへ

UI オートメーション

名前空間: 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 クラスから継承するオブジェクトを返すことを検討します。

コンテナー オフ スクリーン

正しくない戻り値を修正するために、UIElementAutomationPeer.IsOffscreenCore メソッドは、ビューのスクロールの範囲外にある項目コンテナーについて、false を正しく返すようになりました。 このメソッドの値は、他のウィンドウを閉じても変化しません。また、要素が特定のモニターに表示されるかどうかに影響されません。

なし。

メニューと子オブジェクト

MenuItem オブジェクト以外の子を含むメニューの UI オートメーションを有効にするために、GetChildrenCore メソッドは、MenuItemAutomationPeer オブジェクトではなく、子 UIElement オブジェクトの AutomationPeer オブジェクトを返すようになりました。

なし。

新しいインターフェイスおよびアセンブリ

UI オートメーションの新機能を有効にするために、次のインターフェイスが追加されました。

WPF オートメーション ピアを構築するプロジェクトでは、UIAutomationProvider.dll への明示的な参照を追加する必要があります。

Thumb

GetClassNameCore メソッドは、null の代わりに値を返します。 このため、GridSplitter などの、Thumb クラスから継承されたコントロールは、UI オートメーションに名前を報告します。

なし。

仮想化された要素

パフォーマンスを向上させるために、UIElementAutomationPeer.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 オブジェクトを返す代わりに、常に 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 関数

XSLT id 関数は、XmlReader オブジェクトが XLST に渡される場合に、null ではなく適切な値を返すようになりました。

ユーザーが CreateReader メソッドを使用して LINQ to XML クラスから XmlReader オブジェクトを作成し、この XmlReader オブジェクトが XSLT に渡された場合、XSLT の id 関数のインスタンスは以前は null を返しました。 これは、id 関数に対して許容される戻り値ではありません。

Namespace 属性

データの破損を防ぐために、XPathNavigator オブジェクトは x:xmlns 属性のローカル名を正しく返すようになりました。

[名前空間の宣言]

サブツリーの XmlReader オブジェクトは、1 つの XML 要素内に重複する名前空間宣言を作成しなくなりました。

スキーマの検証

誤ったスキーマ検証を防ぐために、XmlSchemaSet クラスは、XSD スキーマが正しく一貫してコンパイルされるようにします。 これらのスキーマには、他のスキーマを含めることができます。たとえば、A.xsd は B.xsd を含むことができ、さらにその中には C.xsd を含むことができます。 これらのいずれかをコンパイルすると、この依存関係のグラフが走査されます。

スクリプト関数

function-available 関数は、関数が実際に使用可能な場合に false を間違って返さなくなりました。

URI

XElement.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 との相違

名前空間リゾルバー

XmlReader.ReadContentAs メソッドは、渡された IXmlNamespaceResolver リゾルバーを無視しなくなりました。

以前のバージョンでは、指定した名前空間リゾルバーが無視され、XmlReader が代わりに使用されました。

空白

リーダーを作成するときのデータの消失を防ぐために、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 回エンティティ化しなくなりました。

ユーザーがエンティティを xmlns 属性に書き込もうとするか、または WriteEntityRef メソッドを使用して xml:lang 属性または xml:space 属性に書き込もうとした場合、エンティティは出力に 2 回エンティティ化されるため、データが破損します。

改行処理

データの破損を防ぐために、XmlWriter オブジェクトは None オプションを考慮します。

ページのトップへ

参照

その他の技術情報

.NET Framework 4 移行ガイド

.NET Framework 4 の新機能

.NET Framework のバージョンの互換性

.NET Framework の互換性のために残されている機能

.NET Framework 4 における新しい型およびメンバー

Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM (.NET Framework 4 アプリケーションの移行に関する問題: Beta 2 から RTM へ)

.NET Framework 4 への Office ソリューションの移行

履歴の変更

日付

履歴

理由

2010 年 8 月

Web ブラウザーでのコントロールのホスト、コンパイラ クラスと CodeDOM、およびグローバル アセンブリ キャッシュ ビューアーに関する問題を追加しました。

情報の拡充