.NET Framework 4.5.2 から 4.6.1 への移行に関するランタイム変更

.NET Framework 4.5.2 から 4.6.1 に移行する場合は、アプリに影響する可能性があるアプリケーションの互換性の問題に関する次のトピックを確認してください。

ASP.NET

AllowCustomPaging が true に設定された GridView では、ビューの最終ページから他に移動するときに、PageIndexChanging イベントが発生する場合がある

説明

.NET Framework 4.5 でのバグのため、System.Web.UI.WebControls.GridView.AllowCustomPaging が有効になっている System.Web.UI.WebControls.GridView に対して System.Web.UI.WebControls.GridView.PageIndexChanging が発生しないことがあります。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。 回避策として、アプリでは、これらの条件 (System.Web.UI.WebControls.GridView が最終ページで、最後の System.Web.UI.WebControls.GridView.PageSizeSystem.Web.UI.WebControls.GridView.PageSize と異なる) を満たす Page_Load で明示的に BindGrid を行うことができます。 または、(カスタム ページングではなく) ページングを許可するようにアプリを変更することもできます。このシナリオでは問題は発生していません。

名前
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

コア

NetDataContractSerializer を使用して .NET Framework 4.5 でシリアル化された ConcurrentDictionary は、.NET Framework 4.5.1 または 4.5.2 で逆シリアル化できない

説明

型に対する内部的な変更のため、System.Runtime.Serialization.NetDataContractSerializer を使って .NET Framework 4.5 でシリアル化された ConcurrentDictionary<TKey,TValue> オブジェクトは、.NET Framework 4.5.1 または .NET Framework 4.5.2 では逆シリアル化できません。反対の方向 (.NET Framework 4.5.x でシリアル化して、.NET Framework 4.5 で逆シリアル化する) は動作することに注意してください。 同様に、すべての 4.x バージョン間のシリアル化は、.NET Framework 4.6 で機能します。 .NET Framework の 1 つのバージョンでのシリアル化と逆シリアル化は影響を受けません。

提案される解決策

.NET Framework 4.5 と .NET Framework 4.5.1/4.5.2 の間で System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> のシリアル化と逆シリアル化を行う必要がある場合は、System.Runtime.Serialization.NetDataContractSerializer の代わりに、System.Runtime.Serialization.DataContractSerializer または System.Runtime.Serialization.Formatters.Binary.BinaryFormatter シリアライザーなど、代替のシリアライザーを使う必要があります。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって解決できます。

名前 [値]
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

API 分析では検出できません。

AppDomainSetup.DynamicBase が UseRandomizedStringHashAlgorithm でランダム化されなくなった

詳細

.NET Framework 4.6 より前では、UseRandomizedStringHashAlgorithm がアプリの構成ファイルで有効になっている場合、DynamicBase の値がアプリケーション ドメイン間、またはプロセス間でランダム化されます。 .NET Framework 4.6 以降では、DynamicBase は実行されているアプリの異なるインスタンス間、および異なるアプリ ドメイン間で安定した結果を返します。 それでも動的ベースはアプリによって異なります。この変更では、同じアプリの異なるインスタンスのランダムな名前付け要素のみが削除されます。

提案される解決策

UseRandomizedStringHashAlgorithm を有効にすると、DynamicBase がランダム化されなくなることに注意してください。 ランダム ベースが必要な場合は、この API を使用するのではなく、アプリのコードで生成する必要があります。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

インデクサー プロパティに対して Attribute.GetCustomAttributes を呼び出しても、インデックスの型によって、あいまいさを解決できる場合、AmbiguousMatchException はスローされなくなった

詳細

.NET Framework 4.6 より以前には、インデックスの型のみが別のプロパティと異なるインデクサ― プロパティに対して GetCustomAttribute(s) を呼び出すと、System.Reflection.AmbiguousMatchException になりました。 .NET Framework 4.6 からは、プロパティの属性が正しく返されます。

提案される解決策

GetCustomAttribute(s) が、より頻繁に機能するようになったことに注意してください。 アプリが System.Reflection.AmbiguousMatchException に依存していた場合は、代わりにリフレクションを使用して、複数のインデクサーを明示的に検索する必要があります。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

COR_PRF_GC_ROOT_HANDLE がプロファイラーで列挙されていない

説明

.NET Framework v4.5.1 では、プロファイル API RootReferences2() が正しく COR_PRF_GC_ROOT_HANDLE を返しません (代わりに、COR_PRF_GC_ROOT_OTHER として返される)。 この問題は、.NET Framework 4.6 以降で修正されています。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

API 分析では検出できません。

ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベント (TPL プロバイダーなど) をキャプチャしません

説明

空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。 .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。 .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。

提案される解決策

この問題を回避するには、EnableEvents(EventSource, EventLevel) の呼び出しを、使用する "any keywords" マスクを明示的に指定する EnableEvents オーバーロードの呼び出し () に置き換えます: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))

または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

ペルシャ暦でイスラム暦の太陽アルゴリズムが使用されるようになった

詳細

.NET Framework 4.6 以降では、System.Globalization.PersianCalendar クラスでイスラム暦の太陽アルゴリズムが使用されます。 System.Globalization.PersianCalendar と他のカレンダーの間で日付を変換すると、.NET Framework 4.6 以降では、1800 年より前か 2023 年 (グレゴリオ暦) よりも後の日付について、わずかに異なる結果になることがあります。また、PersianCalendar.MinSupportedDateTimeMarch 21, 0622 ではなく March 22, 0622 になります。

提案される解決策

.NET Framework 4.6 で PersianCalendar を使用するときには、一部の早い日付または遅い日付に若干の差が生じる場合があることに注意してください。 また、異なるバージョンの .NET Framework で実行する可能性のあるプロセス間で日付をシリアル化するときには、PersianCalendar の日付文字列として格納しないでください (これらの値が異なる場合があるため)。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

リフレクション オブジェクトが、マネージド コードからアウト プロセス DCOM クライアントに渡されなくなった

説明

リフレクション オブジェクトはマネージド コードからアウト プロセス DCOM クライアントに渡されなくなりました。 影響を受ける型は次のとおりです。

オブジェクトの IMarshal の呼び出しは E_NOINTERFACE を返します。

提案される解決策

非リフレクション オブジェクトで動作するように、マーシャリング コードを更新します。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

既定のアプリケーション ドメインの TargetFrameworkName は、設定されなかった場合、既定で null に設定されなくなった

説明

System.AppDomainSetup.TargetFrameworkName は、以前は、明示的に設定されない限り、既定のアプリケーション ドメインでは null でした。 4.6 以降では、既定のアプリケーション ドメインの System.AppDomainSetup.TargetFrameworkName プロパティは、TargetFrameworkAttribute (ある場合) から派生された既定値を持ちます。 既定以外のアプリケーション ドメインは、明示的にオーバーライドされない限り、既定のアプリケーション ドメイン (4.6 では既定で null に設定されない) から System.AppDomainSetup.TargetFrameworkName を継承し続けます。

提案される解決策

TargetFrameworkName が既定で null に設定されることに依然しないように、コードを更新する必要があります。 このプロパティが引き続き null として評価される必要がある場合、明示的にその値に設定できます。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

.NET で証明書を処理できないときに、X509Certificate2.ToString(Boolean) がスローしなくなった

詳細

.NET Framework 4.5.2 およびそれより前のバージョンでは、このメソッドは、verbose パラメーターとして true が渡され、.NET Framework ではサポートされない証明書がインストールされていた場合、スローしました。 現在は、メソッドは成功し、証明書のアクセス不能部分を省いた有効な文字列を返します。

提案される解決策

X509Certificate2.ToString(Boolean) に依存しているコードは、以前は API がスローしていたような場合には、返される文字列から一部の証明書データ (公開鍵、秘密鍵、拡張子など) が除外されることを予期するように更新する必要があります。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

データ

localhost に解決される SQL Server データベースへの TCP/IP 接続の試みが失敗します

説明

.NET Framework 4.6 および 4.6.1 で、localhost に解決される SQL Server データベースへの TCP/IP 接続の試みが次のエラーで失敗していました: "SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。 サーバーが見つからないかアクセスできません。 インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (プロバイダー:SQL ネットワーク インターフェイス、エラー:26 - 指定されたサーバーまたはインスタンスの位置を特定しているときにエラーが発生しました)"

提案される解決策

この問題は修正済みであり、.NET Framework 4.6.2 では以前の動作に戻っています。 localhost に解決される SQL Server データベースに接続するには、.NET Framework 4.6.2 にアップグレードします。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。

デバッガー

デバッガーですぐに null コアレッサー値が表示されない

説明

.NET Framework 4.5 のバグにより、64 ビット版の Framework で実行中に代入演算が実行された直後に、デバッガーで null 合体演算で設定された値が表示されません。

提案される解決策

デバッガーでの操作に時間がかかると、ローカル/フィールドの値が正しく更新されなくなります。 この問題は .NET Framework 4.6 で修正されました。このバージョンの .NET Framework にアップグレードすれば、問題は解決します。

名前 [値]
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

API 分析では検出できません。

ネットワーキング

ContentDisposition DateTimes で少し異なる文字列が返される

説明

System.Net.Mime.ContentDisposition の文字列表現が更新され、4.6 以降では、常に System.DateTime の時間コンポーネントが 2 桁で表されます。 これは、RFC822RFC2822 に準拠しています。 これにより、4.6 では、配置の時間要素の 1 つが午前 10 時より前のシナリオでは、ToString() は少し異なる文字列を返します。 ContentDispositions は文字列への変換によってシリアル化される場合があるため、ToString() 操作、シリアル化、または GetHashCode 呼び出しを見直す必要があることに注意してください。

提案される解決策

異なるバージョンの .NET Framework からの ContentDispotisions の文字列表現が互いに正しく対応することを期待しないでください。 可能な場合は、比較を行う前に、文字列を ContentDispositions に戻してください。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

シリアル化

不明な型の場合に失敗した DataContract シリアル化の例外メッセージが変更された

説明

.NET Framework 4.6 以降では、"既知の型" がないために System.Runtime.Serialization.DataContractSerializer または System.Runtime.Serialization.Json.DataContractJsonSerializer のシリアル化または逆シリアル化が失敗した場合に提供される例外メッセージが明確化されました。

提案される解決策

アプリは、特定の例外メッセージに依存しないようにする必要があります。 アプリがこのメッセージに依存している場合は、新しいメッセージを使うように更新するか、(可能であれば) 例外の種類のみに依存するように変更します。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

セットアップと配置

.NET Framework 4.6 以降のバージョンでの製品のバージョン管理に関する変更点

詳細

製品のバージョン管理が、.NET Framework の以前のリリース (特に .NET Framework 4、4.5、4.5.1、4.5.2) から変更されました。 変更の詳細は次のとおりです。

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full キーの Version エントリの値が、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.xxxxx に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.xxxxx に、それぞれ変更されました。 .NET Framework 4.5、4.5.1、および 4.5.2 では、4.5.xxxxx という形式でした。
  • .NET Framework ファイルにおけるファイルおよび製品のバージョン管理は、以前のバージョン管理方式である 4.0.30319.x から、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 に、それぞれ変更されました。 ファイルを右クリックしてファイルの [プロパティ] を表示すると、これらの新しい値を確認できます。
  • マネージド アセンブリの AssemblyFileVersionAttribute 属性と AssemblyInformationalVersionAttribute 属性の Version 値は、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 という形式に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 という形式になります。
  • .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1 では、Environment.Version プロパティは固定のバージョン文字列 4.0.30319.42000 を返します。 .NET Framework 4、4.5、4.5.1、および 4.5.2 では、4.0.30319.xxxxx という形式のバージョン文字列が返されます (例: "4.0.30319.18010")。 アプリケーションのコードで Environment.Version プロパティに新しい依存関係を設定することは推奨されていないことに注意してください。

詳しくは、「方法: インストールされている .NET Framework バージョンを確認する」をご覧ください。

提案される解決策

一般に、.NET Framework のランタイムのバージョンやインストール ディレクトリを検出する際、アプリケーションは推奨される技法に従う必要があります。

重要

サブキー名は、.NET Framework Setup ではなく NET Framework Setup です。

  • .NET Framework の共通言語ランタイムへのディレクトリ パスを確認するには、RuntimeEnvironment.GetRuntimeDirectory() メソッドを呼び出します。
  • CLR のバージョンを取得するには、RuntimeEnvironment.GetSystemVersion() メソッドを呼び出します。 .NET Framework 4 とそのポイント リリース (.NET Framework 4.5、4.5.1、4.5.2、および .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1) の場合、このメソッドは文字列 v4.0.30319 を返します。
名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。

.NET Framework 4.6 は、自分自身をレジストリに登録するときに 4.5.x.x バージョンを使用しない

詳細

予想されるように、.NET Framework 4.6 に対してレジストリ (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) に設定されるバージョン キーは、"4.5" ではなく "4.6" で始まります。 これらのレジストリ キーに依存してコンピューターにインストールされている .NET Framework のバージョンを特定するアプリは、4.6 が可能な新しいバージョンであり、前の 4.5.x リリースと互換性があることを認識するように、更新する必要があります。

提案される解決策

4.5 のレジストリ キーを検索することによって .NET Framework 4.5 のインストールを調べるアプリを、4.6 も受け付けるように更新します。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。

ツール

Contract.Invariant または Contract.Requires<TException> が String.IsNullOrEmpty の純粋性を考慮しない

説明

.NET Framework 4.6.1 が対象のアプリでは、Contract.Invariant の不変コントラクトまたは Requires の実行前の状態のコントラクトが String.IsNullOrEmpty メソッドを呼び出した場合、リライターはコンパイラの警告 CC1036:"Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method." を生成します。これはコンパイラ エラーではなく、コンパイラ警告です。

提案される解決策

この動作については GitHubの問題 #339 で報告されています。 この警告が表示されないようにするには、コード コントラクト ツールのソース コードの更新バージョンを GitHub からダウンロードしてコンパイルします。 ページ下部から情報をダウンロードできます。

名前 [値]
スコープ マイナー
バージョン 4.6.1
種類 ランタイム

影響を受ける API

Windows Communication Foundation (WCF)

SSL セキュリティと MD5 証明書認証で NETTCP を使用する WCF サービス

説明

.NET Framework 4.6 では、WCF SSL の既定のプロトコル一覧に TLS 1.1 および TLS 1.2 が追加されます。 クライアントとサーバーの両方のコンピューターに .NET Framework 4.6 以降がインストールされている場合は、TLS 1.2 がネゴシエーションに使用されます。TLS 1.2 では MD5 証明書認証がサポートされません。 このため、顧客が MD5 証明書を使用する場合、WCF クライアントでは WCF サービスへ接続できません。

提案される解決策

次のいずれかの操作を実行することで、この問題を回避して、WCF クライアントを WCF サーバーに接続できるようになります。

  • MD5 アルゴリズムを使用しないように証明書を更新します。 この解決策をお勧めします。
  • バインドがソース コードで動的に構成されていない場合は、TLS 1.1 または以前のバージョンのプロトコルを使用するようにアプリケーションの構成ファイルを更新します。 これにより、引き続き MD5 ハッシュ アルゴリズムによる証明書を使用することができます。

警告

MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。

次の構成ファイルでこれを行います。

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>
  • バインドがソース コードで動的に構成されている場合は、ソース コード内で TLS 1.1 (SslProtocols.Tls11) または以前のバージョンのプロトコルを使用するように TcpTransportSecurity.SslProtocols プロパティを更新します。

警告

MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。

Windows Presentation Foundation (WPF)

DataGrid の UnloadingRow イベントのハンドラーから WPF DataGrid の選択された項目にアクセスすると、NullReferenceException が発生する可能性がある

説明

.NET Framework 4.5 のバグが原因で、行の削除に関連する DataGrid イベントのイベント ハンドラーにより、DataGridSystem.Windows.Controls.Primitives.Selector.SelectedItem または System.Windows.Controls.Primitives.MultiSelector.SelectedItems プロパティにアクセスする場合に System.NullReferenceException がスローされる可能性があります。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 [値]
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

項目が選択されている WPF ListBox、ListView、または DataGrid に対して Items.Refresh を呼び出すと、重複した項目が要素に表示されることがある

説明

.NET Framework 4.5 では、System.Windows.Controls.ListBox で項目が選択されているときにコードから ListBox.Items.Refresh を呼び出すと、選択された項目がリストに複製されることがあります。 同様の問題が System.Windows.Controls.ListViewSystem.Windows.Controls.DataGrid で発生します。 これは、.NET Framework 4.6 で修正されます。

提案される解決策

この問題は、System.Windows.Data.CollectionView.Refresh() が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 [値]
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

CoerceIsSelectionBoxHighlighted

説明

System.Windows.Controls.ComboBox とそのデータ ソースに関連するアクションの特定のシーケンスで System.NullReferenceException が発生する可能性があります。

提案される解決策

可能な場合は、.NET Framework 4.6.2 にアップグレードします。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

ピクセルの高さが異なる項目を含むフラット リストでの項目スクロール

説明

System.Windows.Controls.ItemsControl に仮想化 (IsVirtualizing=true) と項目スクロール (ScrollUnit=Item) を使うコレクションが表示される場合、およびコントロールがスクロールされ、近隣項目と異なる高さ (ピクセル単位) の項目が表示される場合、System.Windows.Controls.VirtualizingStackPanel ではコレクション内のすべての項目に対してイテレーションが行われます。 このイテレーション中に UI は応答しません。コレクションのサイズが大きい場合、ハングとして認識される場合があります。 .NET Framework の以前のリリースであっても、このようなイテレーションは他の状況で発生します。 たとえば、これは、ピクセル スクロール (ScrollUnit=Pixel) が高さの異なる項目 (ピクセル単位) を検出した場合、および階層データの項目スクロール (System.Windows.Controls.TreeView や、グループ化が有効になっている System.Windows.Controls.ItemsControl など) が近隣項目と異なる数の子項目を持つ項目を検出した場合に発生します。項目スクロールと高さが異なる (ピクセル単位) 場合の対処方として、階層データのレイアウトのバグを修正できるようイテレーションが .NET Framework 4.6.1 で導入されました。 データがフラットである場合 (階層がない場合) は必要ないため、そのような状況では .NET Framework 4.6.2 はイテレーションを行いません。

提案される解決策

.NET Framework 4.6.1 でイテレーションが発生し、以前のリリースでは発生しない場合、つまり System.Windows.Controls.ItemsControl が異なる高さの (ピクセル単位) の項目を含むフラットなリストを項目スクロールしている場合、実行できる対応策は以下の 2 つです。

  • .NET Framework 4.6.2 をインストールします。
  • .NET Framework 4.6.1 の修正プログラム HR 1605 をインストールします。
名前
スコープ マイナー
バージョン 4.6.1
種類 ランタイム

影響を受ける API

ObservableCollection<T>.Move に対する ListBoxItem IsSelected のバインディングの問題

説明

項目が選択された System.Windows.Controls.ListBox にバインドされるコレクションで Move(Int32, Int32) または MoveItem(Int32, Int32) を呼び出すと、System.Windows.Controls.ListBox 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。

提案される解決策

Move(Int32, Int32) ではなく System.Collections.ObjectModel.Collection<T>.Remove(T)System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) を呼び出すことで、この問題は解決されます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 [値]
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

ObjectDisposedException が WPF スペルチェックでスローされる

説明

スペルチェックで System.ObjectDisposedException がスローされ、WPF アプリケーションがシャットダウン時にクラッシュする場合があります。 これは .NET Framework 4.7 WPF で修正されます。例外は正しく処理されるため、アプリケーションが悪影響を受けることはなくなります。 ただし、デバッグ時に実行中のアプリケーションで初回例外が見られる場合があるので注意してください。

提案される解決策

.NET Framework 4.7 にアップグレードします

名前 [値]
スコープ エッジ
バージョン 4.6.1
種類 ランタイム

影響を受ける API

API 分析では検出できません。

WPF DataGrid 行ヘッダーを右クリックすると、DataGrid の選択が変更される

説明

複数行が選択されている状態で、選択した System.Windows.Controls.DataGrid 行ヘッダーを右クリックすると、その行のみで System.Windows.Controls.DataGrid の選択が変更されます。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 [値]
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF が wisptis.exe プロセスを生成し、マウスがフリーズする可能性がある

説明

この問題は 4.5.2 から発生するようになり、wisptis.exe が生成され、マウス入力がフリーズする可能性があります。

提案される解決策

この問題はサービス リリースの .NET Framework 4.5.2 (修正プログラム ロールアップ 3026376) で、あるいは .NET Framework 4.6 にアップグレードすることで解決できます。

名前
スコープ Major
バージョン 4.5.2
種類 ランタイム

影響を受ける API

API 分析では検出できません。

WPF スペル チェックが予期しない方法で失敗する

説明

これには、次の WPF スペル チェックのいくつかの問題が含まれます。

  • WPF スペル チェックで System.Runtime.InteropServices.COMException がスローされる場合がある。
  • "別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックが UnauthorizedAccessException で失敗する。
  • WPF スペル チェックで、ドイツ語の "Hausnummer" などの複合語のスペル ミスが正しく識別されない。

提案される解決策

問題 1 - これは .NET Framework 4.6.2 で修正されました。問題 2 - "別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックがサポートされなくなりました。 .NET Framework 4.6.2 以降では、このように起動されたアプリケーションが予期せずクラッシュしなくなります。代わりに、スペル チェックが自動的に無効になります。 問題 3 - これは .NET Framework 4.6.2 で修正されました。

名前
スコープ エッジ
バージョン 4.6.1
種類 ランタイム

影響を受ける API

API 分析では検出できません。

OS の入力言語リストにない言語の場合、Windows 10 でテキスト対応コントロールの WPF スペル チェックが動作しなくなる

説明

プラットフォームのスペル チェック機能は入力言語リストに存在する言語でしか使用できないため、 Windows 10 での実行時には、WPF テキスト対応コントロール向けのスペル チェック機能が動作しないことがあります。Windows 10 では、使用可能なキーボードのリストに言語を追加すると、対応するオンデマンド機能 (FOD) パッケージが自動的にダウンロードおよびインストールされ、スペル チェック機能が提供されます。 入力言語リストに言語を追加することで、スペル チェック機能がサポートされます。

提案される解決策

Windows 10 でスペルチェックを動作させるには、スペルチェック対象の言語またはテキストを入力言語として追加する必要があることに注意してください。

名前
スコープ エッジ
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。

1 つのモニターの外部に拡張すると、クリッピングなしで WPF ウィンドウがレンダリングされる

詳細

Windows 8 以上で実行している .NET Framework 4.6 では、マルチ モニターのシナリオで 1 つのディスプレイの外部にウィンドウを拡張すると、ウィンドウ全体がクリッピングなしでレンダリングされます。 これは、1 つのディスプレイを超える WPF ウィンドウをクリッピングする、以前のバージョンの .NET Framework とは異なります。

提案される解決策

この動作 (クリッピングするかどうか) は、アプリケーションの構成ファイルの <appSettings><EnableMultiMonitorDisplayClipping> 要素を使用するか、アプリの起動時に EnableMultiMonitorDisplayClipping プロパティを設定することで明示的に設定できます。

名前
スコープ マイナー
バージョン 4.6
種類 ランタイム

影響を受ける API

API 分析では検出できません。