將移轉變更從 .NET Framework 4.0 重定為 4.5.2Retargeting Changes for Migration from .NET Framework 4.0 to 4.5.2

如果您想從 .NET Framework 4.0 移轉至 4.5.2,請檢閱下列主題中可能會影響應用程式的應用程式相容性問題:If you are migrating from the .NET Framework 4.0 to 4.5.2, review the following topics for application compatibility issues that may affect your app:

ADO.NETADO.NET

DbParameter.Precision 和 DbParameter.Scale 現在是公用虛擬成員DbParameter.Precision and DbParameter.Scale are now public virtual members

詳細資料Details

PrecisionScale 會當做公用虛擬屬性來實作。Precision and Scale are implemented as public virtual properties. 這些屬性取代對應的明確介面實作 IDbDataParameter.PrecisionIDbDataParameter.ScaleThey replace the corresponding explicit interface implementations, IDbDataParameter.Precision and IDbDataParameter.Scale.

建議Suggestion

重建 ADO.NET 資料庫提供者時,這些差異會要求將 'override' 關鍵字套用至 Precision 和 Scale 屬性。When re-building an ADO.NET database provider, these differences will require the 'override' keyword to be applied to the Precision and Scale properties. 只有在重建元件時才需要這樣做;現有的二進位檔將繼續運作。This is only needed when re-building the components; existing binaries will continue to work.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ASP.NETASP.NET

MachineKey.Encode 和 MachineKey.Decode 方法現在已淘汰MachineKey.Encode and MachineKey.Decode methods are now obsolete

詳細資料Details

這些方法現在已經過時。These methods are now obsolete. 編譯呼叫這些方法的程式碼會產生編譯器警告。Compilation of code that calls these methods produces a compiler warning.

建議Suggestion

建議的替代方式為 Protect(Byte[], String[])Unprotect(Byte[], String[])The recommended alternatives are Protect(Byte[], String[]) and Unprotect(Byte[], String[]). 或者,您也可以隱藏建置警告,或使用舊版編譯器以避免出現警告。Alternatively, the build warnings can be suppressed, or they can be avoided by using an older compiler. 這些 API 仍受到支援。The APIs are still supported.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

使用 AntiXSSEncoder 時,多行 ASP.NET 文字方塊間距已變更Multi-line ASP.NET TextBox spacing changed when using AntiXSSEncoder

詳細資料Details

在 .NET Framework 4.0 中,如果使用 System.Web.Security.AntiXss.AntiXssEncoder,則會在回傳時,於多行文字方塊的行間插入額外幾行。In .NET Framework 4.0, extra lines were inserted between lines of a multi-line text box on postback, if using the System.Web.Security.AntiXss.AntiXssEncoder. 在 .NET Framework 4.5 中,不會包含這些額外的分行符號,但前提是 Web 應用程式是以 .NET Framework 4.5 為目標In .NET Framework 4.5, those extra line breaks are not included, but only if the web app is targeting .NET Framework 4.5

建議Suggestion

請注意,重定目標為 .NET Framework 4.5 的 4.0 版 Web 應用程式可能已改善多行文字方塊,不再插入額外的分行符號。Be aware that 4.0 web apps retargeted to .NET Framework 4.5 may have multi-line text boxes improved to no longer insert extra line breaks. 如果不想這麼做,在 .NET Framework 4.5 上執行的應用程式可藉由將目標設為 .NET Framework 4.0 來保留舊版行為。If this is not desirable, the app can have the old behavior when running on .NET Framework 4.5 by targeting the .NET Framework 4.0.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

WebUtility.HtmlEncode 和 WebUtility.HtmlDecode 正確地反覆存取 BMPWebUtility.HtmlEncode and WebUtility.HtmlDecode round-trip BMP correctly

詳細資料Details

若是目標為 .NET Framework 4.5 的應用程式,當 Basic Multilingual Plane (BMP) 以外的字元傳遞至 HtmlDecode(String) 方法時,會正確地來回轉譯。For applications that target the .NET Framework 4.5, characters that are outside the Basic Multilingual Plane (BMP) round-trip correctly when they are passed to the HtmlDecode(String) methods.

建議Suggestion

這項變更應該不會影響目前的應用程式,但若要還原原始行為,請將 targetFramework 元素的屬性設定 <httpRuntime> 為 "4.5" 以外的字串。This change should have no effect on current applications, but to restore the original behavior, set the targetFramework attribute of the <httpRuntime> element to a string other than "4.5". 您也可以設定 unicodeEncodingConformance 組態項目的 unicodeDecodingConformance<webUtility> 屬性,以與目標 .NET Framework 版本不相關的方式控制這個行為。You can also set the unicodeEncodingConformance and unicodeDecodingConformance attributes of the <webUtility> configuration element to control this behavior independently of the targeted version of the .NET Framework.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ClickOnceClickOnce

透過 ClickOnce 發行的應用程式,這些應用程式使用可能會在 Windows 2003 上失敗的 SHA-256 程式碼簽署憑證Apps published with ClickOnce that use a SHA-256 code-signing certificate may fail on Windows 2003

詳細資料Details

這個可執行檔使用 SHA256 簽署。The executable is signed with SHA256. 之前,不論程式碼簽署憑證為 SHA-1 或 SHA-256,都會使用 SHA1 簽署。Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. 這適用於:This applies to:

  • 使用 Visual Studio 2012 (含) 以後版本建置的所有應用程式。All applications built with Visual Studio 2012 or later.
  • 使用 Visual Studio 2010 (含) 以前版本,在具有 .NET Framework 4.5 的系統上建置應用程式。Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present. 此外,如果有 .NET Framework 4.5 (含) 以後版本,也會針對 SHA-256 憑證使用 SHA-256 來簽署 ClickOnce 資訊清單,而不論編譯的 .NET Framework 版本為何。In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.

建議Suggestion

對簽署 ClickOnce 可執行檔所做的變更只會影響 Windows Server 2003 系統;這些變更需要安裝 KB 938397。The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed. 對使用 SHA-256 簽署資訊清單所做的變更還會引進 .NET Framework 4.5 (含) 以後版本的執行階段相依性,即使應用程式是以 .NET Framework 4.0 (含) 以前版本為目標亦然。The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4.0 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

核心Core

Foreach 迭代器變數的範圍現在會設定為在反覆項目內,因此關閉擷取語意不同 (在 C#5 中)Foreach iterator variable is now scoped within the iteration, so closure capturing semantics are different (in C#5)

詳細資料Details

從 C# 5 (Visual Studio 2012) 開始,foreach 迭代器變數的範圍會設定為在反覆項目內。Beginning with C# 5 (Visual Studio 2012), foreach iterator variables are scoped within the iteration. 如果程式碼之前需要這些變數才不會包含在 foreach 的關閉中,這可能會導致中斷。This can cause breaks if code was previously depending on the variables to not be included in the foreach's closure. 這項變更的徵兆是傳遞至委派的迭代器變數會視為建立委派時所具有的值,而不是叫用委派時所具有的值。The symptom of this change is that an iterator variable passed to a delegate is treated as the value it has at the time the delegate is created, rather than the value it has at the time the delegate is invoked.

建議Suggestion

在理想情況下,您應該更新程式碼,以確保此新的編譯器行為。Ideally, code should be updated to expect the new compiler behavior. 如果需要舊版語意,您可以將此迭代器變數取代成明確放在迴圈範圍外的不同變數。If the old semantics are required, the iterator variable can be replaced with a separate variable which is explicitly placed outside of the loop's scope.

名稱Name Value
影響範圍Scope 主要Major
版本Version 4.54.5
類型Type 正在重定目標Retargeting

IAsyncResult.CompletedSynchronously 屬性必須正確,產生的工作才能完成IAsyncResult.CompletedSynchronously property must be correct for the resulting task to complete

詳細資料Details

呼叫 TaskFactory.FromAsync 時,CompletedSynchronously 屬性的實作必須正確,產生的工作才能完成。When calling TaskFactory.FromAsync, the implementation of the CompletedSynchronously property must be correct for the resulting task to complete. 也就是說,只有在實作同步完成時,屬性才必須傳回 true。That is, the property must return true if, and only if, the implementation completed synchronously. 以往不會檢查屬性。Previously, the property was not checked.

建議Suggestion

如果 System.IAsyncResult 實作只在工作同步完成時,才針對 System.IAsyncResult.CompletedSynchronously 屬性正確地傳回 true,則不會觀察到中斷情況。If System.IAsyncResult implementations correctly return true for the System.IAsyncResult.CompletedSynchronously property only when a task completed synchronously, then no break will be observed. 使用者應檢閱其擁有的 System.IAsyncResult 實作 (如果有的話),以確保正確評估工作是否同步完成。Users should review System.IAsyncResult implementations they own (if any) to ensure that they correctly evaluate whether a task completed synchronously or not.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

修改清單項目時,List<T>.ForEach 可能會擲回例外狀況List<T>.ForEach can throw exception when modifying list item

詳細資料Details

從 .NET Framework 4.5 開始,如果呼叫集合中有任何項目遭到修改,ForEach(Action<T>) 列舉程式將會擲回 System.InvalidOperationException 例外狀況。Beginning in .NET Framework 4.5, a ForEach(Action<T>) enumerator will throw an System.InvalidOperationException exception if an element in the calling collection is modified. 之前,這不會擲回例外狀況,但可能會造成競爭情形。Previously, this would not throw an exception but could lead to race conditions.

建議Suggestion

在理想情況下,您應該修正程式碼,不要在列舉其項目時修改清單,因為這絕不是安全的作業。Ideally, code should be fixed to not modify lists while enumerating their elements because that is never a safe operation. 不過,若要還原成舊版行為,應用程式可以將目標設為 .NET Framework 4.0。To revert to the previous behavior, though, an app may target .NET Framework 4.0.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

ObsoleteAttribute 會在 WinMD 案例中匯出為 ObsoleteAttribute 和 DeprecatedAttributeObsoleteAttribute exports as both ObsoleteAttribute and DeprecatedAttribute in WinMD scenarios

詳細資料Details

當您建立 Windows 中繼資料庫 (.winmd 檔案) 時,System.ObsoleteAttribute 屬性會匯出為 System.ObsoleteAttributeWindows.Foundation.DeprecatedAttributeWhen you create a Windows Metadata library (.winmd file), the System.ObsoleteAttribute attribute is exported as both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute.

建議Suggestion

重新編譯使用 System.ObsoleteAttribute 屬性的現有來源程式碼,可能會在從 C++/CX 或 JavaScript 使用該程式碼時產生警告。我們不建議您在受控組件中同時套用 System.ObsoleteAttributeWindows.Foundation.DeprecatedAttribute,這樣可能會導致建置警告。Recompilation of existing source code that uses the System.ObsoleteAttribute attribute may generate warnings when consuming that code from C++/CX or JavaScript.We do not recommend applying both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute to code in managed assemblies; it may result in build warnings.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

System.Uri 剖析遵守 RFC 3987System.Uri parsing adheres to RFC 3987

詳細資料Details

URI 剖析在 .NET Framework 4.5 中已做了幾項變更。URI parsing has changed in several ways in .NET Framework 4.5. 不過請注意,這些變更只會影響以 .NET Framework 4.5 為目標的程式碼。Note, however, that these changes only affect code targeting .NET Framework 4.5. 如果某個二進位檔是以 .NET Framework 4.0 為目標,則會遵守舊版行為。If a binary targets .NET Framework 4.0, the old behavior will be observed. .NET Framework 4.5 中的 URI 剖析變更包括:Changes to URI parsing in .NET Framework 4.5 include:

  • URI 剖析將會根據 RFC 3987 中最新的 IRI 規則來執行正規化和字元檢查。URI parsing will perform normalization and character checking according to the latest IRI rules in RFC 3987.
  • 只會在 URI 的主機部分執行 Unicode 正規化格式 C。Unicode normalization form C will only be performed on the host portion of the URI.
  • 無效的 mailto: URI 現在會造成例外狀況。Invalid mailto: URIs will now cause an exception.
  • 現在會保留路徑線段結尾的後置點。Trailing dots at the end of a path segment are now preserved.
  • file:// URI 不會逸出 ? 字元。file:// URIs do not escape the ? character.
  • 不支援 Unicode 控制字元 U+0080U+009FUnicode control characters U+0080 through U+009F are not supported.
  • 逗號字元 ,%2c 不會自動設為未逸出。Comma characters , or %2c are not automatically unescaped.

建議Suggestion

如果需要舊版 .NET Framework 4.0 URI 剖析語意 (通常不需要),藉由設定 .NET Framework 4.0 目標即可使用。If the old .NET Framework 4.0 URI parsing semantics are necessary (they often aren't), they can be used by targeting .NET Framework 4.0. 您可以在組件上使用 System.Runtime.Versioning.TargetFrameworkAttribute,或透過 Visual Studio 專案系統 UI 的 [專案屬性] 頁面來完成此作業。This can be accomplished by using a System.Runtime.Versioning.TargetFrameworkAttribute on the assembly, or through Visual Studio's project system UI in the 'project properties' page.

名稱Name Value
影響範圍Scope 主要Major
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

System.Uri.IsWellFormedUriString 方法針對第一個區段中有冒號字元的相對 URI 會傳回 falseSystem.Uri.IsWellFormedUriString method returns false for relative URIs with a colon char in first segment

詳細資料Details

從 .NET Framework 4.5 開始,IsWellFormedUriString(String, UriKind) 會將第一個區段中具有 : 的相對 URI 視為格式不正確。Beginning with the .NET Framework 4.5, IsWellFormedUriString(String, UriKind) will treat relative URIs with a : in their first segment as not well formed. 這是 .NET Framework 4.0 System.Uri.IsWellFormedUriString(String, UriKind) 行為的變更,以符合 RFC3986。This is a change from System.Uri.IsWellFormedUriString(String, UriKind) behavior in the .NET Framework 4.0 that was made to conform to RFC3986.

建議Suggestion

這項變更 (就像許多其他的 URI 變更一樣) 只會影響以 .NET Framework 4.5 (或更新版本) 為目標的應用程式。This change (like many other URI changes) will only affect applications targeting the .NET Framework 4.5 (or later). 若要繼續使用舊的行為,請將應用程式設為以 .NET Framework 4.0 為目標。To keep using the old behavior, target the app against the .NET Framework 4.0. 或者,在呼叫 System.Uri.IsWellFormedUriString(String, UriKind) 前掃描 URI,尋找 : 字元,如果您偏好舊的行為,則請移除字元以進行驗證。Alternatively, scan URI's prior to calling System.Uri.IsWellFormedUriString(String, UriKind) looking for : characters that you may want to remove for validation purposes, if the old behavior is desirable.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Entity FrameworkEntity Framework

如果使用 EntityDeploySplit 或 EntityClean 工作,以 Visual Studio 2013 建置 Entity Framework edmx 可能會失敗,並出現錯誤 MSB4062Building an Entity Framework edmx with Visual Studio 2013 can fail with error MSB4062 if using the EntityDeploySplit or EntityClean tasks

詳細資料Details

MSBuild 12.0 工具 (隨附於 Visual Studio 2013) 已變更 MSBuild 檔案位置,導致舊版 Entity Framework 的目標檔案無效。MSBuild 12.0 tools (included in Visual Studio 2013) changed MSBuild file locations, causing older Entity Framework targets files to be invalid. 結果是 EntityDeploySplitEntityClean 工作會失敗,因為找不到 Microsoft.Data.Entity.Build.Tasks.dllThe result is that EntityDeploySplit and EntityClean tasks fail because they are unable to find Microsoft.Data.Entity.Build.Tasks.dll. 請注意,造成此中斷的原因是工具組 (MSBuild/VS) 變更,而不是 .NET Framework 變更。Note that this break is because of a toolset (MSBuild/VS) change, not because of a .NET Framework change. 只有在升級開發人員工具時才會發生此情況,若只是升級 .NET Framework 則不會發生。It will only occur when upgrading developer tools, not when merely upgrading the .NET Framework.

建議Suggestion

Entity Framework 的目標檔案已修正,從 .NET Framework 4.6 開始,可搭配新的 MSBuild 配置使用。Entity Framework targets files are fixed to work with the new MSBuild layout beginning in the .NET Framework 4.6. 升級至該版 Framework 將會修正此問題。Upgrading to that version of the Framework will fix this issue. 或者,您也可以使用此因應措施來直接修補目標檔案。Alternatively, this workaround can be used to patch the targets files directly.

名稱Name Value
影響範圍Scope 主要Major
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

Entity Framework 版本必須符合 .NET Framework 版本Entity Framework version must match the .NET Framework version

詳細資料Details

Entity Framework (EF)版本應該與 .NET Framework 版本相符。The Entity Framework (EF) version should be matched with the .NET Framework version. 建議針對 .NET Framework 4.5 使用 Entity Framework 5。Entity Framework 5 is recommended for .NET Framework 4.5. .NET Framework 4.5 專案中,已知 EF 4.x 有一些 System.ComponentModel.DataAnnotations 相關問題。There are some known issues with EF 4.x in a .NET Framework 4.5 project around System.ComponentModel.DataAnnotations. 在 .NET Framework 4.5 中,這些已移至不同的元件,因此在決定要使用的注釋時,會發生問題。In .NET Framework 4.5, these were moved to a different assembly, so there are issues determining which annotations to use.

建議Suggestion

針對 .NET Framework 4.5 升級至 Entity Framework 5Upgrade to Entity Framework 5 for .NET Framework 4.5

名稱Name Value
影響範圍Scope 主要Major
版本Version 4.54.5
類型Type 正在重定目標Retargeting

MSBuildMSBuild

ResolveAssemblyReference 工作現在會發出警告,指出相依於錯誤的架構ResolveAssemblyReference task now warns of dependencies with the wrong architecture

詳細資料Details

這項工作會發出警告 MSB3270,指出某個參考或參考的任何一個相依性不符合應用程式的架構。The task emits a warning, MSB3270, which indicates that a reference or any of its dependencies does not match the app's architecture. 例如,如果使用 AnyCPU 選項編譯的應用程式包含 x86 參考,則會發生此情況。For example, this occurs if an app that was compiled with the AnyCPU option includes an x86 reference. 這類情況會導致應用程式在執行階段失敗 (在本範例中,如果應用程式部署為 x64 處理序)。Such a scenario could result in an app failure at run time (in this case, if the app is deployed as an x64 process).

建議Suggestion

影響可分為下列兩方面:There are two areas of impact:

  • 重新編譯會產生在舊版 MSBuild 下編譯應用程式時未顯示的警告。Recompilation generates warnings that did not appear when the app was compiled under a previous version of MSBuild. 不過,由於此警告識別執行階段失敗的可能來源,因此應該加以調查和解決。However, because the warning identifies a possible source of runtime failure, it should be investigated and addressed.
  • 如果將警告視為錯誤,應用程式將無法編譯。If warnings are treated as errors, the app will fail to compile.
名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

Visual Basic .NETVisual Basic .NET

VB.NET 不再支援 System.Windows API 的部分命名空間限定性條件VB.NET no longer supports partial namespace qualification for System.Windows APIs

詳細資料Details

從 .NET Framework 4.5.2 開始,VB.NET 專案無法以部分限定的命名空間來指定 System.Windows API。Beginning in .NET Framework 4.5.2, VB.NET projects cannot specify System.Windows APIs with partially-qualified namespaces. 例如,參考 Windows.Forms.DialogResult 將會失敗。For example, referring to Windows.Forms.DialogResult will fail. 相反地,程式碼必須參考完整名稱 (DialogResult),或匯入特定命名空間並只參考 System.Windows.Forms.DialogResultInstead, code must refer to the fully qualified name (DialogResult) or import the specific namespace and refer simply to System.Windows.Forms.DialogResult.

建議Suggestion

您應該更新程式碼,以簡單名稱 (並匯入相關命名空間) 或完整名稱參考 System.Windows API。Code should be updated to refer to System.Windows APIs either with simple names (and importing the relevant namespace) or with fully qualified names.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.5.24.5.2
類型Type 正在重定目標Retargeting

Windows FormsWindows Forms

DataObject.GetData 現在會以 UTF-8 形式來擷取資料DataObject.GetData now retrieves data as UTF-8

詳細資料Details

若為以 .NET Framework 4.5.1 為目標的應用程式,或者在 .NET Framework 4.5.1 或舊版上執行的應用程式,DataObject.GetData 會以 ASCII 字串形式來擷取 HTML 格式的資料。For apps that target the .NET Framework 4 or that run on the .NET Framework 4.5.1 or earlier versions, DataObject.GetData retrieves HTML-formatted data as an ASCII string. 因此,非 ASCII 字元 (ASCII 碼大於 0x7F 的字元) 會以兩個隨機字元表示。As a result, non-ASCII characters (characters whose ASCII codes are greater than 0x7F) are represented by two random characters.

若為以 .NET Framework 4.5 或更新版本為目標並且在 .NET Framework 4.5.2 上執行的應用程式,DataObject.GetData 會以 UTF-8 形式來擷取 HTML 格式的資料,以正確地表示大於 0x7F 的字元。For apps that target the .NET Framework 4.5 or later and run on the .NET Framework 4.5.2, DataObject.GetData retrieves HTML-formatted data as UTF-8, which represents characters greater than 0x7F correctly.

建議Suggestion

如果針對 HTML 格式字串的編碼問題實作了因應措施 (例如將從 [剪貼簿] 擷取的 HTML 字串傳遞至 System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32) 以明確將其編碼),並將目標從應用程式 4 版重定為 4.5 版,則應該移除該因應措施。如果因故需要舊版行為,應用程式可以將目標設為 .NET Framework 4.0 來取得該行為。If you implemented a workaround for the encoding problem with HTML-formatted strings (for example, by explicitly encoding the HTML string retrieved from the Clipboard by passing it to System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) and you're retargeting your app from version 4 to 4.5, that workaround should be removed.If the old behavior is needed for some reason, the app can target the .NET Framework 4.0 to get that behavior.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.5.24.5.2
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

EncoderParameter ctor 已淘汰EncoderParameter ctor is obsolete

詳細資料Details

EncoderParameter(Encoder, Int32, Int32, Int32, Int32) 建構函式現在已淘汰,如果使用,就會產生建置警告。The EncoderParameter(Encoder, Int32, Int32, Int32, Int32) constructor is obsolete now and will introduce build warnings if used.

建議Suggestion

雖然 EncoderParameter(Encoder, Int32, Int32, Int32, Int32) 建構函式會繼續運作,但應改用下列建構函式,以避免使用 .NET Framework 4.5 工具重新編譯程式碼時出現已淘汰的建置警告:EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr)Although the EncoderParameter(Encoder, Int32, Int32, Int32, Int32)constructor will continue to work, the following constructor should be used instead to avoid the obsolete build warning when re-compiling code with .NET Framework 4.5 tools: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

不支援具有非公用 setter 之屬性的雙向資料繫結Two-way data-binding to a property with a non-public setter is not supported

詳細資料Details

嘗試將資料繫結至不含公用 setter 的屬性,是之前從未支援過的情況。Attempting to data bind to a property without a public setter has never been a supported scenario. 從 .NET Framework 4.5.1 開始,這種情況將會擲回 System.InvalidOperationExceptionBeginning in the .NET Framework 4.5.1, this scenario will throw an System.InvalidOperationException. 請注意,只有專門以 .NET Framework 4.5.1 為目標的應用程式才會擲回此新的例外狀況。Note that this new exception will only be thrown for apps that specifically target the .NET Framework 4.5.1. 如果應用程式是以 .NET Framework 4.5 為目標,則會允許此呼叫。If an app targets the .NET Framework 4.5, the call will be allowed. 如果應用程式未以特定 .NET Framework 版本為目標,則會將繫結視為單向。If the app does not target a particular .NET Framework version, the binding will be treated as one-way.

建議Suggestion

您應該更新應用程式以使用單向繫結,或以公用方式公開屬性的 setter。The app should be updated to either use one-way binding, or expose the property's setter publicly. 此外,以 .NET Framework 4.5 為目標也會使應用程式展示舊版行為。Alternatively, targeting the .NET Framework 4.5 will cause the app to exhibit the old behavior.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.5.14.5.1
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

WPF TextBox.Text 可能與資料繫結不同步WPF TextBox.Text can be out-of-sync with databinding

詳細資料Details

在某些情況下,如果屬性在資料繫結寫入作業期間經過修改,Text 屬性會反映資料繫結屬性值先前的值。In some cases, the Text property reflects a previous value of the databound property value if the property is modified during a databinding write operation.

建議Suggestion

這應該不會產生負面影響。This should have no negative impact. 不過,您可以藉由將 KeepTextBoxDisplaySynchronizedWithTextProperty 屬性設為 false 還原舊有行為。However, you can restore the previous behavior by setting the KeepTextBoxDisplaySynchronizedWithTextProperty property to false.

名稱Name Value
影響範圍Scope EdgeEdge
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

新的 (模稜兩可的) Dispatcher.Invoke 多載可能會導致不同的行為New (ambiguous) Dispatcher.Invoke overloads could result in different behavior

詳細資料Details

.NET Framework 4.5 將包含 Action 類型參數的多載新增至 Dispatcher.InvokeThe .NET Framework 4.5 adds new overloads to Dispatcher.Invoke that include a parameter of type Action. 重新編譯現有的程式碼時,編譯器可能會將呼叫解析為具有 Delegate 參數的 Dispatcher.Invoke 方法,就像呼叫具有 Action 參數的 Dispatcher.Invoke 方法。When existing code is recompiled, compilers may resolve calls to Dispatcher.Invoke methods that have a Delegate parameter as calls to Dispatcher.Invoke methods with an Action parameter. 如果將具有 Delegate 參數的 Dispatcher.Invoke 多載呼叫解析成具有 Action 參數的 Dispatcher.Invoke 多載呼叫,則可能會出現下列行為上的差異:If a call to a Dispatcher.Invoke overload with a Delegate parameter is resolved as a call to a Dispatcher.Invoke overload with an Action parameter, the following differences in behavior may occur:

建議Suggestion

若要避免模稜兩可的情況 (以及例外狀況處理或封鎖行為上的可能差異),呼叫 Dispatcher.Invoke 的程式碼可以傳遞空的 object[] 作為 Invoke 呼叫的第二個參數,以確定解析為 .NET Framework 4.0 方法多載。To avoid ambiguity (and potential differences in exception handling or blocking behaviors), code calling Dispatcher.Invoke can pass an empty object[] as a second parameter to the Invoke call to be sure of resolving to the .NET Framework 4.0 method overload.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

某些工作流程拖放 API 已淘汰Some WorkFlow drag-and-drop APIs are obsolete

詳細資料Details

此工作流程拖放 API 已淘汰;如果針對 4.5 重建應用程式,就會產生編譯器警告。This WorkFlow drag-and-drop API is obsolete and will cause compiler warnings if the app is rebuilt against 4.5.

建議Suggestion

您應該改用支援操作多個物件的新 System.Activities.Presentation.DragDropHelper API。New System.Activities.Presentation.DragDropHelper APIs that support operations with multiple objects should be used instead. 或者,您也可以隱藏建置警告,或使用舊版編譯器以避免出現警告。Alternatively, the build warnings can be suppressed or they can be avoided by using an older compiler. 這些 API 仍受到支援。The APIs are still supported.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting

受影響的 APIAffected APIs

WorkFlow 3.0 類型已淘汰WorkFlow 3.0 types are obsolete

詳細資料Details

Windows Workflow Foundation (WWF) 3.0 API (System.Workflow 命名空間中的 API) 現在已淘汰。Windows Workflow Foundation (WWF) 3.0 APIs (those from the System.Workflow namespace) are now obsolete.

建議Suggestion

您應該改用新的 WWF 4.0 API (在 System.Activities 中)。New WWF 4.0 APIs (in System.Activities) should be used instead. 您可以在這裡找到使用新 API 的範例,並在這裡取得進一步指引。An example of using the new APIs can be found here and further guidance is available here. 此外,由於仍然支援 WWF 3.0 API,因此可使用這些 API,並藉由隱藏建置階段警告或使用舊版編譯器來避免出現警告。Alternatively, since the WWF 3.0 APIs are still supported, they may be used and the build-time warning avoided either by suppressing it or by using an older compiler.

名稱Name Value
範圍Scope 主要Major
版本Version 4.54.5
類型Type 正在重定目標Retargeting

XML、XSLTXML, XSLT

XML 結構描述驗證更嚴格XML schema validation is stricter

詳細資料Details

在 .NET Framework 4.5 中,XML 結構描述驗證更為嚴格。In the .NET Framework 4.5, XML schema validation is more strict. 如果您使用 xsd:anyURI 驗證 URI (例如 mailto 通訊協定),而 URI 中有空格,則驗證會失敗。If you use xsd:anyURI to validate a URI such as a mailto protocol, validation fails if there are spaces in the URI. 在舊版 .NET Framework 中,驗證會成功。In previous versions of the .NET Framework, validation succeeded. 這項變更只會影響以 .NET Framework 4.5 為目標的應用程式。The change affects only applications that target the .NET Framework 4.5.

建議Suggestion

如果需要較鬆散的 .NET Framework 4.0 驗證,正在驗證的應用程式可以將目標設為 .NET Framework 4.0 版。If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.0 of the .NET Framework. 不過,將目標重定為 .NET Framework 4.5 時,應該完成程式碼檢閱,以確定無效的 URI (含空格) 不會作為 anyURI 資料類型的屬性值。When retargeting to .NET Framework 4.5, however, code review should be done to be sure that invalid URIs (with spaces) are not expected as attribute values with the anyURI data type.

名稱Name Value
影響範圍Scope MinorMinor
版本Version 4.54.5
類型Type 正在重定目標Retargeting