Microsoft has released the newest version of Visual Studio, Visual Studio 2015 Preview, along with .NET Framework 4.6. The newer version of the .NET Framework was introduced 12-13 of Nov 2014. The old version of .NET 4.5.3 will be updated to 4.6 before the final version ships. The .NET Framework 4.6 is highly compatible in comparison to the older version like .NET Framework 4, .NET Framework 4.5, .NET Framework 4.5.1, .NET Framework 4.5.2.
We would like to suggest that this preview version of .NET Framework 4.6 and Visual Studio 2015 is currently available for testing and feedback purposes only but very shortly it will be released as a final release, so before installing this version, please do remember that this preview version is not intended for use on a production computer.
New Features with .NET Framework 4.6
The following are the new features of the .NET Framework 4.6:
- Changes in the Base Class Library
- Resizing in Windows Forms controls
- Support for code page encodings
- Open-source .NET Framework packages
- Improvements to event tracing
- .NET Native
- Changes in Base Class Library
So many new APIs have been added to this new .NET Framework to enable key scenarios, especially for the Cross-Platform environment. Microsoft has made the following changes:
The CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture properties are now read-write rather than read-only. If you assign a new CultureInfo object to these properties, the current thread culture defined by the Thread.CurrentThread.CurrentCulture property and the current UI thread culture defined by the Thread.CurrentThread and CurrentUICulture properties also change.
The preceding program the gets error that we can’t make the assignment, it is read only but in the .Net Framework 4.6 it’s not an error because this property is now read write.
Additional collections implement ReadOnlyCollection<T> such as Queue<T> and Stack<T>. It implement System.Collections.ObjectModel.ReadOnlyCollection, including System.Collections.Generic.Queue and System.Collections.Generic.Stack.
Additional members support the task-based asynchronous pattern (TAP) such as Task.CompletedTask and NamedPipeClientStream.ConnectAsync.
Resizing in Windows Forms controls
The .NET Framework 4.6 expanded some namespaces that enable us to resize Windows Forms forms, so we need to include the following namespace to enable this feature, in other words:
System.Windows.Forms.DomainUpDown, System.Windows.Forms.NumericUpDown, System.Windows.Forms.DataGridViewComboBoxColumn, System.Windows.Forms.DataGridViewColumn and System.Windows.Forms.ToolStripSplitButton types.
This is an opt-in feature. To enable it, set the EnableWindowsFormsHighDpiAutoResizing element to true in the application configuration (app.config) file. Example code:
<appSettings>
<add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>
Support for code page encodings
The core .NET Framework primarily supports Unicode encodings and by default it provides limited support for code page encodings. We can add support for code page encodings that are available in the .NET Framework but unsupported in .NET Core by registering code page encodings with the Encoding.RegisterProvider method. So we will use the namespace System.Text.CodePagesEncodingProvider. So to make these code pages available to .NET Framework 4.6 Preview use these additional code pages, do the following assemblies reference to our project.
- Add a reference to the System.Text.Encoding.CodePages.dll assembly to your project.
- Retrieve a CodePagesEncodingProvider object from the static Instance property.
- Pass the CodePagesEncodingProvider object to the Encoding.RegisterProvider method.
The .NET Framework for the Windows Desktop supports a large set of Unicode and code page encodings. On the other hand, .NET Framework 4.6 Preview supports only the following encodings:
- ASCII (code page 20127)
- ISO-8859-1 (code page 28591)
- UTF-7 (code page 65000)
- UTF-8 (code page 65001)
- UTF-16 and UTF-16LE (code page 1200)
- UTF-16BE (code page 1201)
- UTF-32 and UTF-32LE (code page 12000)
- UTF-32BE (code page 12001)
Open-source .NET Framework packages
Some great .NET packages such as the Immutable Collections and SIMD APIs are now available, open source, on GitHub. To access the code, see NetFx on GitHub. For information on how to contribute to these packages, see the .NET Home Page on GitHub.
Where Immutable Collection is a common approach to use an immutable state that can be passed freely among multiple threads. Immutable collections are different from read-only collections in the sense that unlike read-only collections, they cannot be changed by the provider or consumer of the collection. For example, if you are enumerating a read-only collection, there is a possibility that the collection can be changed on another thread, causing data corruption. This scenario can’t occur if you are using an immutable collection. With an Immutable Collection you can do the following.
GitHub is a repository that contains the foundation libraries that make up the .NET Core development stack as in the following:
- Share a collection in such a way that its consumer can be assured that the collection will never change.
- Provide implicit thread safety in multi-threaded applications. No locks required to access collections.
- Follow functional programming practices.
- Modify a collection during enumeration, while ensuring that the original collection does not change.
- Improvements to event tracing
- An EventSource object can now be constructed directly and you can call one of the Write() methods to emit a self-describing event.
using System.Diagnostics.Tracing
//Assembly: mscorlib (in mscorlib.dll)
public void Write<T>(
string eventName,
T data
)
In the above example code:
T is the type that defines the event and its associated data. This type must be an anonymous type or marked with the EventSourceAttribute attribute, eventName is the name of event and data is the object of type T
.Net Native
It is a pre-compilation technology for building and deploying Windows Store apps. It compiles apps that are written in managed code (Like Visual C#) and that target the .NET Framework to native code. It is quite different from Just-In-Time (JIT) as well as the Native Image Generator (NGEN). Basically the .Net Native tool chain converts source code to native code at compile time while JIT is responsible for compiling the IL code to native code (machine specific code). Let’s see the brief comparison with JIT and NGEN as well.
The .NET Native tool chain begins execution when the C# compiler has finished compilation of a Windows Store app. In another words, we can say that the input for the .NET Native is the Windows Store app built by the C# compiler. .NET Native compiles an entire application to a native application. It does not allow you to compile a single assembly that contains a class library to native code so that it can be called independently from managed code. The NGEN compiles assemblies to native code and installs them in the native image cache on the local computer, whereas .NET Native produces native code.
Summary
In this article we saw the new features of the .NET version with details. In a future article we will explore the other new features introduced in #vsconnect();
