.NET Framework 4.6.x への移行に関するランタイム変更
この記事では、.NET Framework 4.6、 4.6.1、および 4.6.2 で生じたアプリの互換性の問題について説明します。
.NET Framework 4.6
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.PageSize が System.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 のような別のシリアライザーを使用する必要があります。 または、この問題は .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
- Attribute.GetCustomAttribute(MemberInfo, Type)
- Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
- Attribute.GetCustomAttributes(MemberInfo)
- Attribute.GetCustomAttributes(MemberInfo, Boolean)
- Attribute.GetCustomAttributes(MemberInfo, Type)
- Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)
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.MinSupportedDateTime は March 21, 0622
ではなく March 22, 0622
になります。
提案される解決策
.NET Framework 4.6 で PersianCalendar を使用するときには、一部の早い日付または遅い日付に若干の差が生じる場合があることに注意してください。 また、異なるバージョンの .NET Framework で実行する可能性のあるプロセス間で日付をシリアル化するときには、PersianCalendar の日付文字列として格納しないでください (これらの値が異なる場合があるため)。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6 |
種類 | ランタイム |
影響を受ける API
リフレクション オブジェクトが、マネージド コードからアウト プロセス DCOM クライアントに渡されなくなった
説明
リフレクション オブジェクトはマネージド コードからアウト プロセス DCOM クライアントに渡されなくなりました。 影響を受ける型は次のとおりです。
- System.Reflection.Assembly
- System.Reflection.MemberInfo (およびその派生型、System.Reflection.FieldInfo、System.Reflection.MethodInfo、System.Type、System.Reflection.TypeInfo など)
- System.Reflection.MethodBody
- System.Reflection.Module
- System.Reflection.ParameterInfo
オブジェクトの IMarshal
の呼び出しは E_NOINTERFACE
を返します。
提案される解決策
非リフレクション オブジェクトで動作するように、マーシャリング コードを更新します。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6 |
種類 | ランタイム |
影響を受ける API
- System.Reflection.Assembly
- System.Reflection.FieldInfo
- System.Reflection.MemberInfo
- System.Reflection.MethodBody
- System.Reflection.MethodInfo
- System.Reflection.Module
- System.Reflection.ParameterInfo
- System.Reflection.TypeInfo
- System.Type
既定のアプリケーション ドメインの 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
Data
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 桁で表されます。 これは、RFC822 と RFC2822 に準拠しています。 これにより、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
- DataContractJsonSerializer(Type)
- DataContractJsonSerializer(Type, IEnumerable<Type>)
- DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
- DataContractJsonSerializer(Type, String)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>)
- DataContractJsonSerializer(Type, XmlDictionaryString)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
- DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractSerializer(Type)
- DataContractSerializer(Type, DataContractSerializerSettings)
- DataContractSerializer(Type, IEnumerable<Type>)
- DataContractSerializer(Type, String, String)
- DataContractSerializer(Type, String, String, IEnumerable<Type>)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
セットアップと配置
.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 のランタイム バージョンを検出するには、「方法:インストールされている .NET Framework バージョンを確認する」を参照してください。
- .NET Framework のインストール パスを確認するには、
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
キーのInstallPath
エントリの値を使用します。
重要
サブキー名は、.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 分析では検出できません。
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 イベントのイベント ハンドラーにより、DataGrid の System.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.ListView と System.Windows.Controls.DataGrid で発生します。 これは、.NET Framework 4.6 で修正されます。
提案される解決策
この問題は、System.Windows.Data.CollectionView.Refresh() が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。
Value | |
---|---|
スコープ | マイナー |
Version | 4.5 |
Type | ランタイム |
影響を受ける API
CoerceIsSelectionBoxHighlighted
詳細
System.Windows.Controls.ComboBox とそのデータ ソースに関連するアクションの特定のシーケンスで System.NullReferenceException が発生する可能性があります。
提案される解決策
可能な場合は、.NET Framework 4.6.2 にアップグレードします。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6 |
種類 | ランタイム |
影響を受ける 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
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 分析では検出できません。
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 分析では検出できません。
.NET Framework 4.6.1
ツール
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 Presentation Foundation (WPF)
ピクセルの高さが異なる項目を含むフラット リストでの項目スクロール
説明
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
ObjectDisposedException が WPF スペルチェックでスローされる
説明
スペルチェックで System.ObjectDisposedException がスローされ、WPF アプリケーションがシャットダウン時にクラッシュする場合があります。 これは .NET Framework 4.7 WPF で修正されます。例外は正しく処理されるため、アプリケーションが悪影響を受けることはなくなります。 ただし、デバッグ時に実行中のアプリケーションで初回例外が見られる場合があるので注意してください。
提案される解決策
.NET Framework 4.7 にアップグレードします
名前 | 値 |
---|---|
スコープ | エッジ |
バージョン | 4.6.1 |
種類 | ランタイム |
影響を受ける 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 分析では検出できません。
.NET Framework 4.6.2
データ
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 分析では検出できません。
Azure SQL データベースの接続プールのブロック期間が削除される
詳細
.NET Framework 4.6.2 以降では、既知の Azure SQL データベースへの接続確立要求の場合 (*.database.windows.net、*.database.chinacloudapi.cn、*.database.usgovcloudapi.net、*.database.cloudapi.de)、接続プールのブロック期間が削除され、接続確立のエラーはキャッシュされません。 接続オープン要求の再試行は、一時的な接続エラーのほぼすぐ後に発生します。 この変更により、Azure SQL データベースへの接続確立がすぐに再試行するされるため、クラウド対応アプリケーションのパフォーマンスが向上します。 他のすべての接続を試みる場合は、接続プールのブロック期間が引き続き適用されます。
.NET Framework 4.6.1 以前のバージョンでは、データベースへの接続時にアプリで一時的な接続エラーが発生した場合、接続はすぐに再試行されません。接続プールがエラーをキャッシュし、5 秒 ~ 1 分の間にエラーを再スローするためです。 詳しくは、「SQL Server の接続プール (ADO.NET)」をご覧ください。 この動作は、Azure SQL データベースへの接続時に問題となります。多くの場合、一時的なエラーが発生し、通常数秒内に回復します。 接続プールのブロック機能を使うと、データベースが使用可能で、アプリが数秒以内にレンダリングする必要がある場合でも、アプリは長期間データベースに接続できません。
提案される解決策
この動作が望ましくない場合は、.NET Framework 4.6.2 で導入された System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod プロパティを設定することで、接続プールのブロック期間を構成できます。 プロパティ値が System.Data.SqlClient.PoolBlockingPeriod 列挙型のメンバーである場合、次の 3 つの値のいずれかを使用できます。
System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod プロパティを AlwaysBlock に設定して、以前の動作を復元することができます。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
グローバリゼーション
Unicode 標準バージョン 8.0 のカテゴリのサポート開始
詳細
.NET Framework 4.6.2 で、Unicode データが Unicode 標準バージョン 6.3 からバージョン 8.0 にアップグレードされました。 .NET Framework 4.6.2 で Unicode 文字カテゴリを要求すると、いくつかの結果が以前の .NET Framework バージョンの結果と一致しない可能性があります。 この変更は、主にチェロキーの音節、新タイ ロ文字の母音記号および声調記号に影響します。
提案される解決策
コードを確認し、ハードコーディングされた Unicode 文字カテゴリに依存するロジックを削除/変更します。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
- Char.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(String, Int32)
セキュリティ
部分信頼のシナリオで RSACng と DSACng が再び使用可能に
詳細
CngLightup (System.Security.Cryptography.Xml.EncryptedXml などの複数の上位レベル暗号化 API で使われます) および System.Security.Cryptography.RSACng は、完全信頼に依存する場合があります。 たとえば、SecurityPermissionFlag.UnmanagedCode アクセス許可をアサートしない P/Invoke や、System.Security.Cryptography.CngKey に SecurityPermissionFlag.UnmanagedCode に対するアクセス許可要求があるコード パスなどです。 .NET Framework 4.6.2 以降では、CngLightup は可能な場合に常に System.Security.Cryptography.RSACng に切り替えるために使われました。 その結果、System.Security.Cryptography.Xml.EncryptedXml を正常に使っていた部分信頼アプリが、失敗して SecurityException 例外をスローするようになりました。この変更では、CngLightup を使っているすべての関数が必要なアクセス許可を持つように、必要なアサートが追加されます。
推奨事項
.NET Framework 4.6.2 でのこの変更により部分信頼アプリに悪影響があった場合は、.NET Framework 4.7.1 にアップグレードしてください。
名前 | 値 |
---|---|
スコープ | エッジ |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
- DSACng(CngKey)
- DSACng.Key
- DSACng.LegalKeySizes
- DSACng.CreateSignature(Byte[])
- DSACng.VerifySignature(Byte[], Byte[])
- RSACng(CngKey)
- RSACng.Key
- RSACng.Decrypt(Byte[], RSAEncryptionPadding)
- RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)
RSACng.VerifyHash で検証が失敗した場合に False が返されるようになった
詳細
.NET Framework 4.6.2 以降では、署名自体の形式が正しくない場合、このメソッドでは False が返されます。 今すぐ false を返しますの検証に失敗しました。 .NET Framework 4.6 および 4.6.1 では、メソッドによってスローされる、System.Security.Cryptography.CryptographicException署名自体が正しくフォーマットされている場合。
推奨事項
検証が失敗し、メソッドで False が返される場合は、代わりにその実行が System.Security.Cryptography.CryptographicException の処理に依存するコードが実行される必要があります。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
SignedXml と EncryptedXml の互換性に影響する変更点
詳細
.NET Framework 4.6.2 では、System.Security.Cryptography.Xml.SignedXml および System.Security.Cryptography.Xml.EncryptedXml のセキュリティ修正プログラムにより、実行時の動作が変わります。 例:
- ドキュメントに
id
属性が同じ値の複数の要素があり、署名でそれらの要素の 1 つが署名のルートとして指定されている場合、ドキュメントは無効と見なされるようになります。 - 参照で非正規 XPath 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。
- 参照で非正規 XSLT 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。
- 外部リソースのデタッチされた署名を利用しているプログラムは、利用できなくなります。
提案される解決策
ドキュメントの受信者が処理できない可能性があるため、開発者は XmlDsigXsltTransform と XmlDsigXsltTransform の使用、および Transform の派生型を確認することが必要な場合があります。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
- System.Security.Cryptography.Xml.Transform
- System.Security.Cryptography.Xml.XmlDsigXPathTransform
- System.Security.Cryptography.Xml.XmlDsigXsltTransform
Windows Communication Foundation (WCF)
WCF TransportDefaults からの Ssl3 の削除
説明
トランスポート セキュリティで NetTcp を使用し、証明書の資格情報の種類を使用する場合、SSL 3 プロトコルは、安全な接続のネゴシエーションに使用される既定のプロトコルではなくなりました。 TLS 1.0 は常に NetTcp のプロトコル一覧に含まれているため、ほとんどの場合、既存のアプリには影響はないと考えられます。 既存のすべてのクライアントは TLS 1.0 以降を使用して接続をネゴシエートできるようになりました。
提案される解決策
Ssl3 が必要な場合は、以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に Ssl3 を追加します。
- SslProtocols
- SslProtocols
- <netTcpBinding> の <transport>
- <sslStreamSecurity>
名前 | 値 |
---|---|
スコープ | エッジ |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
Windows Presentation Foundation (WPF)
TextBlock コントロールの親の IsEnabled プロパティの変更がすべての子コントロールに影響する
詳細
.NET Framework 4.6.2、変更以降のSystem.Windows.UIElement.IsEnabledの親のプロパティ、System.Windows.Controls.TextBlockコントロール (ハイパーリンクやボタンなど) などの子コントロールに影響を与える、System.Windows.Controls.TextBlockコントロール。 .NET Framework 4.6.1 以前のバージョンで、内部コントロール、System.Windows.Controls.TextBlockの状態を常に反映されませんでした、System.Windows.UIElement.IsEnabledのプロパティ、System.Windows.Controls.TextBlock親。
提案される解決策
[なし] : この変更は、System.Windows.Controls.TextBlock コントロール内部のコントロールに期待される動作に準拠しています。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
CoerceIsSelectionBoxHighlighted
詳細
System.Windows.Controls.ComboBox とそのデータ ソースに関連するアクションの特定のシーケンスで System.NullReferenceException が発生する可能性があります。
提案される解決策
可能な場合は、.NET Framework 4.6.2 にアップグレードします。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6 |
種類 | ランタイム |
影響を受ける API
DataGridCellsPanel.BringIndexIntoView で ArgumentOutOfRangeException がスローされる
詳細
列の仮想化は有効になっているが、列の幅がまだ決定されていない場合、ScrollIntoView(Object) は非同期で動作します。 非同期動作が発生する前に列が削除されると、System.ArgumentOutOfRangeException が発生する場合があります。
推奨事項
以下のいずれかを実行してください。
- .NET Framework 4.7 にアップグレードします。
- .NET Framework 4.6.2 の最新のサービス パッチをインストールします。
- ScrollIntoView(Object) に対する非同期応答が完了するまでは列を削除しないようにする。
名前 | 値 |
---|---|
スコープ | エッジ |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
水平方向スクロールと仮想化
詳細
この変更は、メインのスクロール方向と直交する方向で独自に仮想化を行う System.Windows.Controls.ItemsControl に適用されます (代表的な例は、EnableColumnVirtualization="True" である System.Windows.Controls.DataGrid です)。 特定の水平方向スクロール操作の結果が変更され、比較可能な垂直操作の結果により類似した、より直感的な結果が生成されるようになりました。
操作には "ここにスクロール" や "右端" などがあり、水平スクロール バーを右クリックすると表示されるメニューから名前を使用することができます。 これらの両方でオフセット候補が計算され、SetHorizontalOffset(Double) が呼び出されます。
新しいオフセットにスクロールすると、"ここ" または "右端" の概念が変更されている場合があります。これは、新しく非仮想化されたコンテンツで System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth の値が変更されたためです。
.NET Framework 4.6.2 より前では、もう "ここ" や "右端" にない場合でも、スクロール操作では単にオフセット候補を使用します。 その結果、スクロールつまみの "バウンス" などの効果が得られます。たとえば、 たとえば、System.Windows.Controls.DataGrid で ExtentWidth=1000 および Width=200 であるものとします。 "右端" へのスクロールでは、1000 - 200 = 800 の候補オフセットを使用します。 そのオフセットへのスクロール時に、新しい列が非仮想化されます。これらの列が非常に広いため、System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth を 2000 に変更したとします。 スクロールは HorizontalOffset=800 で終了し、つまみはスクロールバーの中央付近 (正確には 800/2000 = 40%) に "戻り" ます。
変更するには、この状況が発生したら新しいオフセット候補を再計算してやり直します (垂直方向スクロールの動作は既にこのようになっています)。
この変更により、エンド ユーザーにはより予測可能で直感的なエクスペリエンスが提供されるようになりますが、水平方向スクロール後の System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset の正確な値に依存するアプリに影響する可能性もあります。これは、エンド ユーザーによる呼び出しであるか、SetHorizontalOffset(Double) の明示的な呼び出しであるかに関係ありません。
推奨事項
System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset の予測値を使用するアプリを、非仮想化により System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth が変更される可能性のある水平方向スクロール後の実際の値 (および System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth の値) を取得するように変更する必要があります。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.6.2 |
種類 | ランタイム |
影響を受ける API
Items.Clear で SelectedItems から重複部分が削除されない
説明
セレクター (複数選択が有効になっている) の System.Windows.Controls.Primitives.MultiSelector.SelectedItems コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。 データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、System.Windows.Controls.Primitives.MultiSelector.SelectedItems からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。 さらに、System.Windows.Controls.Primitives.MultiSelector.SelectedItems (SelectedItems.Clear() など) を引き続き使用すると、System.ArgumentException などの問題が発生する可能性があります。これは、System.Windows.Controls.Primitives.MultiSelector.SelectedItems に、データ ソース内にはもう存在しない項目が含まれているためです。
提案される解決策
可能であれば、.NET Framework 4.6.2 にアップグレードします。
名前 | 値 |
---|---|
スコープ | マイナー |
バージョン | 4.5 |
種類 | ランタイム |
影響を受ける 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
ローカライズされたビルドで RibbonGroup の背景が透明に設定される
詳細
ローカライズされたビルドの System.Windows.Controls.Ribbon.RibbonGroup の背景が常に透明のブラシで塗りつぶされており、UI の操作性が低下していました。 これは、.NET Framework 4.7 WPF 修正プログラムで修正されます。System.Windows.Controls.Ribbon.RibbonGroup のローカライズされたリソースが更新され、正しいブラシが確実に選択されるようになります。
提案される解決策
.NET Framework 4.7 にアップグレードします
名前 | 値 |
---|---|
スコープ | エッジ |
バージョン | 4.6.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 分析では検出できません。
.NET