Framework 4.5 2 Download

Posted onby

May 07, 2014 Download Microsoft.NET Framework 4.5.2 (Web Installer) size: 1.1 MB Down load Microsoft.NET Framework 4.5.2 (offline installer) size: 66.755 MB After installing the update, you need to restart your computer. Microsoft.NET Framework Repair Tool.NET Version Detector, Check Which Versions of.NET Framework Installed on your Computer. The.NET Framework 4.5.2 Developer Pack installs the multi-targeting pack for.NET Framework 4.5.2. Developers can build applications targeting the.NET Framework 4.5.2 using either Visual Studio 2013, Visual Studio 2012 or third party IDEs.

  1. Framework 5.0 Download
  2. Net Framework 4.5 2 Download Filehippo
  3. Microsoft .net Framework 4 5 2 Download
  4. Microsoft Net Framework
-->

This article provides information for developers who want to install any version of .NET Framework from .NET Framework 4.5 to .NET Framework 4.8 with their apps.

You can download the redistributable packages and language packs for .NET Framework from the download pages:

Important

7/10 (293 votes) - Download.NET Framework 4.5 Free.NET Framework 4.5 is a step forward in what regards to the features of the runtime environment by Microsoft. Download.NET Framework 4.5 for free. With each day that goes by, the.NET Framework runtime environment becomes an even more. May 06, 2014 The Microsoft.NET Framework 4.5.2 is a highly compatible, in-place update to the Microsoft.NET Framework 4, Microsoft.NET Framework 4.5 and Microsoft.NET Framework 4.5.1. The web installer is a small package that automatically determines and downloads only the components applicable for a particular platform.

.NET Framework content previously digitally signed using certificates that use the SHA1 algorithm, will be retired in order to support evolving industry standards.

The following versions of .NET Framework will reach end-of-support on April 26, 2022: 4.5.2, 4.6, and 4.6.1. After this date, security fixes, updates, and technical support for these versions will no longer be provided.

If you're using .NET Framework 4.5.2, 4.6, or 4.6.1, update your deployed runtime to a more recent version, such as .NET Framework 4.6.2, before April 26, 2022 in order to continue to receive updates and technical support.

Updated SHA2 signed installers will be available for .NET Framework 3.5 SP1, and 4.6.2 through 4.8. For more information, see the SHA1 retirement plan, the .NET 4.5.2, 4.6, and 4.6.1 lifecycle update blog post, and the FAQ.

Important notes:

  • Versions of .NET Framework from .NET Framework 4.5.1 through .NET Framework 4.8 are in-place updates to .NET Framework 4.5, which means they use the same runtime version, but the assembly versions are updated and include new types and members.

  • .NET Framework 4.5 and later versions are built incrementally on .NET Framework 4. When you install .NET Framework 4.5 or later versions on a system that has .NET Framework 4 installed, the version 4 assemblies are replaced with newer versions.

  • If you are referencing a Microsoft out-of-band package in your app, the assembly will be included in the app package.

  • You must have administrator privileges to install .NET Framework 4.5 or later versions.

  • .NET Framework 4.5 is included in Windows 8 and Windows Server 2012, so you don't have to deploy it with your app on those operating systems. Similarly, .NET Framework 4.5.1 is included in Windows 8.1 and Windows Server 2012 R2. .NET Framework 4.5.2 isn't included in any operating systems. .NET Framework 4.6 is included in Windows 10, .NET Framework 4.6.1 is included in Windows 10 November Update, and .NET Framework 4.6.2 is included in Windows 10 Anniversary Update. .NET Framework 4.7 is included in Windows 10 Creators Update, .NET Framework 4.7.1 is included in Windows 10 Fall Creators Update, and .NET Framework 4.7.2 is included in Windows 10 October 2018 Update and Windows 10 April 2018 Update. .NET Framework 4.8 is included in Windows 10 May 2019 Update and all later Windows 10 updates. For a full list of hardware and software requirements, see System Requirements.

  • Starting with .NET Framework 4.5, your users can view a list of running .NET Framework apps during setup and close them easily. This may help avoid system restarts caused by .NET Framework installations. See Reducing System Restarts.

  • Uninstalling .NET Framework 4.5 or later versions also removes pre-existing .NET Framework 4 files. If you want to go back to .NET Framework 4, you must reinstall it and any updates to it. See Installing the .NET Framework 4.

  • The .NET Framework 4.5 redistributable was updated on October 9, 2012 to correct an issue related to an improper timestamp on a digital certificate, which caused the digital signature on files produced and signed by Microsoft to expire prematurely. If you previously installed the .NET Framework 4.5 redistributable package dated August 16, 2012, we recommend that you update your copy with the latest redistributable from the .NET Framework download page. For more information about this issue, see Microsoft Security Advisory 2749655.

For information about how a system administrator can deploy the .NET Framework and its system dependencies across a network, see Deployment Guide for Administrators.

Deployment options for your app

When you're ready to publish your app to a web server or other centralized location so that users can install it, you can choose from several deployment methods. Some of these are provided with Visual Studio. The following table lists the deployment options for your app and specifies the .NET Framework redistributable package that supports each option. In addition to these, you can write a custom setup program for your app; for more information, see the section Chaining the .NET Framework Installation to Your App's Setup.

Deployment strategy for your appDeployment methods available.NET Framework redistributable to use
Install from the web- InstallAware
- InstallShield
- WiX toolset
- Manual installation
Web installer
Install from disc- InstallAware
- InstallShield
- WiX toolset
- Manual installation
Offline installer
Install from a local area network (for enterprise apps)- ClickOnceEither web installer (see ClickOnce for restrictions) or offline installer

Redistributable packages

.NET Framework is available in two redistributable packages: web installer (bootstrapper) and offline installer (stand-alone redistributable). All .NET Framework downloads are hosted on the Download .NET Framework page. The following table compares the two packages:

Web installerOffline installer
Internet connection required?YesNo
Size of downloadSmaller (includes installer for target platform only)*Larger*
Language packsIncluded**Must be installed separately, unless you use the package that targets all operating systems
Deployment methodSupports all methods:
- ClickOnce
- InstallAware
- InstallShield
- Windows Installer XML (WiX)
- Manual installation
- Custom setup (chaining)
Supports all methods:
- ClickOnce
- InstallAware
- InstallShield
- Windows Installer XML (WiX)
- Manual installation
- Custom setup (chaining)

* The offline installer is larger because it contains the components for all the target platforms. When you finish running setup, the Windows operating system caches only the installer that was used. If the offline installer is deleted after the installation, the disk space used is the same as that used by the web installer. If the tool you use (for example, InstallAware or InstallShield) to create your app's setup program provides a setup file folder that is removed after installation, the offline installer can be automatically deleted by placing it into the setup folder.

** If you're using the web installer with custom setup, you can use default language settings based on the user's Multilingual User Interface (MUI) setting, or specify another language pack by using the /LCID option on the command line. See the section Chaining by Using the Default .NET Framework UI for examples.

Deployment methods

Four deployment methods are available:

  • You can set a dependency on .NET Framework. You can specify .NET Framework as a prerequisite in your app's installation, using one of these methods:

    • Use ClickOnce deployment (available with Visual Studio)

    • Create an InstallAware project (free edition available for Visual Studio users)

    • Create an InstallShield project (available with Visual Studio)

    • Use the Windows Installer XML (WiX) toolset

  • You can ask your users to install .NET Framework manually.

  • You can chain (include) the .NET Framework setup process in your app's setup, and decide how you want to handle the .NET Framework installation experience:

    • Use the default UI. Let the .NET Framework installer provide the installation experience.

    • Customize the UI to present a unified installation experience and to monitor the .NET Framework installation progress.

These deployment methods are discussed in detail in the following sections.

Set a dependency on .NET Framework

If you use ClickOnce, InstallAware, InstallShield, or WiX to deploy your app, you can add a dependency on .NET Framework so it can be installed as part of your app.

ClickOnce deployment

ClickOnce deployment is available for projects that are created with Visual Basic and Visual C#, but it is not available for Visual C++.

In Visual Studio, to choose ClickOnce deployment and add a dependency on .NET Framework:

  1. Open the app project you want to publish.

  2. In Solution Explorer, open the shortcut menu for your project, and then choose Properties.

  3. Choose the Publish pane.

  4. Choose the Prerequisites button.

  5. In the Prerequisites dialog box, make sure that the Create setup program to install prerequisite components check box is selected.

  6. In the prerequisites list, locate and select the version of .NET Framework that you've used to build your project.

  7. Choose an option to specify the source location for the prerequisites, and then choose OK.

    If you supply a URL for the .NET Framework download location, you can specify either the .NET Framework download page or a site of your own. If you are placing the redistributable package on your own server, it must be the offline installer and not the web installer. You can only link to the web installer on the .NET Framework download page. The URL can also specify a disc on which your own app is being distributed.

  8. In the Property Pages dialog box, choose OK.

InstallAware deployment

InstallAware builds Windows app (APPX), Windows Installer (MSI), Native Code (EXE), and App-V (Application Virtualization) packages from a single source. Easily include any version of the .NET Framework in your setup, optionally customizing the installation by editing the default scripts. For example, InstallAware pre-installs certificates on Windows 7, without which .NET Framework 4.7 setup fails. For more information on InstallAware, see the InstallAware for Windows Installer website.

InstallShield deployment

InstallShield builds Windows app packages (MSIX, APPX), Windows Installer packages (MSI), and Native Code (EXE) installers. InstallShield also provides Visual Studio integration. For more information, see the InstallShield website.

Windows Installer XML (WiX) deployment

The Windows Installer XML (WiX) toolset builds Windows installation packages from XML source code. WiX supports a command-line environment that can be integrated into your build processes to build MSI and MSM setup packages. By using WiX, you can specify the .NET Framework as a prerequisite, or create a chainer to fully control the .NET Framework deployment experience. For more information about WiX, see the Windows Installer XML (WiX) toolset website.

Install .NET Framework manually

In some situations, it might be impractical to automatically install .NET Framework with your app. In that case, you can have users install .NET Framework themselves. The redistributable package is available in two packages. In your setup process, provide instructions for how users should locate and install .NET Framework.

Chain the .NET Framework installation to your app's setup

If you're creating a custom setup program for your app, you can chain (include) the .NET Framework setup process in your app's setup process. Chaining provides two UI options for the .NET Framework installation:

  • Use the default UI provided by the .NET Framework installer.

  • Create a custom UI for the .NET Framework installation for consistency with your app's setup program.

Both methods allow you to use either the web installer or the offline installer. Each package has its advantages:

  • If you use the web installer, the .NET Framework setup process will decide which installation package is required, and download and install only that package from the web.

  • If you use the offline installer, you can include the complete set of .NET Framework installation packages with your redistribution media so that your users don't have to download any additional files from the web during setup.

Chaining by using the default .NET Framework UI

To silently chain the .NET Framework installation process and let the .NET Framework installer provide the UI, add the following command to your setup program:

<.NET Framework redistributable> /q /norestart /ChainingPackage <PackageName>

For example, if your executable program is Contoso.exe and you want to silently install the .NET Framework 4.5 offline redistributable package, use the command:

dotNetFx45_Full_x86_x64.exe /q /norestart /ChainingPackage Contoso

You can use additional command-line options to customize the installation. For example:

  • To provide a way for users to close running .NET Framework apps to minimize system restarts, set passive mode and use the /showrmui option as follows:

    dotNetFx45_Full_x86_x64.exe /norestart /passive /showrmui /ChainingPackage Contoso

    This command allows Restart Manager to display a message box that gives users the opportunity to close .NET Framework apps before installing the .NET Framework.

  • If you're using the web installer, you can use the /LCID option to specify a language pack. For example, to chain the .NET Framework 4.5 web installer to your Contoso setup program and install the Japanese language pack, add the following command to your app's setup process:

    dotNetFx45_Full_setup.exe /q /norestart /ChainingPackage Contoso /LCID 1041

    If you omit the /LCID option, setup will install the language pack that matches the user's MUI setting.

    Note

    Different language packs may have different release dates. If the language pack you specify is not available at the download center, setup will install the .NET Framework without the language pack. If the .NET Framework is already installed on the user’s computer, the setup will install only the language pack.

For a complete list of options, see the Command-Line Options section.

For common return codes, see the Return Codes section.

Chaining by using a Custom UI

If you have a custom setup package, you may want to silently launch and track the .NET Framework setup while showing your own view of the setup progress. If this is the case, make sure that your code covers the following:

  • Check for .NET Framework hardware and software requirements.

  • Detect whether the correct version of the .NET Framework is already installed on the user’s computer.

    Important

    In determining whether the correct version of the .NET Framework is already installed, you should check whether your target version or a later version is installed, not whether your target version is installed. In other words, you should evaluate whether the release key you retrieve from the registry is greater than or equal to the release key of your target version, not whether it equals the release key of your target version.

  • Detect whether the language packs are already installed on the user’s computer.

  • If you want to control the deployment, silently launch and track the .NET Framework setup process (see How to: Get Progress from the .NET Framework 4.5 Installer).

  • If you’re deploying the offline installer, chain the language packs separately.

  • Customize deployment by using command-line options. For example, if you’re chaining the .NET Framework web installer, but you want to override the default language pack, use the /LCID option, as described in the previous section.

  • Troubleshoot.

Detect .NET Framework

The .NET Framework installer writes registry keys when installation is successful. You can test whether .NET Framework 4.5 or later is installed by checking the HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4Full folder in the registry for a DWORD value named Release. (Note that 'NET Framework Setup' doesn't begin with a period.) The existence of this key indicates that .NET Framework 4.5 or a later version has been installed on that computer. The value of Release indicates which version of .NET Framework is installed.

Important

Check for a value greater than or equal to the release keyword value when attempting to detect whether a specific version is present.

VersionValue of the Release DWORD
.NET Framework 4.8 installed on Windows 10 May 2020 Update and Windows 10 October 2020 Update528372
.NET Framework 4.8 installed on Windows 10 May 2019 Update and Windows 10 November 2019 Update528040
.NET Framework 4.8 installed on all OS versions other than the listed Windows 10 Update versions528049
.NET Framework 4.7.2 installed on Windows 10 April 2018 Update and on Windows Server, version 1803461808
.NET Framework 4.7.2 installed on all OS versions other than Windows 10 April 2018 Update, and Windows Server, version 1803. This includes Windows 10 October 2018 Update.461814
.NET Framework 4.7.1 installed on Windows 10 Fall Creators Update and on Windows Server, version 1709461308
.NET Framework 4.7.1 installed on all OS versions other than Windows 10 Fall Creators Update and Windows Server, version 1709461310
.NET Framework 4.7 installed on Windows 10 Creators Update460798
.NET Framework 4.7 installed on all OS versions other than Windows 10 Creators Update460805
.NET Framework 4.6.2 installed on Windows 10 Anniversary Edition and on Windows Server 2016394802
.NET Framework 4.6.2 installed on all OS versions other than Windows 10 Anniversary Edition and Windows Server 2016394806
.NET Framework 4.6.1 installed on Windows 10 November Update394254
.NET Framework 4.6.1 installed on all OS versions other than Windows 10 November Update394271
.NET Framework 4.6 installed on Windows 10393295
.NET Framework 4.6 installed on all OS versions other than Windows 10393297
.NET Framework 4.5.2379893
.NET Framework 4.5.1 installed with Windows 8.1 or Windows Server 2012 R2378675
.NET Framework 4.5.1 installed on Windows 8, Windows 7378758
.NET Framework 4.5378389

Detect language packs

You can test whether a specific language pack is installed by checking the HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4FullLCID folder in the registry for a DWORD value named Release. (Note that 'NET Framework Setup' doesn't begin with a period.) LCID specifies a locale identifier; see supported languages for a list of these.

For example, to detect whether the full Japanese language pack (LCID=1041) is installed, retrieve the following named value from the registry:

Value
KeyHKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4Full1041
EntryRelease
TypeDWORD

To determine whether the final release version of a language pack is installed for a particular version of .NET Framework from 4.5 through 4.7.2, check the value of the RELEASE key DWORD value described in the previous section, Detecting .NET Framework.

Chaining the language packs to your app setup

.NET Framework provides a set of stand-alone language pack executable files that contain localized resources for specific cultures. The language packs are available from the .NET Framework download pages:

Important

The language packs don't contain the .NET Framework components that are required to run an app. You must install .NET Framework by using the web or offline installer before you install a language pack.

Starting with .NET Framework 4.5.1, the package names take the form NDP<version>-KB<number>-x86-x64-AllOS-<culture>.exe, where version is the version number of the .NET Framework, number is a Microsoft Knowledge Base article number, and culture specifies a country/region. An example of one of these packages is NDP452-KB2901907-x86-x64-AllOS-JPN.exe. Package names are listed in the Redistributable Packages section earlier in this article.

To install a language pack with the .NET Framework offline installer, you must chain it to your app's setup. For example, to deploy .NET Framework 4.5.1 offline installer with the Japanese language pack, use the following command:

NDP451-KB2858728-x86-x64-AllOS-JPN.exe /q /norestart /ChainingPackage <ProductName>

You do not have to chain the language packs if you use the web installer; setup will install the language pack that matches the user's MUI setting. If you want to install a different language, you can use the /LCID option to specify a language pack.

For a complete list of command-line options, see the Command-Line Options section.

Troubleshooting

Return codes

The following table lists the most common return codes for the .NET Framework redistributable installer. The return codes are the same for all versions of the installer. For links to detailed information, see the next section.

Return codeDescription
0Installation completed successfully.
1602The user canceled installation.
1603A fatal error occurred during installation.
1641A restart is required to complete the installation. This message indicates success.
3010A restart is required to complete the installation. This message indicates success.
5100The user's computer does not meet system requirements.

Download error codes

See the following content:

Other error codes

See the following content:

Uninstall .NET Framework

Starting with Windows 8, you can uninstall .NET Framework 4.5 or later versions by using Turn Windows features on and off in Control Panel. In older versions of Windows, you can uninstall .NET Framework 4.5 or later versions by using Add or Remove Programs in Control Panel.

Important

For Windows 7 and earlier operating systems, uninstalling .NET Framework 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, or 4.8 doesn't restore .NET Framework 4.5 files, and uninstalling .NET Framework 4.5 doesn't restore .NET Framework 4 files. If you want to go back to the older version, you must reinstall it and any updates to it.

Appendix

Command-line options

The following table lists options that you can include when you chain the .NET Framework 4.5 redistributable to your app's setup.

OptionDescription
/CEIPConsentOverwrites the default behavior and sends anonymous feedback to Microsoft to improve future deployment experiences. This option can be used only if the setup program prompts for consent and if the user grants permission to send anonymous feedback to Microsoft.
/chainingpackagepackageNameSpecifies the name of the executable that is doing the chaining. This information is sent to Microsoft as anonymous feedback to help improve future deployment experiences.
If the package name includes spaces, use double quotation marks as delimiters; for example: /chainingpackage 'Lucerne Publishing'. For an example of a chaining package, see Getting Progress Information from an Installation Package.
/LCIDLCID
where LCID specifies a locale identifier (see supported languages)
Installs the language pack specified by LCID and forces the displayed UI to be shown in that language, unless quiet mode is set.
For the web installer, this option chain-installs the language package from the web. Note: Use this option only with the web installer.
/logfilefolderSpecifies the location of the log file. The default is the temporary folder for the process, and the default file name is based on the package. If the file extension is .txt, a text log is produced. If you specify any other extension or no extension, an HTML log is created.
/msioptionsSpecifies options to be passed for .msi and .msp items; for example: /msioptions 'PROPERTY1='Value'.
/norestartPrevents the setup program from rebooting automatically. If you use this option, the chaining app has to capture the return code and handle rebooting (see Getting Progress Information from an Installation Package).
/passiveSets passive mode. Displays the progress bar to indicate that installation is in progress, but does not display any prompts or error messages to the user. In this mode, when chained by a setup program, the chaining package must handle return codes.
/pipeCreates a communication channel to enable a chaining package to get progress.
/promptrestartPassive mode only, if the setup program requires a restart, it prompts the user. This option requires user interaction if a restart is required.
/qSets quiet mode.
/repairTriggers the repair functionality.
/serialdownloadForces the installation to happen only after the package has been downloaded.
/showfinalerrorSets passive mode. Displays errors only if the installation is not successful. This option requires user interaction if the installation is not successful.
/showrmuiUsed only with the /passive option. Displays a message box that prompts users to close .NET Framework apps that are currently running. This message box behaves the same in passive and non-passive mode.
/uninstallUninstalls the .NET Framework redistributable.

Supported languages

The following table lists .NET Framework language packs that are available for .NET Framework 4.5 and later versions.

LCIDLanguage – country/regionCulture
1025Arabic - Saudi Arabiaar
1028Chinese – Traditionalzh-Hant
1029Czechcs
1030Danishda
1031German – Germanyde
1032Greekel
1035Finnishfi
1036French – Francefr
1037Hebrewhe
1038Hungarianhu
1040Italian – Italyit
1041Japaneseja
1042Koreanko
1043Dutch – Netherlandsnl
1044Norwegian (Bokmål)no
1045Polishpl
1046Portuguese – Brazilpt-BR
1049Russianru
1053Swedishsv
1055Turkishtr
2052Chinese – Simplifiedzh-Hans
2070Portuguese – Portugalpt-PT
3082Spanish - Spain (Modern Sort)es

See also

-->

If you are migrating from the .NET Framework 4.5.2 to 4.8, review the following topics for application compatibility issues that may affect your app:

ASP.NET

ASP.NET Fix handling of InputAttributes and LabelAttributes for WebForms CheckBox control

Details

For applications that target .NET Framework 4.7.2 and earlier versions, CheckBox.InputAttributes and CheckBox.LabelAttributes that are programmatically added to a WebForms CheckBox control are lost after postback. For applications that target .NET Framework 4.8 or later versions, they are preserved after postback.

Suggestion

For the correct behavior for restoring attributes on postback, set the targetFrameworkVersion to 4.8 or higher. For example:Setting it lower, or not at all, preserves the old incorrect behavior.

NameValue
ScopeUnknown
Version4.8
TypeRuntime

Affected APIs

ASP.NET Incorrect multipart handling may result in lost form data.

Details

In applications that target .NET Framework 4.7.2 and earlier versions, ASP.NET might incorrectly parse multipart boundary values, resulting in form data being unavailable during request execution. Applications that target .NET Framework 4.8 or later versions correctly parse multipart data, so form values are available during request execution.

Suggestion

Starting with applications running on .NET Framework 4.8, when targeting .NET Framework 4.8 or later by using the targetFrameworkVersion element, the default behavior changes to strip delimiters. When targeting previous framework versions or not using targetFrameworkVersion, trailing delimiters for some values are still returned.

This behavior can also be explicitly controlled with an appSetting:

NameValue
ScopeUnknown
Version4.8
TypeRuntime

Affected APIs

ASP.NET ValidationContext.MemberName is not NULL when using custom DataAnnotations.ValidationAttribute

Details

In .NET Framework 4.7.2 and earlier versions, when using a custom System.ComponentModel.DataAnnotations.ValidationAttribute, the ValidationContext.MemberName property returns null. In .NET Framework 4.8 version prior to the October 2019 update, it returns the member name. Starting with .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8, it returns null by default, but you can opt in to return the member name instead.

Suggestion

Add the following setting to your web.config file for the property to return the member name in .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8 and later versions:In .NET Framework 4.8 version prior to the October 2019 update, adding this to your web.config file restores the previous behavior and the property returns null.

NameValue
ScopeUnknown
Version4.8
TypeRuntime

Affected APIs

GridViews with AllowCustomPaging set to true may fire the PageIndexChanging event when leaving the final page of the view

Details

A bug in the .NET Framework 4.5 causes System.Web.UI.WebControls.GridView.PageIndexChanging to sometimes not fire for System.Web.UI.WebControls.GridViews that have enabled System.Web.UI.WebControls.GridView.AllowCustomPaging.

Suggestion

This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework. As a work-around, the app can do an explicit BindGrid on any Page_Load that would hit these conditions (the System.Web.UI.WebControls.GridView is on the last page and LastSystem.Web.UI.WebControls.GridView.PageSize is different from System.Web.UI.WebControls.GridView.PageSize). Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.

NameValue
ScopeMinor
Version4.5
TypeRuntime

Affected APIs

Core

.NET COM successfully marshals ByRef SafeArray parameters on events

Details

In .NET Framework 4.7.2 and earlier versions, a ByRef SafeArray parameter on a COM event would fail to marshal back to native code. With this change, the SafeArray is now marshalled successfully.

  • [ x ] Quirked

Suggestion

If properly marshalling ByRef SafeArray parameters on COM Events breaks execution, you can disable this code by adding the following configuration switch to your application config:

NameValue
ScopeMinor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

.NET Interop will now QueryInterface for IAgileObject (a WinRT interface)

Details

When using a WinRT event with a .NET delegate, Windows will QI for IAgileObject starting with .NET Framework 4.8. In previous versions of .NET Framework, the runtime would fail that QI, and the event could not be subscribed.

  • [ x ] Quirked

Suggestion

If enabling the QI for IAgileObject breaks execution, you can disable this code by setting the following configuration.

Method 1: Environment variable

Set the following environment variable: COMPLUS_DisableCCWSupportIAgileObject=1

This method affects any environment that inherits this environment variable. This might be just a single console session, or it might affect the entire machine if you set the environment variable globally. The environment variable name is not case-sensitive.

Method 2: Registry

Using Registry Editor (regedit.exe), find either of the following subkeys:

  • HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFramework
  • HKEY_CURRENT_USERSOFTWAREMicrosoft.NETFramework

Then add the following entry:

Name: DisableCCWSupportIAgileObjectType: DWORD (32-bit) value (also called REG_DWORD)Data: 1

You can use the Windows REG.EXE tool to add this value from a command line or scripting environment. For example:

In this case, HKLM is used instead of HKEY_LOCAL_MACHINE. Use reg add /? to see help on this syntax. The registry value name is not case-sensitive.

NameValue
ScopeEdge
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

A ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2

Details

Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the System.Runtime.Serialization.NetDataContractSerializer cannot be deserialized in the .NET Framework 4.5.1 or in the .NET Framework 4.5.2.Note that moving in the other direction (serializing with the .NET Framework 4.5.x and deserializing with the .NET Framework 4.5) works. Similarly, all 4.x cross-version serialization works with the .NET Framework 4.6.Serializing and deserializing with a single version of the .NET Framework is not affected.

Suggestion

If it is necessary to serialize and deserialize a System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, an alternate serializer like the System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer should be used instead of the System.Runtime.Serialization.NetDataContractSerializer.Alternatively, because this issue is addressed in the .NET Framework 4.6, it may be solved by upgrading to that version of the .NET Framework.

NameValue
ScopeMinor
Version4.5.1
TypeRuntime

Affected APIs

Not detectable via API analysis.

Allow Unicode in URIs that resemble UNC shares

Details

In System.Uri, constructing a file URI containing both a UNC share name and Unicode characters will no longer result in a URI with invalid internal state. The behavior will change only when all of the following are true:

  • The URI has the scheme file: and is followed by four or more slashes.
  • The host name begins with an underscore or other non-reserved symbol.
  • The URI contains Unicode characters.

Suggestion

Applications working with URIs consistently containing Unicode could have conceivably used this behavior to disallow references to UNC shares. Those applications should use IsUnc instead.

NameValue
ScopeEdge
Version4.7.2
TypeRuntime

Affected APIs

AppDomainSetup.DynamicBase is no longer randomized by UseRandomizedStringHashAlgorithm

Details

Prior to the .NET Framework 4.6, the value of DynamicBase would be randomized between application domains, or between processes, if UseRandomizedStringHashAlgorithm was enabled in the app's config file. Beginning in the .NET Framework 4.6, DynamicBase will return a stable result between different instances of an app running, and between different app domains. Dynamic bases will still differ for different apps; this change only removes the random naming element for different instances of the same app.

Suggestion

Be aware that enabling UseRandomizedStringHashAlgorithm will not result in DynamicBase being randomized. If a random base is needed, it must be produced in your app's code rather than via this API.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

Calling Attribute.GetCustomAttributes on an indexer property no longer throws AmbiguousMatchException if the ambiguity can be resolved by index's type

Details

Prior to the .NET Framework 4.6, calling GetCustomAttribute(s) on an indexer property which differed from another property only by the type of the index would result in an System.Reflection.AmbiguousMatchException. Beginning in the .NET Framework 4.6, the property's attributes will be correctly returned.

Suggestion

Be aware that GetCustomAttribute(s) will work more frequently now. If an app was previously relying on the System.Reflection.AmbiguousMatchException, reflection should now be used to explicitly look for multiple indexers, instead.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

COR_PRF_GC_ROOT_HANDLEs are not being enumerated by profilers

Details

In the .NET Framework v4.5.1, the profiling API RootReferences2() is incorrectly never returning COR_PRF_GC_ROOT_HANDLE (they are returned as COR_PRF_GC_ROOT_OTHER instead). This issue is fixed beginning in the .NET Framework 4.6.

Suggestion

This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeMinor
Version4.5.1
TypeRuntime

Affected APIs

Not detectable via API analysis.

ETW EventListeners do not capture events from providers with explicit keywords (like the TPL provider)

Details

ETW EventListeners with a blank keyword mask do not properly capture events from providers with explicit keywords. In the .NET Framework 4.5, the TPL provider began providing explicit keywords and triggered this issue. In the .NET Framework 4.6, EventListeners have been updated to no longer have this issue.

Suggestion

To work around this problem, replace calls to EnableEvents(EventSource, EventLevel) with calls to the EnableEvents overload that explicitly specifies the 'any keywords' mask to use: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).

Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeEdge
Version4.5
TypeRuntime

Affected APIs

Persian calendar now uses the Hijri solar algorithm

Details

Starting with the .NET Framework 4.6, the System.Globalization.PersianCalendar class uses the Hijri solar algorithm. Converting dates between the System.Globalization.PersianCalendar and other calendars may produce a slightly different result beginning with the .NET Framework 4.6 for dates earlier than 1800 or later than 2023 (Gregorian).Also, PersianCalendar.MinSupportedDateTime is now March 22, 0622 instead of March 21, 0622.

Suggestion

Be aware that some early or late dates may be slightly different when using the PersianCalendar in .NET Framework 4.6. Also, when serializing dates between processes which may run on different .NET Framework versions, do not store them as PersianCalendar date strings (since those values may be different).

NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Reflection objects can no longer be passed from managed code to out-of-process DCOM clients

Details

Reflection objects can no longer be passed from managed code to out-of-process DCOM clients. The following types are affected:

  • System.Reflection.MemberInfo (and its derived types, including System.Reflection.FieldInfo, System.Reflection.MethodInfo, System.Type, and System.Reflection.TypeInfo)

Calls to IMarshal for the object return E_NOINTERFACE.

Suggestion

Update marshaling code to work with non-reflection objects.

NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Support special relative URI notation when Unicode is present

Details

Uri will no longer throw a NullReferenceException when calling TryCreate on certain relative URIs containing Unicode. The simplest reproduction of the NullReferenceException is below, with the two statements being equivalent:

To reproduce the NullReferenceException, the following items must be true:

  • The URI must be specified as relative by prepending it with 'http:' and not following it with '//'.
  • The URI must contain percent-encoded Unicode or unreserved symbols.

Suggestion

Users depending on this behavior to disallow relative URIs should instead specify UriKind.Absolute when creating a URI.

NameValue
ScopeEdge
Version4.7.2
TypeRuntime

Affected APIs

TargetFrameworkName for default app domain no longer defaults to null if not set

Details

The System.AppDomainSetup.TargetFrameworkName was previously null in the default app domain, unless it was explicitly set. Beginning in 4.6, the System.AppDomainSetup.TargetFrameworkName property for the default app domain will have a default value derived from the TargetFrameworkAttribute (if one is present). Non-default app domains will continue to inherit their System.AppDomainSetup.TargetFrameworkName from the default app domain (which will not default to null in 4.6) unless it is explicitly overridden.

Suggestion

Code should be updated to not depend on TargetFrameworkName defaulting to null. If it is required that this property continue to evaluate to null, it can be explicitly set to that value.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

X509Certificate2.ToString(Boolean) does not throw now when .NET cannot handle the certificate

Details

In .NET Framework 4.5.2 and earlier versions, this method would throw if true was passed for the verbose parameter and there were certificates installed that weren't supported by the .NET Framework. Now, the method will succeed and return a valid string that omits the inaccessible portions of the certificate.

Suggestion

Any code depending on X509Certificate2.ToString(Boolean) should be updated to expect that the returned string may exclude some certificate data (such as public key, private key, and extensions) in some cases in which the API would have previously thrown.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

Data

Connection pool blocking period for Azure SQL databases is removed

Details

Starting with the .NET Framework 4.6.2, for connection open requests to known Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool blocking period is removed, and connection open errors are not cached. Attempts to retry connection open requests will occur almost immediately after transient connection errors. This change allows the connection open attempt to be retried immediately for Azure SQL databases, thereby improving the performance of cloud- enabled apps. For all other connection attempts, the connection pool blocking period continues to be enforced.

In the .NET Framework 4.6.1 and earlier versions, when an app encounters a transient connection failure when connecting to a database, the connection attempt cannot be retried quickly, because the connection pool caches the error and re-throws it for 5 seconds to 1 minute. For more information, see SQL Server Connection Pooling (ADO.NET). This behavior is problematic for connections to Azure SQL databases, which often fail with transient errors that are typically recovered from within a few seconds. The connection pool blocking feature means that the app cannot connect to the database for an extensive period, even though the database is available and the app needs to render within a few seconds.

Suggestion

If this behavior is undesirable, the connection pool blocking period can be configured by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take either of three values:

The previous behavior can be restored by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

Debugger

Null coalescer values are not visible in debugger until one step later

Details

A bug in the .NET Framework 4.5 causes values set via a null coalescing operation to not be visible in the debugger immediately after the assignment operation is executed when running on the 64-bit version of the Framework.

Suggestion

Stepping one additional time in the debugger will cause the local/field's value to be correctly updated. Also, this issue has been fixed in the .NET Framework 4.6; upgrading to that version of the Framework should solve the issue.

NameValue
ScopeEdge
Version4.5
TypeRuntime

Affected APIs

Not detectable via API analysis.

Globalization

Unicode standard version 8.0 categories now supported

Details

In .NET Framework 4.6.2, Unicode data has been upgraded from Unicode Standard version 6.3 to version 8.0. When requesting Unicode character categories in .NET Framework 4.6.2, some results might not match the results in previous .NET Framework versions. This change mostly affects Cherokee syllables and New Tai Lue vowels signs and tone marks.

Suggestion

Review code and remove/change logic that depends on hard-coded Unicode character categories.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

Networking

ContentDisposition DateTimes returns slightly different string

Details

String representations of System.Net.Mime.ContentDisposition's have been updated, beginning in 4.6, to always represent the hour component of a System.DateTime with two digits. This is to comply with RFC822 and RFC2822. This causes ToString() to return a slightly different string in 4.6 in scenarios where one of the disposition's time elements was before 10:00 AM. Note that ContentDispositions are sometimes serialized via converting them to strings, so any ToString() operations, serialization, or GetHashCode calls should be reviewed.

Suggestion

Do not expect that string representations of ContentDispositions from different .NET Framework versions will correctly compare to one another. Convert the strings back to ContentDispositions, if possible, before conducting a comparison.

NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Runtime

Improved WCF chain trust certificate validation for Net.Tcp certificate authentication

Details

.NET Framework 4.7.2 improves chain trust certificate validation when using certificate authentication with transport security with WCF. With this improvement, client certificates that are used to authenticate to a server must be configured for client authentication. Similarly server certificates that are for the authenticating a server must be configured for server authentication. With this change, if the root certificate is disabled, the certificate chain validation fails. The same change was also made to .NET Framework 3.5 and later versions via Windows security roll-up. You can find more information here.This change is on by default and can be turned off by a configuration setting.

Suggestion

  • Validate if your server and client certification has the required EKU OID. If not, update your certification.

  • Validate if your root certificate is invalid. If so, update the root certificate.

  • If you can't update the certificate, you can work around the breaking change temporarily with the following configuration setting. However, opting out of the change will leave your system vulnerable to the security issue.

NameValue
ScopeMinor
Version4.7.2
TypeRuntime

Affected APIs

Not detectable via API analysis.

Security

RSACng.VerifyHash now returns False for any verification failure

Details

Starting with the .NET Framework 4.6.2, this method returns False if the signature itself is badly formatted. It now returns false for any verification failure.In the .NET Framework 4.6 and 4.6.1, the method throws a System.Security.Cryptography.CryptographicException if the signature itself is badly formatted.

Suggestion

Any code whose execution depends on handling the System.Security.Cryptography.CryptographicException should instead execute if validation fails and the method returns False.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

SignedXml and EncryptedXml Breaking Changes

Details

In .NET Framework 4.6.2, security fixes in System.Security.Cryptography.Xml.SignedXml and System.Security.Cryptography.Xml.EncryptedXml lead to different run-time behaviors. For example:

  • If a document has multiple elements with the same id attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.
  • Documents using non-canonical XPath transform algorithms in references are now considered invalid.
  • Documents using non-canonical XSLT transform algorithms in references are now consider invalid.
  • Any program making use of external resource detached signatures will be unable to do so.

Framework 5.0 Download

Suggestion

Developers might want to review the usage of XmlDsigXsltTransform and XmlDsigXsltTransform, as well as types derived from Transform since a document receiver may not be able to process it.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

Serialization

Exception message has changed for failed DataContract serialization in case of an unknown type

Details

Beginning in the .NET Framework 4.6, the exception message given if a System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Json.DataContractJsonSerializer fails to serialize or deserialize due to missing 'known types' has been clarified.

Suggestion

Apps should not depend on specific exception messages. If an app depends on this message, either update it to expect the new message or (preferably) change it to depend only on the exception type.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

Setup and Deployment

Product versioning changes in the .NET Framework 4.6 and later versions

Details

Product versioning has changed from the previous releases of the .NET Framework, and particularly from the .NET Framework 4, 4.5, 4.5.1, and 4.5.2. The following are the detailed changes:

  • The value of the Version entry in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4Full key has changed to 4.6.xxxxx for the .NET Framework 4.6 and its point releases, and to 4.7.xxxxx for the .NET Framework 4.7 and 4.7.1. In the .NET Framework 4.5, 4.5.1, and 4.5.2, it had the format 4.5.xxxxx.
  • The file and product versioning for .NET Framework files has changed from the earlier versioning scheme of 4.0.30319.x to 4.6.X.0 for the .NET Framework 4.6 and its point releases, and to 4.7.X.0 for the .NET Framework 4.7 and 4.7.1. You can see these new values when you view the file's Properties after right-clicking on a file.
  • The AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute attributes for managed assemblies have Version values in the form 4.6.X.0 for the .NET Framework 4.6 and its point releases, and 4.7.X.0 for the .NET Framework 4.7 and 4.7.1.
  • In the .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1, the Environment.Version property returns the fixed version string 4.0.30319.42000. In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format 4.0.30319.xxxxx (for example, '4.0.30319.18010'). Note that we do not recommend application code taking any new dependency on the Environment.Version property.

For more information, see How to: Determine which .NET Framework Versions Are Installed.

Suggestion

In general, applications should depend on the recommended techniques for detecting such things as the runtime version of the .NET Framework and the installation directory:

  • To detect the runtime version of the .NET Framework, see How to: Determine Which .NET Framework Versions Are Installed.
  • To determine the installation path for the .NET Framework, use the value of the InstallPath entry in the HKEY_LOCAL_MACHINESOFTWAREMicrosoftNET Framework SetupNDPv4Full key.

Important

The subkey name is NET Framework Setup, not .NET Framework Setup.

  • To determine the directory path to the .NET Framework common language runtime, call the RuntimeEnvironment.GetRuntimeDirectory() method.
  • To get the CLR version, call the RuntimeEnvironment.GetSystemVersion() method. For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1), it returns the string v4.0.30319.
NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Not detectable via API analysis.

The .NET Framework 4.6 does not use a 4.5.x.x version when registering itself in the registry

Details

As one might expect, the version key set in the registry (at HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftNET Framework SetupNDPv4Full) for the .NET Framework 4.6 begins with '4.6', not '4.5'. Apps that depend on these registry keys to know which .NET Framework versions are installed on a machine should be updated to understand that 4.6 is a new possible version, and one that is compatible with previous 4.5.x releases.

Suggestion

Update apps probing for a .NET Framework 4.5 install by looking for 4.5 registry keys to also accept 4.6.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

Not detectable via API analysis.

Tools

Contract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure

Details

For apps that target the .NET Framework 4.6.1, if the invariant contract for Contract.Invariant or the precondition contract for Requires calls the String.IsNullOrEmpty method, the rewriter emits compiler warning CC1036: 'Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method.' This is a compiler warning rather than a compiler error.

Suggestion

This behavior was addressed in GitHub Issue #339. To eliminate this warning, you can download and compile an updated version of the source code for the Code Contracts tool from GitHub. Download information is found at the bottom of the page.

NameValue
ScopeMinor
Version4.6.1
TypeRuntime

Affected APIs

Web Applications

'dataAnnotations:dataTypeAttribute:disableRegEx' app setting is on by default in .NET Framework 4.7.2

Details

In .NET Framework 4.6.1, an app setting (&quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot;) was introduced that allows users to disable the use of regular expressions in data type attributes (such as System.ComponentModel.DataAnnotations.EmailAddressAttribute, System.ComponentModel.DataAnnotations.UrlAttribute, and System.ComponentModel.DataAnnotations.PhoneAttribute). This helps to reduce security vulnerability such as avoiding the possibility of a Denial of Service attack using specific regular expressions.
In .NET Framework 4.6.1, this app setting to disable RegEx usage was set to false by default. Starting with .NET Framework 4.7.2, this config switch is set to true by default to further reduce secure vulnerability for web applications that target .NET Framework 4.7.2 and above.

Suggestion

If you find that regular expressions in your web application do not work after upgrading to .NET Framework 4.7.2, you can update the value of the &quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot; setting to false to revert to the previous behavior.

NameValue
ScopeMinor
Version4.7.2
TypeRuntime

Affected APIs

Not detectable via API analysis.

Windows Communication Foundation (WCF)

Remove Ssl3 from the WCF TransportDefaults

Details

When using NetTcp with transport security and a credential type of certificate, the SSL 3 protocol is no longer a default protocol used for negotiating a secure connection. In most cases there should be no impact to existing apps as TLS 1.0 has always been included in the protocol list for NetTcp. All existing clients should be able to negotiate a connection using at least TLS1.0.

Suggestion

If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.

NameValue
ScopeEdge
Version4.6.2
TypeRuntime

Affected APIs

svcTraceViewer ComboBox high contrast change

Details

In the Microsoft Service Trace Viewer tool, ComboBox controls were not displayed in the correct color in certain high contrast themes. The issue was fixed in .NET Framework 4.7.2. However, due to .NET Framework SDK backward compatibility requirements, the fix was not visible to customers by default. .NET 4.8 surfaces this change by adding the following AppContext configuration switches to the svcTraceViewer.exe.config file:

Suggestion

If you don't want to have the high contrast behavior change, you can disable it by removing the following section from the svcTraceViewer.exe.config file:

NameValue
ScopeEdge
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

WCF AddressHeaderCollection now throws an ArgumentException if an addressHeader element is null

Details

Starting with the .NET Framework 4.7.1, the AddressHeaderCollection(IEnumerable<AddressHeader>) constructor throws an ArgumentException if one of the elements is null. In the .NET Framework 4.7 and earlier versions, no exception is thrown.

Suggestion

If you encounter compatibility issues with this change on the .NET Framework 4.7.1 or a later version, you can opt-out of it by adding the following line to the <runtime> section of the app.config file:

NameValue
ScopeMinor
Version4.7.1
TypeRuntime

Net Framework 4.5 2 Download Filehippo

Affected APIs

WCF MsmqSecureHashAlgorithm default value is now SHA256

Details

Starting with the .NET Framework 4.7.1, the default message signing algorithm in WCF for Msmq messages is SHA256. In the .NET Framework 4.7 and earlier versions, the default message signing algorithm is SHA1.

Suggestion

If you run into compatibility issues with this change on the .NET Framework 4.7.1 or later, you can opt-out the change by adding the following line to the <runtime> section of your app.config file:

NameValue
ScopeMinor
Version4.7.1
TypeRuntime

Affected APIs

Not detectable via API analysis.

WCF PipeConnection.GetHashAlgorithm now uses SHA256

Details

Starting with the .NET Framework 4.7.1, Windows Communication Foundation uses a SHA256 hash to generate random names for named pipes. In the .NET Framework 4.7 and earlier versions, it used a SHA1 hash.

Suggestion

If you run into compatibility issue with this change on the .NET Framework 4.7.1 or later, you can opt-out it by adding the following line to the <runtime> section of your app.config file:

NameValue
ScopeMinor
Version4.7.1
TypeRuntime

Affected APIs

Not detectable via API analysis.

WCF services that use NETTCP with SSL security and MD5 certificate authentication

Details

The .NET Framework 4.6 adds TLS 1.1 and TLS 1.2 to the WCF SSL default protocol list. When both client and server machines have the .NET Framework 4.6 or later installed, TLS 1.2 is used for negotiation.TLS 1.2 does not support MD5 certificate authentication. As a result, if a customer uses an MD5 certificate, the WCF client will fail to connect to the WCF service.

Microsoft .net Framework 4 5 2 Download

Suggestion

You can work around this issue so that a WCF client can connect to a WCF server by doing any of the following:

  • Update the certificate to not use the MD5 algorithm. This is the recommended solution.
  • If the binding is not dynamically configured in source code, update the application's configuration file to use TLS 1.1 or an earlier version of the protocol. This allows you to continue to use a certificate with the MD5 hash algorithm.

Warning

This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

The following configuration file does this:

  • If the binding is dynamically configured in source code, update the TcpTransportSecurity.SslProtocols property to use TLS 1.1 (SslProtocols.Tls11 or an earlier version of the protocol in the source code.

Warning

This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Not detectable via API analysis.

Windows Presentation Foundation (WPF)

Accessing a WPF DataGrid's selected items from a handler of the DataGrid's UnloadingRow event can cause a NullReferenceException

Details

Due to a bug in the .NET Framework 4.5, event handlers for DataGrid events involving the removal of a row can cause a System.NullReferenceException to be thrown if they access the DataGrid's System.Windows.Controls.Primitives.Selector.SelectedItem or System.Windows.Controls.Primitives.MultiSelector.SelectedItems properties.

Suggestion

This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeMinor
Version4.5
TypeRuntime

Affected APIs

Calling Items.Refresh on a WPF ListBox, ListView, or DataGrid with items selected can cause duplicate items to appear in the element

Details

In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a System.Windows.Controls.ListBox can cause the selected items to be duplicated in the list. A similar issue occurs with System.Windows.Controls.ListView and System.Windows.Controls.DataGrid. This is fixed in the .NET Framework 4.6.

Suggestion

This issue may be worked around by programmatically unselecting items before System.Windows.Data.CollectionView.Refresh() is called and then re-selecting them after the call is completed. Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeMinor
Version4.5
TypeRuntime

Affected APIs

Chained Popups with StaysOpen=False

Details

A Popup with StaysOpen=False is supposed to close when you click outside the Popup. When two or more such Popups are chained (i.e. one contains another), there were many problems, including:

  • Open two levels, click outside P2 but inside P1. Nothing happens.
  • Open two levels, click outside P1. Both popups close.
  • Open and close two levels. Then try to open P2 again. Nothing happens.
  • Try to open three levels. You can't. (Either nothing happens or the first two levels close, depending on where you click.)

These cases (and other variants) now work as expected.

NameValue
ScopeEdge
Version4.7.1
TypeRuntime

Affected APIs

Changing the IsEnabled property of the parent of a TextBlock control affects any child controls

Details

Starting with the .NET Framework 4.6.2, changing the System.Windows.UIElement.IsEnabled property of the parent of a System.Windows.Controls.TextBlock control affects any child controls (such as hyperlinks and buttons) of the System.Windows.Controls.TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a System.Windows.Controls.TextBlock did not always reflect the state of the System.Windows.UIElement.IsEnabled property of the System.Windows.Controls.TextBlock parent.

Suggestion

None. This change conforms to the expected behavior for controls inside a System.Windows.Controls.TextBlock control.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

Data Binding improvement for KeyedCollection

Details

Fixed Binding incorrect use of IList indexer when the source object declares a custom indexer with the same signature (for example, KeyedCollection<int,TItem>).

Suggestion

In order for an application that targets an older version to benefit from this change, it must run on the .NET Framework 4.8 or later, and it must opt in to the change by adding the following AppContext switch to the <runtime> section of the app config file and setting it to false:

NameValue
ScopeMajor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

Fixed a issue when ListBox stops responding if it contains duplicate value-types

Details

Fixed a problem where a virtualizing ItemsControl can stop responding during scrolling when its Items collection contains duplicate value-typed objects.

NameValue
ScopeMajor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

Horizontal scrolling and virtualization

Details

This change applies to an System.Windows.Controls.ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is System.Windows.Controls.DataGrid with EnableColumnVirtualization='True'). The outcome of certain horizontal scrolling operations has been changed to produce results that are more intuitive and more analogous to the results of comparable vertical operations.

The operations include 'Scroll Here' and 'Right Edge', to use the names from the menu obtained by right-clicking a horizontal scrollbar. Both of these compute a candidate offset and call SetHorizontalOffset(Double).

After scrolling to the new offset, the notion of 'here' or 'right edge' may have changed because newly de-virtualized content has changed the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even though it may not be 'here' or at the 'right edge' any more. This results in effects like 'bouncing' the scroll thumb, best illustrated by example. Suppose a System.Windows.Controls.DataGrid has ExtentWidth=1000 and Width=200. A scroll to 'Right Edge' uses candidate offset 1000 - 200 = 800. While scrolling to that offset, new columns are de- virtualized; let's suppose they are very wide, so that the System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth changes to 2000. The scroll ends with HorizontalOffset=800, and the thumb 'bounces' back to near the middle of the scrollbar - precisely at 800/2000 = 40%.

The change is to recompute a new candidate offset when this situation occurs, and try again. (This is how vertical scrolling works already.)

The change produces a more predictable and intuitive experience for the end user, but it could also affect any app that depends on the exact value of System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).

Suggestion

An app that uses a predicted value for System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset should be changed to fetch the actual value (and the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) after any horizontal scroll that could change System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth due to de-virtualization.

NameValue
ScopeMinor
Version4.6.2
TypeRuntime

Affected APIs

Improvements to Grid star-rows space allocating algorithm

Details

Fixed a bug in the algorithm for allocating sizes to) in a Grid introduced in .NET Framework 4.7. In some cases, such as a Grid with Height=&quot;Auto&quot; containing empty rows, rows were arranged at the wrong position, possibly outside the Grid altogether.

Suggestion

In order for the application to benefit from these changes, it must run on the .NET Framework 4.8 or later.

NameValue
ScopeMajor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

Items.Clear does not remove duplicates from SelectedItems

Details

Suppose a Selector (with multiple selection enabled) has duplicates in its System.Windows.Controls.Primitives.MultiSelector.SelectedItems collection - the same item appears more than once. Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from System.Windows.Controls.Primitives.MultiSelector.SelectedItems; only the first instance is removed. Furthermore, subsequent use of System.Windows.Controls.Primitives.MultiSelector.SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as System.ArgumentException, because System.Windows.Controls.Primitives.MultiSelector.SelectedItems contains items that are no longer in the data source.

Suggestion

Upgrade if possible to .NET Framework 4.6.2.

NameValue
ScopeMinor
Version4.5
TypeRuntime

Affected APIs

Keyboard navigation improvement in ListBox with Hyperlinks

Details

Fixed incorrect result of pressing an arrow key when the focus is on a hyperlink within an item that is not the selected item of the parent ItemsControl.

NameValue
ScopeMajor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

.net framework 4.5.2 download windows 10

Keytips behavior improved in WPF

Details

Keytips behavior has been modified to bring parity with behavior on Microsoft Word and Windows Explorer. By checking whether keytip state is enabled or not in the case of a SystemKey (in particular, Key or F11) being pressed, WPF handles keytip keys appropriately. Keytips now dismiss a menu even when it is opened by mouse.

Suggestion

N/A

NameValue
ScopeEdge
Version4.7.2
TypeRuntime

Affected APIs

Not detectable via API analysis.

ListBoxItem IsSelected binding issue with ObservableCollection<T>.Move

Details

Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a System.Windows.Controls.ListBox with items selected can lead to erratic behavior with future selection or unselection of System.Windows.Controls.ListBox items.

Suggestion

Calling System.Collections.ObjectModel.Collection<T>.Remove(T) and System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) instead of Move(Int32, Int32) will work around this issue. Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeMinor
Version4.5
TypeRuntime

Affected APIs

Performance improvement in Automation tree for grouping ItemsControls

Details

Improved the performance of rebuilding the automation tree of an ItemsControl, such as a ListBox or DataGrid, in which grouping is enabled.

NameValue
ScopeMajor
Version4.8
TypeRuntime

Affected APIs

Not detectable via API analysis.

Right clicking on a WPF DataGrid row header changes the DataGrid selection

Details

Right-clicking a selected System.Windows.Controls.DataGrid row header while multiple rows are selected results in the System.Windows.Controls.DataGrid's selection changing to only that row.

Suggestion

This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

NameValue
ScopeEdge
Version4.5
TypeRuntime

Affected APIs

WPF Printing Stack Update

Details

WPF's Printing APIs using System.Printing.PrintQueue now call Window's Print Document Package API in favor of the now deprecated XPS Print API. The change was made with serviceability in mind; neither users nor developers should see any changes in behavior or API usage. The new printing stack is enabled by default when running in Windows 10 Creators Update. The old printing stack will still continue to work just as before in older Windows versions.

Suggestion

Microsoft Net Framework

To use the old stack in Windows 10 Creators Update, set the UseXpsOMPrinting REG_DWORD value of the HKEY_CURRENT_USERSoftwareMicrosoft.NETFrameworkWindows Presentation FoundationPrinting registry key to 1.

NameValue
ScopeEdge
Version4.7
TypeRuntime

Affected APIs

Not detectable via API analysis.

WPF spawns a wisptis.exe process which can freeze the mouse

Details

An issue was introduced in 4.5.2 that causes wisptis.exe to be spawned that can freeze mouse input.

Suggestion

A fix for this issue is available in a servicing release of the .NET Framework 4.5.2 (hotfix rollup 3026376), or by upgrading to the .NET Framework 4.6

NameValue
ScopeMajor
Version4.5.2
TypeRuntime

Affected APIs

Not detectable via API analysis.

WPF spell checking in text-enabled controls will not work in Windows 10 for languages not in the OS's input language list

Details

When running on Windows 10, the spell checker may not work for WPF text-enabled controls because platform spell-checking capabilities are available only for languages present in the input languages list.In Windows 10, when a language is added to the list of available keyboards, Windows automatically downloads and installs a corresponding Feature on Demand (FOD) package that provides spell-checking capabilities. By adding the language to the input languages list, the spell checker will be supported.

Suggestion

Be aware that the language or text to be spell-checked must be added as an input language for spell-checking to work in Windows 10.

NameValue
ScopeEdge
Version4.6
TypeRuntime

Affected APIs

Not detectable via API analysis.

WPF windows are rendered without clipping when extending outside a single monitor

Details

In the .NET Framework 4.6 running on Windows 8 and above, the entire window is rendered without clipping when it extends outside of single display in a multi-monitor scenario. This is different from previous versions of the .NET Framework which would clip WPF windows that extended beyond a single display.

Suggestion

This behavior (whether to clip or not) can be explicitly set using the <EnableMultiMonitorDisplayClipping> element in <appSettings> in an application's configuration file, or by setting the EnableMultiMonitorDisplayClipping property at app startup.

NameValue
ScopeMinor
Version4.6
TypeRuntime

Affected APIs

Not detectable via API analysis.

Windows Workflow Foundation (WF)

Workflow now throws original exception instead of NullReferenceException in some cases

Details

In the .NET Framework 4.6.2 and earlier versions, when the Execute method of a workflow activity throws an exception with a null value for the Message property, the System.Activities Workflow runtime throws a System.NullReferenceException, masking the original exception.In the .NET Framework 4.7, the previously masked exception is thrown.

Suggestion

If your code relies on handling the System.NullReferenceException, change it to catch the exceptions that could be thrown from your custom activities.

NameValue
ScopeMinor
Version4.7
TypeRuntime

Affected APIs

Workflow SQL persistence adds primary key clusters and disallows null values in some columns

Details

Starting with the .NET Framework 4.7, the tables created for the SQL Workflow Instance Store (SWIS) by the SqlWorkflowInstanceStoreSchema.sql script use clustered primary keys. Because of this, identities do not support null values. The operation of SWIS is not impacted by this change. The updates were made to support SQL Server Transactional Replication.

Suggestion

The SQL file SqlWorkflowInstanceStoreSchemaUpgrade.sql must be applied to existing installations in order to experience this change. New database installations will automatically have the change.

NameValue
ScopeEdge
Version4.7
TypeRuntime

Affected APIs

Not detectable via API analysis.