Fresh from the long-awaited release of its Angular 2 JavaScript framework in mid-September, Google will release Angular 3 in a few short months.
Expected in March, Angular 3 will focus on improved tooling and a reduction in generated code, said Rob Wormald, of the Angular core team and a developer advocate at Google. It will feature a template compiler that provides feedback in an IDE on errors in a template, and it will generate 25 percent less code, thanks to improved compilation and changes in the framework's underlying mechanics.
While more than two years passed between the April 2012 introduction of the 1.0 line and the Sept. 15 debut of the rewritten Angular 2 framework, Angular 3 gets a much-accelerated release schedule. Wormald promised a new major version twice a year from now on. "This is just semantic versioning in action for us and it means that we will every six months have a predictable release schedule," he stated.
Wormald said he was not aware of any features that would be deprecated in Angular 3, but when features are to be deprecated, the Angular team will let developers know ahead of time and keep supporting that feature for two major release cycles.
Unlike Angular 2, Angular 3 is not a rewrite. "There's nobody on the team who ever wants to rewrite a framework again," said Wormald. Using TypeScript, Microsoft's typed superset of JavaScript, Angular 2 was rewritten to allow decoupling of the framework from the DOM to enable use of multiple renderers.
Wednesday, November 9, 2016
Wednesday, August 17, 2016
The MVVM design pattern has been around for quite a while now. It has a lot of strengths when done correctly. But, I believe the time has come to recognize that MVVM has a lot of shortcomings that point to its demise. Since I primarily develop web applications, I will keep this discussion centered on the use of MVVM in web applications. The use of MVVM for desktop may or may not have these same issues.
I realize that for some of you, the very suggestion of dropping MVVM will invoke a negative emotional response. Some very smart people have quit their job at the suggestion that MVVM and its close cousin two-way data-binding, be abandoned in favor of another way. But just for a few minutes, I would like for you to stop treating programming as a religion and consider the possibility that there may be a better way.
The next major implementation of MVVM that I can remember is Knockout. It is the knockout framework that introduced me to MVVM and I have to say it is also the only one I feel like actually got it right. By that I mean that it actually did what it was advertised to do. Maybe that’s because of all the implementations I’ve used, Knockout is the only one that ONLY implemented MVVM rather than making it part of a larger framework.
MVVM is a design pattern that uses two-way data-binding to get data in and out of the presentation layer, referred to as the View1, without the programmer needing to do any more than specifying that this should happen in the view. MVVM is also able to have data elements and functions in the “ViewModel” track changes so that anything that is dependent on other data is automatically recalculated without the programmer having to write a lot of code to make this happen. This creates a model that is able to respond to events in the view, but is primarily data centric rather than event centric has we have often reasoned about our applications in the past.
It sounds great. And when it works it is. But that’s the main problem, it hardly ever works well.
But doing that means we have not moved on to…
This is to say nothing of many frameworks just not working as you would expect them to.
I said, “Given the two models we have to work within the framework we are currently using, MVVM is the best choice.”
However, what we might want to consider is moving to another framework that provides a better design pattern. There are several “One-way” design patterns that intrigue me. The first is the basic Flux pattern that React tends to use. Done correctly, this uses events to achieve the decoupling we all should be striving for. At its core, it is basic MVC.
The second one, which is very flux like, is RxJS. I’m still wrapping my head around how I to use it in an application and honestly don’t know enough about it at this point to say any more than that it looks interesting.
And even if we decided to move away from MVVM, I think using two way data-binding between the view and the ViewModel is good. I just think the ViewModel shouldn’t try to re-compute the values as part of what it does. Leave that to the developer to control. The problem is, trying to get existing systems that implement two-way data-binding to only work at that level would not work correctly.
I realize that for some of you, the very suggestion of dropping MVVM will invoke a negative emotional response. Some very smart people have quit their job at the suggestion that MVVM and its close cousin two-way data-binding, be abandoned in favor of another way. But just for a few minutes, I would like for you to stop treating programming as a religion and consider the possibility that there may be a better way.
History of MVVM
MVVM was originally created by John Gossman to support the XAML syntax used to create Windows™ desktop applications and Silver Light applications. Its main advantage has always been that it provides an easy way to decouple the View code from any business logic that might need to run. Because of this decoupling, our applications become much easier to unit test.The next major implementation of MVVM that I can remember is Knockout. It is the knockout framework that introduced me to MVVM and I have to say it is also the only one I feel like actually got it right. By that I mean that it actually did what it was advertised to do. Maybe that’s because of all the implementations I’ve used, Knockout is the only one that ONLY implemented MVVM rather than making it part of a larger framework.
Definition of MVVM
I’ve written about MVVM before where I’ve explained more completely what MVVM is. But just so we have a working definition of what I mean when I talk about MVVM, let’s define it this way.MVVM is a design pattern that uses two-way data-binding to get data in and out of the presentation layer, referred to as the View1, without the programmer needing to do any more than specifying that this should happen in the view. MVVM is also able to have data elements and functions in the “ViewModel” track changes so that anything that is dependent on other data is automatically recalculated without the programmer having to write a lot of code to make this happen. This creates a model that is able to respond to events in the view, but is primarily data centric rather than event centric has we have often reasoned about our applications in the past.
It sounds great. And when it works it is. But that’s the main problem, it hardly ever works well.
MVVM Done Right is Slow
If you’ve had any experience or paid any attention to the implementation of MVVM using JavaScript, you will realize that the number one problem with MVVM is that it is a memory hog and performs poorly for all but the most trivial of applications. In fact, for all of the popularity of Angular JS, the biggest complaint has been around the implementation of the data-binding. In a large application, you might need to loop through the data multiple times to make sure it has all recalculated correctly. If you just use the framework and let the framework deal with your sloppy code, this can make the system incredibly slow. If you actually pay attention to what you are doing, it takes longer to implement than if you had chosen some other design pattern.But doing that means we have not moved on to…
MVVM is Hard to Implement
Recognizing that looping through the data until it stabilizes may not be a good idea, the framework designers have developed rules such as, “We’ll only run the digest cycle once.” and “We’ll only run it when some user interaction has occurred.” Well, OK. That sounds good. At least now it will be obvious that I have a problem. But this is where the trouble begins. If I can’t rely on my data, and ultimately my view, responding to changes in my data correctly, I am left with having to only partially implementing MVVM so that I can work around these limitations and using other means to make sure my view is updated correctly.This is to say nothing of many frameworks just not working as you would expect them to.
MVVM is Hard to Reason About
Again, in all but the most trivial of applications, and because of the optimizations that various frameworks have tried to implement, MVVM becomes difficult to implement. As I’ve tried to explain MVVM to others and even as I’ve tried to implement it myself, I’ve found that the simple act of keeping the view stuff in the view layer and the data stuff in the data layer and making sure it all updates appropriately has me, at times tearing my hair out. Many times this is caused by incomplete implementations. But if being hard to implement means it is hard to reason about, maybe we shouldn’t be using it to begin with.MVVM is Overkill
But it does work sometimes. In really simple CRUD applications, it works great. None of the problems I’ve mentioned. And this is the great seduction of MVVM. You try it on some small application and you get excited. Like a gateway drug, it lures you in. And when you finally go to implement it on some larger application, you find out that it really doesn’t scale all that well. And on that small app you tried it on, couldn’t you have done that just as easily using another design pattern?Where to Go from Here
As I was reviewing these arguments with a co-worker this week, he asked, “Are you saying we shouldn’t be using MVVM?” And my answer might surprise you.I said, “Given the two models we have to work within the framework we are currently using, MVVM is the best choice.”
However, what we might want to consider is moving to another framework that provides a better design pattern. There are several “One-way” design patterns that intrigue me. The first is the basic Flux pattern that React tends to use. Done correctly, this uses events to achieve the decoupling we all should be striving for. At its core, it is basic MVC.
The second one, which is very flux like, is RxJS. I’m still wrapping my head around how I to use it in an application and honestly don’t know enough about it at this point to say any more than that it looks interesting.
And even if we decided to move away from MVVM, I think using two way data-binding between the view and the ViewModel is good. I just think the ViewModel shouldn’t try to re-compute the values as part of what it does. Leave that to the developer to control. The problem is, trying to get existing systems that implement two-way data-binding to only work at that level would not work correctly.
Tuesday, August 2, 2016
Announcing .NET Framework 4.6.2
Today we are excited to announce the availability of the .NET Framework 4.6.2! Many of the changes are based on your feedback, including those submitted on UserVoice and Connect. Thanks for your continued help and engagement!
The release is packed with lots of great improvements in the following areas:
Long Path Support (
We fixed the 260 character (MAXPATH) file name length limitation in the System.IO APIs. Over 4500 of you voted for this issue on UserVoice!
This limitation doesn’t usually affect consumer applications (for example, loading files out of “My Documents”), but is more common on developer machines that build deeply nested source trees or use specialized tools that also run on Unix (where long paths are much more common).
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
The absence of targeting the .NET Framework 4.6.2 or setting the AppContext switch results in the existing behavior of being blocked from using paths longer than MAXPATH. The behavior is opt-in to maintain backwards compatibility for existing applications.
The following improvements were made to enable long paths:
The .NET Framework 4.6.1 supports FIPS 186-2, which is limited to keys no greater than 1024-bit.
You can take advantage of FIPS 186-3 support by using the new DSACng class, as you can see in the example below.
The DSA base class has also been updated so you can you use FIPS 186-3 support without casting to the new DSACng class. This is the same as the approach that was used for updating RSA and ECDsa implementations, in the two previous .NET Framework releases.
In previous .NET Framework versions, you had to know which subset of properties to set on the ECDiffieHellmanCng class for each of the three different routines.
You need to use the concrete implementation classes, such as AesCng to use this new capability, as opposed to the more common factory approach, Aes.Create(). This requirement is due to key names and key providers being implementation-specific
Persisted-key symmetric encryption has been added for the AES and 3DES algorithms, in the AesCng TripleDESCng classes, respectively.
The new SignedXML URI constants have been added as new SignedXml fields. The new fields are shown below.
Any programs which have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults the CryptoConfig registration should no longer be necessary.
The debugging experience in Visual Studio relies on the Common Language Runtime debugging APIs for low-level interaction with your code. Today, the
In this release, we extended the CLR debugging APIs to enable the debugger to request more information and perform additional analysis when a
Secure Sockets Layer (SSL) and TLS 1.0 are no longer recommended or supported by some organizations. For example, the Payment Card Industry Security Standards Council is in the process of requiring TLS 1.1 or higher for online transactions that meet their specifications.
ClickOnce continues to support TLS 1.0 for applications that do not or cannot upgrade, for compatibility. We recommend analyzing all of your uses of SSL and TLS 1.0. See the KB articles for links to download the hotfix .NET Framework versions 4.6, 4.6.1 and 4.5.2.
In previous versions, ClickOnce deployments were terminated with an access denied error when applications where hosted this way.
You can see that localized resx files have been placed in the ‘App_LocalResources’ folder, following the new convention, in the example below:
You can also plug in your own stringlocalizer provider to store the localized strings in another location or file type.
In previous .NET Framework versions, you would need to specify
You can now use async APIs with Output Caching by implementing a new interface called
The .NET Framework Data Provider for SQL Server (System.Data.SqlClient) introduces two important enhancements for Always Encrypted around performance and security.
The “Best Match” pipe is particularly useful if a WCF client app tries to connect to the wrong URI when using the default “First Match” behavior. In certain situations, when there is more than one WCF Services listening on named pipes, WCF clients using “First Match” could be connected to a wrong service. This could happen if some of the services is hosted by an administrator account.
To enable this feature, you can add the following AppSetting to your client application’s App.config or Web.config file:
You can enable this feature by adding the following AppSetting to the app.config file:
SSL3 was removed as a default protocol since it is not longer considered secure. While not recommended, one of the following configuration mechanisms can be used to add SSL 3 back to the list of negotiated protocols if it is required for your deployment:
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
You can also enable this functionality programmatically:
The following example demonstrates OperationContext.Current flowing correctly across a thread transition:
Previously, the internal implementation of OperationContext.Current was to store the CurrentContext using a ThreadStatic variable, which used the thread’s local storage to store the data associated with CurrentContext. If there was a change in the execution context of the method call (i.e. a thread change caused by awaiting another operation), any subsequent calls would be operating on a different thread without a reference to the original value. With the fix, the second call to OperationContext.Current will deliver the expected value even though threadId1 and threadId2 may be different.
The feature includes two new properties on the GroupDescription class:
For example, suppose an application wants to group data by Age, sorting the groups in ascending order and the items within each group by LastName.
With this new feature the application can now declare:
Prior to this feature, the application would declare:
You can learn more about how to enable your WPF application to become per-monitor DPI aware in the WPF samples and developer guide on GitHub.
In previous versions, you would have to write additional native code to enable per-monitor DPI awareness in WPF applications.
In previous versions, WPF applications did not implicitly support the invocation or dismissal of the touch keyboard without disabling WPF stylus/touch support. This is due to a change in the way the touch keyboard tracks focus in applications starting in Windows 8.
Source: https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
The release is packed with lots of great improvements in the following areas:
- Base Class Library
- Common Language Runtime
- ClickOnce
- ASP.NET
- SQL
- Windows Presentation Foundation
- Windows Communication Foundation
Download Now
You can download the .NET Framework 4.6.2 now:- .NET Framework 4.6.2 Web Installer – Quickest Install. Requires an internet connection.
- .NET Framework 4.6.2 Offline Installer – All-inclusive installer (includes all language packs). Does not require an internet connection.
- .NET Framework 4.6.2 Developer Pack – For development and build environments (includes Offline Installer and the 4.6.2 targeting pack). Does not require an internet connection.
Base Class Library (BCL)
The following improvements have been made in the BCL.
Long Path Support (MAXPATH)
We fixed the 260 character (MAXPATH) file name length limitation in the System.IO APIs. Over 4500 of you voted for this issue on UserVoice!This limitation doesn’t usually affect consumer applications (for example, loading files out of “My Documents”), but is more common on developer machines that build deeply nested source trees or use specialized tools that also run on Unix (where long paths are much more common).
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.6.2"/> | |
| </startup> | |
| </configuration> |
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.5.2"/> | |
| </startup> | |
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" /> | |
| </runtime> | |
| </configuration> |
The following improvements were made to enable long paths:
- Allow paths that are greater than 260 character (MAX_PATH). Paths that are longer than
MAX_PATHare allowed by the BCL. The BCL APIs rely on the underlying Win32 file APIs for limitation checks. - Enable extended path syntax and file namespaces (
\\?\,\\.\). Windows exposes multiple file namespaces that enable alternate path schemes, such as the extended path syntax, which allows paths to just over 32k characters. The BCL now supports these paths, such as the following:\\?\very long path. The .NET Framework now primarily relies on Windows for path normalization, treating it as the “source of truth”, to avoid inadvertently blocking legitimate paths. The extended path syntax is a good workaround for Windows versions that don’t support long paths using the regular form (for example, `C:\very long path’). - Performance Improvements. The adoption of Windows path normalization and the reduction of similar logic in the BCL has resulted in overall performance improvements for logic related to file paths. Other related performance improvements have also been made.
X509 Certificates Now Support FIPS 186-3 Digital Signature Algorithm
The .NET Framework 4.6.2 adds support for FIPS 186-3 Digital Signature Algorithm (DSA). This support enables X509 certificates with keys that exceed 1024-bit. It also enables computing signatures with the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512).The .NET Framework 4.6.1 supports FIPS 186-2, which is limited to keys no greater than 1024-bit.
You can take advantage of FIPS 186-3 support by using the new DSACng class, as you can see in the example below.
The DSA base class has also been updated so you can you use FIPS 186-3 support without casting to the new DSACng class. This is the same as the approach that was used for updating RSA and ECDsa implementations, in the two previous .NET Framework releases.
Improved Usability of Elliptic Curve Diffie-Hellman Key Derivation Routines
The usability of the ECDiffieHellmanCng class has been improved. The .NET Framework Elliptic Curve Diffie-Hellman (ECDH) Key Agreement implementation includes three different Key Derivation Function (KDF) routines. These KDF routines are now represented and supported by three different methods, as you can see in the example below.In previous .NET Framework versions, you had to know which subset of properties to set on the ECDiffieHellmanCng class for each of the three different routines.
Support for Persisted-Key Symmetric Encryption
The Windows Cryptography Library (CNG) supports storing persisted symmetric keys on software and hardware devices. The .NET Framework now exposes this CNG capability, as you can see demonstrated in the example below.You need to use the concrete implementation classes, such as AesCng to use this new capability, as opposed to the more common factory approach, Aes.Create(). This requirement is due to key names and key providers being implementation-specific
Persisted-key symmetric encryption has been added for the AES and 3DES algorithms, in the AesCng TripleDESCng classes, respectively.
SignedXml Support for SHA-2 Hashing
The .NET Framework SignedXml implementation now supports the following SHA-2 Hashing algorithms:- RSA-SHA256
- RSA-SHA384
- RSA-SHA512 PKCS#1 signature methods
- SHA256
- SHA384
- SHA512 reference digest algorithms
The new SignedXML URI constants have been added as new SignedXml fields. The new fields are shown below.
Any programs which have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults the CryptoConfig registration should no longer be necessary.
Common Language Runtime (CLR)
The following improvements have been made in the CLR.NullReferenceException Improvements
You have probably experienced and investigated the cause of a NullReferenceException. We are part-way through partnering with the Visual Studio team to provide a better debugging experience for null references in a future Visual Studio release.The debugging experience in Visual Studio relies on the Common Language Runtime debugging APIs for low-level interaction with your code. Today, the
NullReferenceException experience in Visual Studio looks like this:In this release, we extended the CLR debugging APIs to enable the debugger to request more information and perform additional analysis when a
NullReferenceException occurs. Using this information, a debugger will be able to determine which reference is null and provide this information to you, making your job easier.ClickOnce
The following improvements have been made in ClickOnce.Transport Layer Security (TLS) 1.1 and 1.2 Support
We added support for TLS 1.1 and 1.2 protocols in ClickOnce for .NET Framework versions 4.6.2, 4.6.1, 4.6 and 4.5.2. We would like to thank those who voted for it on UserVoice! You do not need to do any extra steps to enable TLS 1.1 or 1.2 support as ClickOnce will automatically detect which TLS protocol is required at runtime.Secure Sockets Layer (SSL) and TLS 1.0 are no longer recommended or supported by some organizations. For example, the Payment Card Industry Security Standards Council is in the process of requiring TLS 1.1 or higher for online transactions that meet their specifications.
ClickOnce continues to support TLS 1.0 for applications that do not or cannot upgrade, for compatibility. We recommend analyzing all of your uses of SSL and TLS 1.0. See the KB articles for links to download the hotfix .NET Framework versions 4.6, 4.6.1 and 4.5.2.
Client Certificate Support
ClickOnce applications can now be hosted in virtual directories with SSL enabled and with client certificates required. In that configuration, end users will be prompted to select their certificate when accessing an application. ClickOnce will not prompt for a certificate if theClient Certificates setting is set to “Ignore”.In previous versions, ClickOnce deployments were terminated with an access denied error when applications where hosted this way.
ASP.NET
The following improvements have been made in ASP.NET. See Announcing ASP.NET Core 1.0 to learn about improvements in ASP.NET Core.DataAnnotation Localization
Localization is now much easier when using model binding andDataAnnotiation validation. ASP.NET has adopted a simple convention for resx resource files that contain DataAnnotation validation messages:- Located in the
App_LocalResourcesfolder. - Follow the
DataAnnotation.Localization.{locale}.resxnaming convention.
DataAnnotation attributes in your model file just like you would in an un-localized application. For the ErrorMessage, you specify the name that you will use in resx file, as you can see in the example below:| public class ContactInfo | |
| { | |
| [Required(ErrorMessage = "Your email address is invalid")] | |
| [Display(Name = "User Email")] | |
| public int Email { get; set; } | |
| [Required(ErrorMessage = "Your phone number is invalid")] | |
| [Display(Name = "User Phone")] | |
| public int Phone { get; set; } | |
| } |
You can see that localized resx files have been placed in the ‘App_LocalResources’ folder, following the new convention, in the example below:
You can also plug in your own stringlocalizer provider to store the localized strings in another location or file type.
In previous .NET Framework versions, you would need to specify
ErrorMessageResourceType and ErrorMessageResourceNamevalues, as you can see in the example below.| public class User | |
| { | |
| [Required(ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "FirstName_Required")] | |
| [StringLength(50, ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "FirstName_StringLength")] | |
| public sstring FirstName { get; set; } | |
| [Required(ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "LastName_Required")] | |
| [StringLength(50, ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "LastName_StringLength")] | |
| public sstring LastName { get; set; } | |
| } |
Async Improvements
SessionStateModule and Output-Cache Module have been improved to enable async scenarios. The team is working on releasing async versions of both modules via NuGet, which will need to be imported into an existing project. Both NuGet packages are anticipated to release within the coming weeks. We will update this post when that happens.SessionStateModule Interfaces
Session State allows you to store and retrieve user session data as a user navigates an ASP.NET site. You can now create your own async Session State Module implementation using the newISessionStateModule interface, enabling you to store session data in your own way and use async methods.Output-Cache Module
Output Caching can dramatically improve the performance of an ASP.NET application by caching the result returned from a controller action to avoid unnecessarily generating the same content for every request.You can now use async APIs with Output Caching by implementing a new interface called
OutputCacheProviderAsync. Doing so will reduce thread-blocking on a web server and improve scalability of an ASP.NET service.SQL
The following improvements have been made in the SQL client.Always Encrypted Enhancements
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers that are stored in a database. It allows clients to encrypt sensitive data inside client applications, never revealing the encryption keys to the database engine. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access).The .NET Framework Data Provider for SQL Server (System.Data.SqlClient) introduces two important enhancements for Always Encrypted around performance and security.
Performance
To improve performance of parameterized queries against encrypted database columns, encryption metadata for query parameters is now cached. Database clients retrieve parameter metadata from the server only once when theSqlConnection::ColumnEncryptionQueryMetadataCacheEnabled property is set to true (the default), even if the same query is called multiple times.Security
Column encryption key entries in the key cache are now evicted after a configurable time interval. The time interval can be set using the SqlConnection::ColumnEncryptionKeyCacheTtl property.Windows Communication Foundation (WCF)
The following improvements have been made in WCF.NetNamedPipeBinding Best Match
In .NET 4.6.2, NetNamedPipeBinding has been enhanced to support a new pipe lookup, known as “Best Match”. When using “Best Match”, the NetNamedPipeBinding service will force clients to search for the service listening at the best matching URI to their requested endpoint, rather than the first matching service found.The “Best Match” pipe is particularly useful if a WCF client app tries to connect to the wrong URI when using the default “First Match” behavior. In certain situations, when there is more than one WCF Services listening on named pipes, WCF clients using “First Match” could be connected to a wrong service. This could happen if some of the services is hosted by an administrator account.
To enable this feature, you can add the following AppSetting to your client application’s App.config or Web.config file:
| <configuration> | |
| <appSettings> | |
| <add key="wcf:useBestMatchNamedPipeUri" value="true" /> | |
| </appSettings> | |
| </configuration> |
DataContractJsonSerializer Improvements
The DataContractJsonSerializer has been improved to better support multiple daylight saving time adjustment rules. When enabled, DataContractJsonSerializer will use the TimeZoneInfo class instead of the TimeZone class. The TimeZoneInfo class supports multiple adjustment rules, which makes it possible to work with historic time zone data. This is useful when a time zone has different daylight saving time adjustment rules, such as (UTC+2) Istanbul.You can enable this feature by adding the following AppSetting to the app.config file:
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" /> | |
| </runtime> |
TransportDefaults No Longer Supports SSL 3
The SSL 3 protocol is no longer a default protocol used for negotiating a secure connection when using NetTcp with transport security and a credential type of certificate. In most cases there should be no impact to existing applications, since TLS 1.0 has always been included in the default protocol list for NetTcp. All existing clients should be able to negotiate a connection using at least TLS 1.0.SSL3 was removed as a default protocol since it is not longer considered secure. While not recommended, one of the following configuration mechanisms can be used to add SSL 3 back to the list of negotiated protocols if it is required for your deployment:
- SslStreamSecurityBindingElement.SslProtocols Property
- TcpTransportSecurity.SslProtocols Property
<transport>section of<netTcpBinding><sslStreamSecurity>section of<customBinding>
Transport Security for Windows Cryptography Library (CNG)
Transport Security now supports certificates stored using the Windows cryptography library (CNG). Currently, this support is limited to using certificates with a public key which has an exponent no more than 32bits in length.This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.5.2"/> | |
| </startup> | |
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableCngCertificates=false" /> | |
| </runtime> | |
| </configuration> |
| private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificates"; | |
| AppContext.SetSwitch(DisableCngCertificates, false); |
OperationContext.Current Async Improvements
WCF now has the ability to include OperationContext.Current with ExecutionContext so that the OperationContext flows through asynchronous continuations. With this improvement, WCF allows CurrentContext to propagate from one thread to another thread. This means that even if there’s a context switch between calls to OperationContext.Current, it’s value will flow correctly throughout the execution of the method.The following example demonstrates OperationContext.Current flowing correctly across a thread transition:
| public async Task InvokeCallbackWithDelay(int delay) | |
| { | |
| int threadId1 = Thread.CurrentThread.ManagedThreadId; | |
| OperationContext.Current.GetCallbackChannel<IServiceCallback>().TheCallback("One"); | |
| await Task.Delay(delay); | |
| int threadId2 = Thread.CurrentThread.ManagedThreadId; | |
| OperationContext.Current.GetCallbackChannel<IServiceCallback>().TheCallback("Two"); | |
| } |
Windows Presentation Foundation (WPF)
The following improvements have been made in WPF.Group Sorting
An application that requests a CollectionView to group data can now explicitly declare how to sort the groups. This overcomes some unintuitive ordering that can arise when the application dynamically adds or removes groups, or when the application changes the value of item properties involved in grouping. It can also improve the performance of the group creation process, by moving comparisons of the grouping properties from the sort of the full collection to the sort of the groups.The feature includes two new properties on the GroupDescription class:
SortDescriptions and CustomSort. These properties describe how to sort the collection of groups produced by the GroupDescription, analogous to the way the properties onListCollectionView with the same names describe how to sort the data items. There are also two new static properties on the PropertyGroupDescription class for use in the most common cases: CompareNameAscending and CompareNameDescending.For example, suppose an application wants to group data by Age, sorting the groups in ascending order and the items within each group by LastName.
With this new feature the application can now declare:
| <GroupDescriptions> | |
| <PropertyGroupDescription | |
| PropertyName=”Age” | |
| CustomSort= | |
| ”{x:Static PropertyGroupDescription.CompareNamesAscending}”/> | |
| </PropertyGroupDescription> | |
| </GroupDescriptions> | |
| <SortDescriptions> | |
| <SortDescription PropertyName=”LastName”/> | |
| </SortDescriptions> |
| <GroupDescriptions> | |
| <PropertyGroupDescription PropertyName=”Age”/> | |
| </GroupDescriptions> | |
| <SortDescriptions> | |
| <SortDescription PropertyName=”Age”/> | |
| <SortDescription PropertyName=”LastName”/> | |
| </SortDescriptions> |
Per-Monitor DPI Support
WPF applications are now enabled for per-monitor DPI awareness. This improvement is critical for scenarios where multiple displays of varying DPI level are attached to a single machine. As all or part of a WPF application is transitioned between monitors, the expected behavior is for WPF to automatically match the DPI of the app to the screen. It now does.You can learn more about how to enable your WPF application to become per-monitor DPI aware in the WPF samples and developer guide on GitHub.
In previous versions, you would have to write additional native code to enable per-monitor DPI awareness in WPF applications.
Soft Keyboard Support
Soft Keyboard support enables automatic invocation and dismissal of the touch keyboard in WPF applications without disabling WPF stylus/touch support on Windows 10.In previous versions, WPF applications did not implicitly support the invocation or dismissal of the touch keyboard without disabling WPF stylus/touch support. This is due to a change in the way the touch keyboard tracks focus in applications starting in Windows 8.
Source: https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/
Thursday, May 12, 2016
Announcing .NET Framework 4.6.2
Today we are excited to announce the availability of the .NET Framework 4.6.2! Many of the changes are based on your feedback, including those submitted on UserVoice and Connect. Thanks for your continued help and engagement!
The release is packed with lots of great improvements in the following areas:
Long Path Support (
We fixed the 260 character (MAXPATH) file name length limitation in the System.IO APIs. Over 4500 of you voted for this issue on UserVoice!
This limitation doesn’t usually affect consumer applications (for example, loading files out of “My Documents”), but is more common on developer machines that build deeply nested source trees or use specialized tools that also run on Unix (where long paths are much more common).
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
The absence of targeting the .NET Framework 4.6.2 or setting the AppContext switch results in the existing behavior of being blocked from using paths longer than MAXPATH. The behavior is opt-in to maintain backwards compatibility for existing applications.
The following improvements were made to enable long paths:
The .NET Framework 4.6.1 supports FIPS 186-2, which is limited to keys no greater than 1024-bit.
You can take advantage of FIPS 186-3 support by using the new DSACng class, as you can see in the example below.
The DSA base class has also been updated so you can you use FIPS 186-3 support without casting to the new DSACng class. This is the same as the approach that was used for updating RSA and ECDsa implementations, in the two previous .NET Framework releases.
In previous .NET Framework versions, you had to know which subset of properties to set on the ECDiffieHellmanCng class for each of the three different routines.
You need to use the concrete implementation classes, such as AesCng to use this new capability, as opposed to the more common factory approach, Aes.Create(). This requirement is due to key names and key providers being implementation-specific
Persisted-key symmetric encryption has been added for the AES and 3DES algorithms, in the AesCng TripleDESCng classes, respectively.
The new SignedXML URI constants have been added as new SignedXml fields. The new fields are shown below.
Any programs which have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults the CryptoConfig registration should no longer be necessary.
The debugging experience in Visual Studio relies on the Common Language Runtime debugging APIs for low-level interaction with your code. Today, the
In this release, we extended the CLR debugging APIs to enable the debugger to request more information and perform additional analysis when a
Secure Sockets Layer (SSL) and TLS 1.0 are no longer recommended or supported by some organizations. For example, the Payment Card Industry Security Standards Council is in the process of requiring TLS 1.1 or higher for online transactions that meet their specifications.
ClickOnce continues to support TLS 1.0 for applications that do not or cannot upgrade, for compatibility. We recommend analyzing all of your uses of SSL and TLS 1.0. See the KB articles for links to download the hotfix .NET Framework versions 4.6, 4.6.1 and 4.5.2.
In previous versions, ClickOnce deployments were terminated with an access denied error when applications where hosted this way.
You can see that localized resx files have been placed in the ‘App_LocalResources’ folder, following the new convention, in the example below:
You can also plug in your own stringlocalizer provider to store the localized strings in another location or file type.
In previous .NET Framework versions, you would need to specify
You can now use async APIs with Output Caching by implementing a new interface called
The .NET Framework Data Provider for SQL Server (System.Data.SqlClient) introduces two important enhancements for Always Encrypted around performance and security.
The “Best Match” pipe is particularly useful if a WCF client app tries to connect to the wrong URI when using the default “First Match” behavior. In certain situations, when there is more than one WCF Services listening on named pipes, WCF clients using “First Match” could be connected to a wrong service. This could happen if some of the services is hosted by an administrator account.
To enable this feature, you can add the following AppSetting to your client application’s App.config or Web.config file:
You can enable this feature by adding the following AppSetting to the app.config file:
SSL3 was removed as a default protocol since it is not longer considered secure. While not recommended, one of the following configuration mechanisms can be used to add SSL 3 back to the list of negotiated protocols if it is required for your deployment:
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
You can also enable this functionality programmatically:
The following example demonstrates OperationContext.Current flowing correctly across a thread transition:
Previously, the internal implementation of OperationContext.Current was to store the CurrentContext using a ThreadStatic variable, which used the thread’s local storage to store the data associated with CurrentContext. If there was a change in the execution context of the method call (i.e. a thread change caused by awaiting another operation), any subsequent calls would be operating on a different thread without a reference to the original value. With the fix, the second call to OperationContext.Current will deliver the expected value even though threadId1 and threadId2 may be different.
The feature includes two new properties on the GroupDescription class:
For example, suppose an application wants to group data by Age, sorting the groups in ascending order and the items within each group by LastName.
With this new feature the application can now declare:
Prior to this feature, the application would declare:
You can learn more about how to enable your WPF application to become per-monitor DPI aware in the WPF samples and developer guide on GitHub.
In previous versions, you would have to write additional native code to enable per-monitor DPI awareness in WPF applications.
In previous versions, WPF applications did not implicitly support the invocation or dismissal of the touch keyboard without disabling WPF stylus/touch support. This is due to a change in the way the touch keyboard tracks focus in applications starting in Windows 8.
The release is packed with lots of great improvements in the following areas:
- Base Class Library
- Common Language Runtime
- ClickOnce
- ASP.NET
- SQL
- Windows Presentation Foundation
- Windows Communication Foundation
Download Now
You can download the .NET Framework 4.6.2 now:- .NET Framework 4.6.2 Web Installer – Quickest Install. Requires an internet connection.
- .NET Framework 4.6.2 Offline Installer – All-inclusive installer (includes all language packs). Does not require an internet connection.
- .NET Framework 4.6.2 Developer Pack – For development and build environments (includes Offline Installer and the 4.6.2 targeting pack). Does not require an internet connection.
Base Class Library (BCL)
The following improvements have been made in the BCL.
Long Path Support (MAXPATH)
We fixed the 260 character (MAXPATH) file name length limitation in the System.IO APIs. Over 4500 of you voted for this issue on UserVoice!This limitation doesn’t usually affect consumer applications (for example, loading files out of “My Documents”), but is more common on developer machines that build deeply nested source trees or use specialized tools that also run on Unix (where long paths are much more common).
This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.6.2"/> | |
| </startup> | |
| </configuration> |
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.5.2"/> | |
| </startup> | |
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" /> | |
| </runtime> | |
| </configuration> |
The following improvements were made to enable long paths:
- Allow paths that are greater than 260 character (MAX_PATH). Paths that are longer than
MAX_PATHare allowed by the BCL. The BCL APIs rely on the underlying Win32 file APIs for limitation checks. - Enable extended path syntax and file namespaces (
\\?\,\\.\). Windows exposes multiple file namespaces that enable alternate path schemes, such as the extended path syntax, which allows paths to just over 32k characters. The BCL now supports these paths, such as the following:\\?\very long path. The .NET Framework now primarily relies on Windows for path normalization, treating it as the “source of truth”, to avoid inadvertently blocking legitimate paths. The extended path syntax is a good workaround for Windows versions that don’t support long paths using the regular form (for example, `C:\very long path’). - Performance Improvements. The adoption of Windows path normalization and the reduction of similar logic in the BCL has resulted in overall performance improvements for logic related to file paths. Other related performance improvements have also been made.
X509 Certificates Now Support FIPS 186-3 Digital Signature Algorithm
The .NET Framework 4.6.2 adds support for FIPS 186-3 Digital Signature Algorithm (DSA). This support enables X509 certificates with keys that exceed 1024-bit. It also enables computing signatures with the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512).The .NET Framework 4.6.1 supports FIPS 186-2, which is limited to keys no greater than 1024-bit.
You can take advantage of FIPS 186-3 support by using the new DSACng class, as you can see in the example below.
The DSA base class has also been updated so you can you use FIPS 186-3 support without casting to the new DSACng class. This is the same as the approach that was used for updating RSA and ECDsa implementations, in the two previous .NET Framework releases.
Improved Usability of Elliptic Curve Diffie-Hellman Key Derivation Routines
The usability of the ECDiffieHellmanCng class has been improved. The .NET Framework Elliptic Curve Diffie-Hellman (ECDH) Key Agreement implementation includes three different Key Derivation Function (KDF) routines. These KDF routines are now represented and supported by three different methods, as you can see in the example below.In previous .NET Framework versions, you had to know which subset of properties to set on the ECDiffieHellmanCng class for each of the three different routines.
Support for Persisted-Key Symmetric Encryption
The Windows Cryptography Library (CNG) supports storing persisted symmetric keys on software and hardware devices. The .NET Framework now exposes this CNG capability, as you can see demonstrated in the example below.You need to use the concrete implementation classes, such as AesCng to use this new capability, as opposed to the more common factory approach, Aes.Create(). This requirement is due to key names and key providers being implementation-specific
Persisted-key symmetric encryption has been added for the AES and 3DES algorithms, in the AesCng TripleDESCng classes, respectively.
SignedXml Support for SHA-2 Hashing
The .NET Framework SignedXml implementation now supports the following SHA-2 Hashing algorithms:- RSA-SHA256
- RSA-SHA384
- RSA-SHA512 PKCS#1 signature methods
- SHA256
- SHA384
- SHA512 reference digest algorithms
The new SignedXML URI constants have been added as new SignedXml fields. The new fields are shown below.
Any programs which have registered a custom SignatureDescription handler into CryptoConfig to add support for these algorithms will continue to function as they did in the past, but since there are now platform defaults the CryptoConfig registration should no longer be necessary.
Common Language Runtime (CLR)
The following improvements have been made in the CLR.NullReferenceException Improvements
You have probably experienced and investigated the cause of a NullReferenceException. We are part-way through partnering with the Visual Studio team to provide a better debugging experience for null references in a future Visual Studio release.The debugging experience in Visual Studio relies on the Common Language Runtime debugging APIs for low-level interaction with your code. Today, the
NullReferenceException experience in Visual Studio looks like this:In this release, we extended the CLR debugging APIs to enable the debugger to request more information and perform additional analysis when a
NullReferenceException occurs. Using this information, a debugger will be able to determine which reference is null and provide this information to you, making your job easier.ClickOnce
The following improvements have been made in ClickOnce.Transport Layer Security (TLS) 1.1 and 1.2 Support
We added support for TLS 1.1 and 1.2 protocols in ClickOnce for .NET Framework versions 4.6.2, 4.6.1, 4.6 and 4.5.2. We would like to thank those who voted for it on UserVoice! You do not need to do any extra steps to enable TLS 1.1 or 1.2 support as ClickOnce will automatically detect which TLS protocol is required at runtime.Secure Sockets Layer (SSL) and TLS 1.0 are no longer recommended or supported by some organizations. For example, the Payment Card Industry Security Standards Council is in the process of requiring TLS 1.1 or higher for online transactions that meet their specifications.
ClickOnce continues to support TLS 1.0 for applications that do not or cannot upgrade, for compatibility. We recommend analyzing all of your uses of SSL and TLS 1.0. See the KB articles for links to download the hotfix .NET Framework versions 4.6, 4.6.1 and 4.5.2.
Client Certificate Support
ClickOnce applications can now be hosted in virtual directories with SSL enabled and with client certificates required. In that configuration, end users will be prompted to select their certificate when accessing an application. ClickOnce will not prompt for a certificate if theClient Certificates setting is set to “Ignore”.In previous versions, ClickOnce deployments were terminated with an access denied error when applications where hosted this way.
ASP.NET
The following improvements have been made in ASP.NET. See Announcing ASP.NET Core 1.0 to learn about improvements in ASP.NET Core.DataAnnotation Localization
Localization is now much easier when using model binding andDataAnnotiation validation. ASP.NET has adopted a simple convention for resx resource files that contain DataAnnotation validation messages:- Located in the
App_LocalResourcesfolder. - Follow the
DataAnnotation.Localization.{locale}.resxnaming convention.
DataAnnotation attributes in your model file just like you would in an un-localized application. For the ErrorMessage, you specify the name that you will use in resx file, as you can see in the example below:| public class ContactInfo | |
| { | |
| [Required(ErrorMessage = "Your email address is invalid")] | |
| [Display(Name = "User Email")] | |
| public int Email { get; set; } | |
| [Required(ErrorMessage = "Your phone number is invalid")] | |
| [Display(Name = "User Phone")] | |
| public int Phone { get; set; } | |
| } |
You can see that localized resx files have been placed in the ‘App_LocalResources’ folder, following the new convention, in the example below:
You can also plug in your own stringlocalizer provider to store the localized strings in another location or file type.
In previous .NET Framework versions, you would need to specify
ErrorMessageResourceType and ErrorMessageResourceNamevalues, as you can see in the example below.| public class User | |
| { | |
| [Required(ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "FirstName_Required")] | |
| [StringLength(50, ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "FirstName_StringLength")] | |
| public sstring FirstName { get; set; } | |
| [Required(ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "LastName_Required")] | |
| [StringLength(50, ErrorMessageResourceType = typeof(ModelResources), | |
| ErrorMessageResourceName = "LastName_StringLength")] | |
| public sstring LastName { get; set; } | |
| } |
Async Improvements
SessionStateModule and Output-Cache Module have been improved to enable async scenarios. The team is working on releasing async versions of both modules via NuGet, which will need to be imported into an existing project. Both NuGet packages are anticipated to release within the coming weeks. We will update this post when that happens.SessionStateModule Interfaces
Session State allows you to store and retrieve user session data as a user navigates an ASP.NET site. You can now create your own async Session State Module implementation using the newISessionStateModule interface, enabling you to store session data in your own way and use async methods.Output-Cache Module
Output Caching can dramatically improve the performance of an ASP.NET application by caching the result returned from a controller action to avoid unnecessarily generating the same content for every request.You can now use async APIs with Output Caching by implementing a new interface called
OutputCacheProviderAsync. Doing so will reduce thread-blocking on a web server and improve scalability of an ASP.NET service.SQL
The following improvements have been made in the SQL client.Always Encrypted Enhancements
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers that are stored in a database. It allows clients to encrypt sensitive data inside client applications, never revealing the encryption keys to the database engine. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access).The .NET Framework Data Provider for SQL Server (System.Data.SqlClient) introduces two important enhancements for Always Encrypted around performance and security.
Performance
To improve performance of parameterized queries against encrypted database columns, encryption metadata for query parameters is now cached. Database clients retrieve parameter metadata from the server only once when theSqlConnection::ColumnEncryptionQueryMetadataCacheEnabled property is set to true (the default), even if the same query is called multiple times.Security
Column encryption key entries in the key cache are now evicted after a configurable time interval. The time interval can be set using the SqlConnection::ColumnEncryptionKeyCacheTtl property.Windows Communication Foundation (WCF)
The following improvements have been made in WCF.NetNamedPipeBinding Best Match
In .NET 4.6.2, NetNamedPipeBinding has been enhanced to support a new pipe lookup, known as “Best Match”. When using “Best Match”, the NetNamedPipeBinding service will force clients to search for the service listening at the best matching URI to their requested endpoint, rather than the first matching service found.The “Best Match” pipe is particularly useful if a WCF client app tries to connect to the wrong URI when using the default “First Match” behavior. In certain situations, when there is more than one WCF Services listening on named pipes, WCF clients using “First Match” could be connected to a wrong service. This could happen if some of the services is hosted by an administrator account.
To enable this feature, you can add the following AppSetting to your client application’s App.config or Web.config file:
| <configuration> | |
| <appSettings> | |
| <add key="wcf:useBestMatchNamedPipeUri" value="true" /> | |
| </appSettings> | |
| </configuration> |
DataContractJsonSerializer Improvements
The DataContractJsonSerializer has been improved to better support multiple daylight saving time adjustment rules. When enabled, DataContractJsonSerializer will use the TimeZoneInfo class instead of the TimeZone class. The TimeZoneInfo class supports multiple adjustment rules, which makes it possible to work with historic time zone data. This is useful when a time zone has different daylight saving time adjustment rules, such as (UTC+2) Istanbul.You can enable this feature by adding the following AppSetting to the app.config file:
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" /> | |
| </runtime> |
TransportDefaults No Longer Supports SSL 3
The SSL 3 protocol is no longer a default protocol used for negotiating a secure connection when using NetTcp with transport security and a credential type of certificate. In most cases there should be no impact to existing applications, since TLS 1.0 has always been included in the default protocol list for NetTcp. All existing clients should be able to negotiate a connection using at least TLS 1.0.SSL3 was removed as a default protocol since it is not longer considered secure. While not recommended, one of the following configuration mechanisms can be used to add SSL 3 back to the list of negotiated protocols if it is required for your deployment:
- SslStreamSecurityBindingElement.SslProtocols Property
- TcpTransportSecurity.SslProtocols Property
<transport>section of<netTcpBinding><sslStreamSecurity>section of<customBinding>
Transport Security for Windows Cryptography Library (CNG)
Transport Security now supports certificates stored using the Windows cryptography library (CNG). Currently, this support is limited to using certificates with a public key which has an exponent no more than 32bits in length.This new capability is enabled for applications that target the .NET Framework 4.6.2 (or later). You can configure an application to target the .NET Framework 4.6.2 with the following app.config or web.config configuration file:
You can opt applications that target an earlier version of the .NET Framework into using this functionality by setting an AppContext switch, as demonstrated in the following configuration file. The switch will only be honored when an application in running on the .NET Framework 4.6.2 (or later).
| <?xml version="1.0" encoding="utf-8" ?> | |
| <configuration> | |
| <startup> | |
| <supportedRuntime version=".NETFramework,Version=v4.5.2"/> | |
| </startup> | |
| <runtime> | |
| <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableCngCertificates=false" /> | |
| </runtime> | |
| </configuration> |
| private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificates"; | |
| AppContext.SetSwitch(DisableCngCertificates, false); |
OperationContext.Current Async Improvements
WCF now has the ability to include OperationContext.Current with ExecutionContext so that the OperationContext flows through asynchronous continuations. With this improvement, WCF allows CurrentContext to propagate from one thread to another thread. This means that even if there’s a context switch between calls to OperationContext.Current, it’s value will flow correctly throughout the execution of the method.The following example demonstrates OperationContext.Current flowing correctly across a thread transition:
| public async Task InvokeCallbackWithDelay(int delay) | |
| { | |
| int threadId1 = Thread.CurrentThread.ManagedThreadId; | |
| OperationContext.Current.GetCallbackChannel<IServiceCallback>().TheCallback("One"); | |
| await Task.Delay(delay); | |
| int threadId2 = Thread.CurrentThread.ManagedThreadId; | |
| OperationContext.Current.GetCallbackChannel<IServiceCallback>().TheCallback("Two"); | |
| } |
Windows Presentation Foundation (WPF)
The following improvements have been made in WPF.Group Sorting
An application that requests a CollectionView to group data can now explicitly declare how to sort the groups. This overcomes some unintuitive ordering that can arise when the application dynamically adds or removes groups, or when the application changes the value of item properties involved in grouping. It can also improve the performance of the group creation process, by moving comparisons of the grouping properties from the sort of the full collection to the sort of the groups.The feature includes two new properties on the GroupDescription class:
SortDescriptions and CustomSort. These properties describe how to sort the collection of groups produced by the GroupDescription, analogous to the way the properties onListCollectionView with the same names describe how to sort the data items. There are also two new static properties on the PropertyGroupDescription class for use in the most common cases: CompareNameAscending and CompareNameDescending.For example, suppose an application wants to group data by Age, sorting the groups in ascending order and the items within each group by LastName.
With this new feature the application can now declare:
| <GroupDescriptions> | |
| <PropertyGroupDescription | |
| PropertyName=”Age” | |
| CustomSort= | |
| ”{x:Static PropertyGroupDescription.CompareNamesAscending}”/> | |
| </PropertyGroupDescription> | |
| </GroupDescriptions> | |
| <SortDescriptions> | |
| <SortDescription PropertyName=”LastName”/> | |
| </SortDescriptions> |
| <GroupDescriptions> | |
| <PropertyGroupDescription PropertyName=”Age”/> | |
| </GroupDescriptions> | |
| <SortDescriptions> | |
| <SortDescription PropertyName=”Age”/> | |
| <SortDescription PropertyName=”LastName”/> | |
| </SortDescriptions> |
Per-Monitor DPI Support
WPF applications are now enabled for per-monitor DPI awareness. This improvement is critical for scenarios where multiple displays of varying DPI level are attached to a single machine. As all or part of a WPF application is transitioned between monitors, the expected behavior is for WPF to automatically match the DPI of the app to the screen. It now does.You can learn more about how to enable your WPF application to become per-monitor DPI aware in the WPF samples and developer guide on GitHub.
In previous versions, you would have to write additional native code to enable per-monitor DPI awareness in WPF applications.
Soft Keyboard Support
Soft Keyboard support enables automatic invocation and dismissal of the touch keyboard in WPF applications without disabling WPF stylus/touch support on Windows 10.In previous versions, WPF applications did not implicitly support the invocation or dismissal of the touch keyboard without disabling WPF stylus/touch support. This is due to a change in the way the touch keyboard tracks focus in applications starting in Windows 8.
Subscribe to:
Posts (Atom)