.NET Framework (4)

What's new in this version:

CORE:
- The .NET Framework 4.7.2 features a large number of cryptographic enhancements, better decompression support for ZIP archives, and additional collection APIs

New overloads of RSA.Create and DSA.Create:
- The DSA.Create(DSAParameters) and RSA.Create(RSAParameters) methods let you supply key parameters when instantiated a new DSA or RSA key

Rfc2898DeriveBytes constructors accept a hash algorithm name:
- The Rfc2898DeriveBytes class has three new constructors with a HashAlgorithmName parameter that identifies the HMAC algorithm to use when deriving keys. Instead of using SHA-1, developers should use a SHA-2-based HMAC like SHA-256

Support for ephemeral keys:
PFX import can optionally load private keys directly from memory, bypassing the hard drive. When the new X509KeyStorageFlags.EphemeralKeySet flag is specified in an X509Certificate2 constructor or one of the overloads of the X509Certificate2.Import method, the private keys will be loaded as ephemeral keys. This prevents the keys from being visible on the disk. However:
- Since the keys are not persisted to disk, certificates loaded with this flag are not good candidates to add to an X509Store.
- Keys loaded in this manner are almost always loaded via Windows CNG. Therefore, callers must access the private key by calling extension methods, such as cert.GetRSAPrivateKey(). The X509Certificate2.PrivateKey property does not function.
- Since the legacy X509Certificate2.PrivateKey property does not work with certificates, developers should perform rigorous testing before switching to ephemeral keys.

Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates:
- Starting with the .NET Framework 4.7.2, workloads can generate certificate signing requests (CSRs), which allows certificate request generation to be staged into existing tooling. This is frequently useful in test scenarios

New SignerInfo members:
- Starting with the .NET Framework 4.7.2, the SignerInfo class exposes more information about the signature. You can retrieve the value of the System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm property to determine the signature algorithm used by the signer. SignerInfo.GetSignature can be called to get a copy of the cryptographic signature for this signer
- Leaving a wrapped stream open after CryptoStream is disposed
- Starting with the .NET Framework 4.7.2, the CryptoStream class has an additional constructor that allows Dispose to not close the wrapped stream

Decompression changes in DeflateStream:
- Starting with the .NET Framework 4.7.2, the implementation of decompression operations in the DeflateStream class has changed to use native Windows APIs by default. Typically, this results in a substantial performance improvement.
- Support for decompression by using Windows APIs is enabled by default for applications that target .NET Framework 4.7.2. Applications that target earlier versions of .NET Framework but are running under .NET Framework 4.7.2 can opt into this behavior by adding the following AppContext switch to the application configuration file: <AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

Additional collection APIs:
- The .NET Framework 4.7.2 adds a number of new APIs to the SortedSet<T> and HashSet<T> types

ASP.NET:
Support for dependency injection in Web Forms:
Dependency injection (DI) decouples objects and their dependencies so that an object's code no longer needs to be changed just because a dependency has changed. When developing ASP.NET applications that target the .NET Framework 4.7.2, you can:
- Use setter-based, interface-based, and constructor-based injection in handlers and modules, Page instances, and user controls of ASP.NET web application projects
- Use setter-based and interface-based injection in handlers and modules, Page instances, and user controls of ASP.NET web site projects
- Plug in different dependency injection frameworks

Support for same-site cookies:
- SameSite prevents a browser from sending a cookie along with a cross-site request. The .NET Framework 4.7.2 adds a HttpCookie.SameSite property whose value is a System.Web.SameSiteMode enumeration member. If its value is SameSiteMode.Strict or SameSiteMode.Lax, ASP.NET adds the SameSite attribute to the set-cookie header. SameSite support applies to HttpCookie objects, as well as to FormsAuthentication and System.Web.SessionState cookies

NETWORKING:
Implementation of HttpClientHandler properties:
The .NET Framework 4.7.1 added eight properties to the System.Net.Http.HttpClientHandler class. However, two threw a PlatformNotSupportedException. The .NET Framework 4.7.2 now provides an implementation for these properties. The properties are:
- CheckCertificateRevocationList
- SslProtocols

SQLCLIENT:
- Support for Azure Active Directory Universal Authentication and Multi-Factor authentication
- Growing compliance and security demands require that many customers use multi-factor authentication (MFA). In addition, current best practices discourage including user passwords directly in connection strings. To support these changes, the .NET Framework 4.7.2 extends SQLClient connection strings by adding a new value, "Active Directory Interactive", for the existing "Authentication" keyword to support MFA and Azure AD Authentication. The new interactive method supports native and federated Azure AD users as well as Azure AD guest users. When this method is used, the MFA authentication imposed by Azure AD is supported for SQL databases. In addition, the authentication process requests a user password to adhere to security best practices.
- In previous versions of the .NET Framework, SQL connectivity supported only the SqlAuthenticationMethod.ActiveDirectoryPassword and SqlAuthenticationMethod.ActiveDirectoryIntegrated options. Both of these are part of the non-interactive ADAL protocol, which does not support MFA. With the new SqlAuthenticationMethod.ActiveDirectoryInteractive option, SQL connectivity supports MFA as well as existing authentication methods (password and integrated authentication), which allows users to enter user passwords interactively without persisting passwords in the connection string.
- Support for Always Encrypted version 2

NET Framework 4.7.2 adds supports for enclave-based Always Encrypted. The original version of Always Encrypted is a client-side encryption technology in which encryption keys never leave the client. In enclave-based Always Encrypted, the client can optionally send the encryption keys to a secure enclave, which is a secure computational entity that can be considered part of SQL Server but that SQL Server code cannot tamper with. To support enclave-based Always Encrypted, the .NET Framework 4.7.2 adds the following types and members to the System.Data.SqlClient namespace:
- SqlConnectionStringBuilder.EnclaveAttestationUrl, which specifies the Uri for enclave-based Always Encrypted
- SqlColumnEncryptionEnclaveProvider, which is an abstract class from which all enclave providers are derived
- SqlEnclaveSession, which encapsulates the state for a given enclave session
- SqlEnclaveAttestationParameters, which provides the attestation parameters used by SQL Server to get information required to execute a particular Attestation Protocol

WINDOWS PRESENTATION FOUNDATION:
Finding ResourceDictionaries by Source:
- Starting with the .NET Framework 4.7.2, a diagnostic assistant can locate the ResourceDictionaries that have been created from a given source Uri. (This feature is for use by diagnostic assistants, not by production applications.) A diagnostic assistant such as Visual Studio’s “Edit-and-Continue” facility lets its user edit a ResourceDictionary with the intent that the changes be applied to the running application. One step in achieving this is finding all the ResourceDictionaries that the running application has created from the dictionary that’s being edited. For example, an application can declare a ResourceDictionary whose content is copied from a given source URI: <ResourceDictionary Source="MyRD.xaml">
- A diagnostic assistant that edits the original markup in MyRD.xaml can use the new feature to locate the dictionary. The feature is implemented by a new static method, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. The diagnostic assistant calls the new method using an absolute Uri that identifies the original markup, as illustrated by the following code: IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));

Finding ResourceDictionary owners:
- Starting with the .NET Framework 4.7.2, a diagnostic assistant can locate the owners of a given ResourceDictionary. (The feature is for use by diagnostic assistants and not by production applications.) Whenever a change is made to a ResourceDictionary, WPF automatically finds all DynamicResource references that might be affected by the change.
- A diagnostic assistant such as Visual Studio’s “Edit-and-Continue” facility may want extend this to handle StaticResource references. The first step in this process is to find the owners of the dictionary; that is, to find all the objects whose Resources property refers to the dictionary (either directly, or indirectly via the ResourceDictionary.MergedDictionaries property). Three new static methods implemented on the System.Windows.Diagnostics.ResourceDictionaryDiagnostics class, one for each of the base types that has a Resources property

Finding StaticResource references:
- A diagnostic assistant can now receive a notification whenever a StaticResource reference is resolved. (The feature is for use by diagnostic assistants, not by production applications.) A diagnostic assistant such as Visual Studio’s “Edit-and-Continue” facility may want to update all uses of a resource when its value in a ResourceDictionary changes. WPF does this automatically for DynamicResource references, but it intentionally does not do so for StaticResource references. Starting with the .NET Framework 4.7.2, the diagnostic assistant can use these notifications to locate those uses of the static resource.

CLICKONCE:
- HDPI-aware applications for Windows Forms, Windows Presentation Foundation (WPF), and Visual Studio Tools for Office (VSTO) can all be deployed by using ClickOnce. If the following entry is found in the application manifest, deployment will succeed under .NET Framework 4.7.2: <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware></windowsSettings>
- For Windows Forms application, the previous workaround of setting DPI awareness in the application configuration file rather than the application manifest is no longer necessary for ClickOnce deployment to succeed