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

ブラウザー定義ファイル

ブラウザー定義ファイルは、新規および更新されたブラウザーとデバイスに関する情報を含むように更新されました。 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 サイトを参照してください。

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

構成ファイル

.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  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 統合モードの既定のドキュメントで起動しない可能性のあるイベント ハンドラー)」を参照してください。

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 ブラウザー アプリケーションの概要」を参照してください。

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 エラーが発生することがある)」を参照してください。

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

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

• System.Web.UI.WebControls.MenuRenderingMode が List に設定されている場合、または System.Web.UI.WebControls.MenuRenderingMode が Default に設定され、PagesSection.ControlRenderingCompatibilityVersion が 4.0 以降に設定されている場合、MenuItem.PopOutImageUrl プロパティは無効です。

• Menu.StaticPopOutImageUrl プロパティと Menu.DynamicPopOutImageUrl プロパティに設定されたパスに円記号 (\) が含まれている場合、イメージはレンダリングされません (旧バージョンの ASP.NET では、パスに円記号を含めることができました)。

• 個々のメニュー項目に対して MenuItem.PopOutImageUrl プロパティを設定する代わりに、親 System.Web.UI.WebControls.Menu コントロールの Menu.StaticPopOutImageUrl または Menu.DynamicPopOutImageUrl を設定します。

  または

  System.Web.UI.WebControls.MenuRenderingMode を Table に設定します。または、System.Web.UI.WebControls.MenuRenderingMode を Default に設定し、PagesSection.ControlRenderingCompatibilityVersion を 3.5 に設定します。 これらの設定により、Menu コントロールで、旧バージョンの ASP.NET で使用された HTML テーブル ベースのレイアウトが使用されます。

• Menu.StaticPopOutImageUrl プロパティまたは Menu.DynamicPopOutImageUrl プロパティのパスに円記号 (\) が含まれている場合は、スラッシュ文字 (/) に置き換えます。

出力キャッシュ

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" に変更できます。

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 を使用するように変更してください。

要求の検証

要求の検証を改善するために、ASP.NET 要求の検証は、要求ライフ サイクルの初期に呼び出されます。 その結果、要求の検証は、Web サービスの呼び出しやカスタム ハンドラーに対する要求など、.aspx ファイルが対象でない要求に対して実行されます。 要求の検証は、カスタム HTTP モジュールが要求処理パイプラインで実行されている場合にもアクティブになります。

この変更点の結果、.aspx ファイル以外のリソースに対する要求では、要求検証エラーがスローされることがあります。 要求パイプラインで実行されるカスタム コード (たとえば、カスタム HTTP モジュール) も、要求検証エラーをスローすることがあります。

必要に応じて、Web 構成ファイルで次の設定を使用することにより、.aspx ページでのみ要求検証を起動する古い動作に戻すことができます。

<httpRuntime requestValidationMode="2.0" />

セキュリティに関するメモ

古い動作に戻す場合は、既存のハンドラー、モジュール、およびその他のカスタム コード内のすべてのコードで、安全でない (XSS 攻撃ベクターである) 可能性のある HTTP 入力がチェックされることを確認します。

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 サイトの子として実行しないでください。

CardSpace

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

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

C# コード コンパイラ

Microsoft.CSharp 名前空間にあった Compiler クラス、CompilerError クラス、および ErrorLevel クラスは使用できなくなったため、これらのアセンブリ (cscompmgd.dll) は .NET Framework に含まれていません。

System.CodeDom.Compiler 名前空間の CodeDomProvider クラスなどを使用します。 詳細については、「CodeDOM の使用方法」を参照してください。

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

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

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

夏時間

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

なし。

カルチャ名

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

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

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

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

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

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

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

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

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

Unicode 5.1 規格

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

なし。

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

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

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

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

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

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

なし。

宣言する型

Type.DeclaringType プロパティは、宣言する型が型にない場合に正しく null を返すようになりました。

なし。

グローバル アセンブリ キャッシュの場所の変更

.NET Framework 4 アセンブリでは、グローバル アセンブリ キャッシュは Windows ディレクトリ (%WINDIR%) から Microsoft .NET サブディレクトリ (%WINDIR%\Microsoft.Net) に移動されました。 旧バージョンのアセンブリは以前のディレクトリに残っています。

アンマネージ ASM_CACHE_FLAGS 列挙体には、新しい ASM_CACHE_ROOT_EX フラグが含まれます。 このフラグは、GetCachePath 関数で取得できる .NET Framework 4 アセンブリのキャッシュ場所を取得します。

アプリケーションがアセンブリへの明示パスを使用していない場合 (これは推奨されない処理です) は、なし。

バッファーの長さ

(アンマネージ API)

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

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

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

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

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

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

POCO のシナリオ

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

イベント

DataRowView.PropertyChanged イベントは、行が変更された状態になり、RejectChanges メソッドが呼び出されたときに発生するようになりました。 この変更により、DataSet オブジェクトの内容を公開する UI コントロールの作成が簡単になります。

ビューのマッピング

実行時に NullReferenceException をスローする代わりに、デザイン時にクエリ ビュー マッピング エラーがキャッチされるようになりました。

マッピングの検証は、概念スキーマ (CSDL) 内の 2 つの関連付けセットが同じ列にマッピングされているエラーをキャッチするようになりました。

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

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

構造的な注釈

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

イベント

System.Data.Linq.EntitySet<TEntity> コレクションは、コレクションが読み込まれたときのイベントの生成に加えて、EntitySet<TEntity> がアンロードされている場合の追加操作および削除操作に対して ListChanged イベントを生成するようになりました。

バッチ バイナリ コンテンツ

WCF Data Services は、要求と応答でバッチ バイナリ コンテンツをサポートするようになりました。

例外

次の条件では、NullReferenceException ではなく、より役に立つ例外がスローされるようになりました。

• データ サービスの呼び出しがタイムアウトになった場合の TimeoutException。

• 不適切な要求がデータ サービスに対して行われた場合の DataServiceRequestException。

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

JSON リーダー

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

要求

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

URI

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

構成ファイル

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

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

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

例外処理

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

なし。

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

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

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

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

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

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

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

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

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

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

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

Windows 7

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

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

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

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

なし。

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 をインストールしてください。

ダイアログ ボックス

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

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

コレクションの項目

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

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

メニュー

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

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

ポップアップ

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

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

テキスト ボックス

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

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

ApplicationCommands.Copy コマンドまたは ApplicationCommands.Cut コマンドを、ボタンのクリックのようなユーザーが起動するアクションにバインドします。

ビットマップ効果

パフォーマンスを向上させるために、BitmapEffect クラス、および BitmapEffect クラスから継承するクラスは、引き続き存在していますが、無効になっています。 効果は、次の条件を満たす場合に、ハードウェア アクセラレータによるレンダリング パイプラインを使用して描画されます。

• アプリケーションで、100 DIU 未満の半径のプロパティ セットを持つ DropShadowBitmapEffect または BlurBitmapEffect を使用する。

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

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

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

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

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

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

イメージのデコード

イメージをデコードできない場合に IOException が処理されるのを防ぐために、BitmapSource クラスは、イメージをデコードできない場合に DecodeFailed イベントを発生させます。

IOException の例外処理を削除し、DecodeFailed イベントを使用してデコードの失敗を確認します。

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

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

• Command

• CommandParameter

• CommandTarget

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

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

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

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

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

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

デッド キーの組み合わせ

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

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

ビューのクラス階層

TreeViewAutomationPeer クラスと TreeViewItemAutomationPeer クラスは、FrameworkElementAutomationPeer ではなく ItemsControlAutomationPeer から継承されます。

TreeViewItemAutomationPeer クラスから継承し、GetChildrenCore メソッドをオーバーライドする場合は、新しい TreeViewDataItemAutomationPeer クラスから継承するオブジェクトを返すことを検討します。

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

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

なし。

Thumb

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

なし。

マークアップ拡張機能

WPF でマークアップ拡張機能を使用するときは、状況に応じて MarkupExtension オブジェクトを返す代わりに、常に MarkupExtension.ProvideValue メソッドの値を正確に使用して、プロパティの設定またはコレクションの項目作成を行うようになりました。 マークアップ拡張機能は、状況によっては自身の値を返すことがあります。

旧バージョンの MarkupExtension オブジェクトを返すリソースにアクセスするアプリケーションの場合は、MarkupExtension オブジェクトではなく、ProvideValue から返されるオブジェクトを参照します。

カメレオン スキーマ

データの破損を防ぐために、カメレオン スキーマは、複数のスキーマにインクルードされている場合に、正しく複製されるようになりました。

カメレオン スキーマは、ターゲット名前空間を持たないスキーマであり、別の XSD にインクルードされている場合は、インポート スキーマのターゲット名前空間を引き継ぎます。 これらは、スキーマに共通の型をインクルードするためによく使用されます。

Namespace 属性

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

スキーマの検証

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

URI

XElement.Load メソッドは、LINQ クエリで正しい BaseURI を返すようになりました。

名前空間リゾルバー

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

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

エンティティ参照

データの破損を防ぐために、エンティティ参照は XML 属性を 2 回エンティティ化しなくなりました。

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

2010 年 8 月

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

情報の拡充