Typically, calendar eras represent long time periods. In the Gregorian calendar, for example, the current era spans (as of this year) 2,019 years. In the Japanese calendar, however, a new era begins with the reign of a new emperor. On April 30, 2019, Emperor Akihito is expected to abdicate, which will bring to an end the Heisei era. On the following day, when his successor becomes emperor, the Reiwa era, a new era in the Japanese calendar, will begin. It is the first transition from one era to another in the history of .NET, and the first change of eras in the Japanese calendar since Emperor Akihito’s accession in January 1989. In this blog post, I’ll discuss how eras work in general in .NET, how you can determine whether your application is affected by the era change, and what you as a developer have to doto make sure your application handles the upcoming Japanese era changes successfully.

Calendars in .NET

.NET supports a number of calendar classes, all of which are derived from the base Calendar class. Calendars can be used in either of two ways in .NET. A supported calendar is a calendar that can be used by a specific culture and that defines the formatting of dates and times for that culture. One supported calendar is the default calendar of a particular culture; it is automatically used as that culture’s calendar for culture-aware operations. Standalone calendars are used apart from a specific culture by calling members of that Calendar class directly. All calendars can be used as standalone calendars. Not all calendars can be used as supported calendars, however.

Each CultureInfo object, which represents a particular culture, has a default calendar, defined by its Calendar property. The OptionalCalendars property defines the set of calendars supported by the culture. Any member of this collection can become the current calendar for the culture by assigning it to the CultureInfo.DateTimeFormat.Calendar property.

Each calendar has a minimum supported date and a maximum supported date. The calendar classes also support eras, which divide the overall time interval supported by the calendar into two or more more periods. Most .NET calendars support a single era. The DateTime constructors that create a date using a specific calendar assume that that dates belong to the current era. You can instantiate a date in an era other than the current era by calling an overload of the Calendar.ToDateTime method.

The JapaneseCalendar and JapaneseLunisolarCalendar classes

Two calendar classes, JapaneseCalendar and JapaneseLunisolarCalendar, are affected by the introduction of a new Japanese era. The JapaneseCalendar uses the same months and days of the month as the Gregorian calendar. The two Japanese calendars differ in how they calculate years; the reign of a new emperor marks the beginning of a new era, which begins with year 1.

The JapaneseCalendar and JapaneseLunisolarCalendar are currently the only two calendar classes in .NET that recognize more than one era. Neither is the default calendar of any culture. The JapaneseCalendar class is an optional calendar supported by the Japanese-Japan (ja-JP) culture and is used in some official and cultural contexts. The JapaneseLunisolarCalendar class is a standalone calendar; it cannot be the current calendar of any culture. That neither is the default calendar of the ja-JP culture minimizes the impact that results from the introduction of a new Japanese calendar era. The introduction of a new era in the Japanese calendar affects only:

• Culture-specific date and time operations with cultures that support the JapaneseCalendar, when the JapaneseCalendar is the current calendar for the culture.
• Calls to standalone JapaneseCalendar and JapaneseLunisolarCalendar methods, such as GetDaysInYear, IsLeapYear, or ToDateTime.
• Formatting using the “g” or “gg” custom format specifier.
• Year formatting with the Japanese calendar classes, which will change to provide special formatting for the first year of an era. For more information, see The first year of an era later in this blog post.

Note that, with the exception of the “g” or “gg” custom format specifier, any unintended side effects from the change in Japanese eras occur only if you use a Japanese calendar class as a standalone calendar, or if you use the JapaneseCalendar as the current calendar of the ja-JP culture.

Testing era changes on Windows

The best way to determine whether your applications are affected by the new era is to test them in advance with the new era in place. You can do this immediately for .NET Framework 4.x apps and for .NET Core apps running on Windows systems. For .NET Core apps on other platforms, you’ll have to wait until the ICU globalization library is updated; see the Updating data sources section for more information.

For .NET Framework 4.x apps and for .NET Core apps on Windows systems, era information for the Japanese calendars is stored as a set of REG_SZ values in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras key of the system registry. For example, the following figure shows the definition of the Heisei era in the Japanese calendar.

You can use the Registry Editor (regedit.exe) to add a definition for the new era. The name defines the era start date, and its value defines the native era name, native abbreviated era name, English era name, and English abbreviated era name, as follows:

Name: yyyy mm dd Value: <native-full>_<native-abbreviated>_<English-full>_<English-abbreviated>

Adding the new Reiwa era to the list of eras requires that you add the following named value to the Eras registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]
"2019 05 01" = "令和_令_Reiwa_R"

Once the new era information is in place on any system running .NET, you can use code like the following to identify instances in which the current string representation of a date and time in a Japanese calendar will differ from its string representation after the introduction of the new era:

Only one month separates the beginning of the Reiwa era on May 1, 2019, and the Japanese government’s announcement of its official name on April 1, 2019. A window of one month leaves very little time to test, detect bugs, troubleshoot, and address bugs. It is important that applications be adequately tested well in advance of the beginning of the new era.

.NET changes to support the new era

To ensure that the transition to a new Japanese calendar era is as seamless as possible, the following changes will be introduced in .NET before the formal introduction of the new Japanese calendar era. These changes either have already been released will be released in the near future in Windows updates. For more information, see Summary of new Japanese Era updates for .NET Framework.

Updating data sources

Currently, the way in which calendar era information is stored differs across .NET implementations:

• For .NET Framework 4.0 and later, as well as for .NET Core running on Windows, calendar era information is provided by the Windows operating system and retrieved from the system registry. Once the Windows registry is updated to include the new era information, .NET on Windows will automatically reflect this update.
• For .NET Framework 3.5 on Windows, calendar era information is maintained as hard-coded data by the .NET Framework itself. An update to .NET Framework 3.5 will change its source for calendar data from private hard-coded data to the registry. Once this happens, .NET Framework 3.5 will automatically reflect the eras defined in the Windows registry.
• For .NET Core on non-Windows platforms, calendar information is provided by International Components for Unicode (ICU), an open source globalization library. ICU libraries will be updated once the era name and abbreviated era name are known.
  Because they do not depend on ICU cultural data, applications that use the globalization invariant mode are not affected by this change.

Relaxed era range checks

In the past, date and time methods that depend on calendar eras threw an ArgumentOutOfRangeException when a date and time was outside the range of a specified era. The following example attempts to instantiate a date in the 65th year of the Showa era, which began on December 25, 1926 and ended on January 7, 1989. This date corresponds to January 9, 1990, which is outside the range of the Showa era in the JapaneseCalendar. As a result, an ArgumentOutOfRangeException results.

To accommodate the era change, .NET by default will use relaxed range enforcement rules. A date in a particular era can “overflow” into the following era, and no exception is thrown. The following example instantiates a date in the third quarter of year 31 of the Heisei era, which is more than two months after the Heisei era has ended.

If this behavior is undesirable, you can restore strict era range checks as follows:

• .NET Framework 4.6 or later: You can set the following AppContextSwitchOverrides element switch:
  
• .NET Framework 4.5.2 or earlier: You can set the following registry value:
  

  Key	HKEY_LOCALMACHINE\SOFTWARE\Microsoft.NETFramework\AppContext
  Name	Switch.System.Globalization.EnforceJapaneseEraYearRanges
  Type	REG_SZ
  Value	1

• .NET Core: You can add the following to the .netcore.runtimeconfig.json config file:
  

The first year of an era

Traditionally, the first year of a new Japanese calendar era is called Gannen (元年). For example, instead of Heisei 1, the first year of the Heisei era can be described as Heisei Gannen.

As part of its enhanced support for Japanese calendar eras, .NET by default adopts this convention in formatting operations. In parsing operations, .NET successfully handles strings that include “1” or “Gannen” as the year component.

The following example displays a date in the first year of the Heisei era. The output from the example illustrates the difference between the current and future handling of the first year of an era by .NET. When run after the servicing update is released, the .NET formatting routine converts year 1 to Gannen only if the custom date and time format string includes “y年” or “y’年'”, as the output from the example illustrates.

If this behavior is undesirable in formatting operations, you can restore the previous behavior, which always represents the year as “1” rather than “Gannen”, by doing the following:

• .NET Framework 4.6 or later: You can set the following AppContextSwitchOverrides element switch:
  
• .NET Framework 4.5.2 or earlier: You can set the following registry value:
  

  Key	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
  Name	Switch.System.Globalization.FormatJapaneseFirstYearAsANumber
  Type	REG_SZ
  Value	1

• .NET Core: You can add the following to the .netcore.runtimeconfig.json config file:
  

Although there rarely should be a need to do this, you can also restore .NET’s previous behavior in parsing operations. This recognizes only “1” as the first year of an era, and does not recognize “Gannen”. You can do this as follows for both .NET Framework and .NET Core:

• .NET Framework 4.6 or later: You can set the following AppContextSwitchOverrides element switch:
  
• .NET Framework 4.5.2 or earlier: You can set the following registry value:
  

  Key	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
  Name	Switch.System.Globalization.EnforceLegacyJapaneseDateParsing
  Type	REG_SZ
  Value	1

• .NET Core: You can add the following to the .netcore.runtimeconfig.json config file:
  

Handling Japanese calendar eras effectively

The change in Japanese eras poses a number of issues. The following list addresses some of these and proposes workarounds.

Specify an era when instantiating dates

You can instantiate a date using the date values of the Japanese calendar in any of three ways:

• By calling a DateTime constructor that includes a parameter of type Calendar.
• By calling a DateTimeOffset constructor that includes a parameter of type Calendar.
• By calling the Calendar.ToDateTime method of a specific calendar type.

The .NET calendar classes include a CurrentEra property, which indicates the current (or default) era used in interpreting dates expressed in a specific calendar. Its value is the constant 0. It is an index into the Eras property, which orders eras in reverse chronological order. In other words, the most recent era is always the default era.

When eras can change unexpectedly, calling a date and time instantiation method that relies on the default era can produce an ambiguous date. In the next example, the call to the JapaneseCalendar.ToDateTime method that uses the default era returns different dates depending on whether or not the new era has been defined in the registry. Note that the output for this and the following example uses the sortable date/time pattern.

You can do either of two things to avoid potential ambiguity:

• Call the Calendar.ToDateTime overload that specifies an era. This overload always produces an unambiguous date:

• Instantiate dates in the Gregorian calendar. Use the Japanese calendar or the Japanese Lunisolar calendar only for the string representation of dates.

Use relaxed era range checks

A basic problem of calendars that can add new eras is that you can’t be certain that a future date will always belong to the current era. If strict range checking is enabled, future dates that are valid before an era change may become invalid after the era change. For this reason, leave relaxed era range checking on (the default value).

Use the era in formatting and parsing operations

Because dates can be ambiguous, you should always format a date value with its era. This is the default behavior of the standard date and time format strings. If you are using a custom date and time format string, be sure to include the “g” or “gg” custom format specifier. Conventionally, the era precedes the other date components in the string representation of a Japanese calendar date.

For parsing operations, also ensure that an era is present unless you want all dates and times to default to the current era.

A call to action

The introduction of a new era in the Japanese calendar poses challenges for any application that uses either the JapaneseCalendar or the JapaneseLunisolarCalendar. We’ve discussed how eras work with calendars and dates and times in .NET, how .NET applications will be updated to use the new era, how .NET APIs are changing to help you handle the Japanese era change, and what you can do as a developer to test your application and minimize the effect of future era changes. Above all, we recommend that you:

• Determine whether your applications are affected by the Japanese era change. All applications that use the JapaneseCalendar and the JapaneseLunisolarCalendar classes may be affected.
• Test your application to determine whether it can handle all dates, and particularly dates that exceed the range of the current Japanese calendar era.
• Adopt the practices outlined in the Handling Japanese calendar eras effectively section to ensure that you can handle era changes effectively.

See also

The Japanese Calendar’s Y2K Moment
Testing for New Japanese Era
Japanese calendar
Japanese era name
List of Japanese era names
Working with Calendars

The post Handling a new era in the Japanese calendar in .NET appeared first on .NET Blog.

Your friendly neighborhood .NET productivity team (aka. Roslyn) focuses a lot on improving the .NET coding experience. Sometimes it’s the little refactorings and code fixes that really improve your workflow. You may have seen many improvements in the previews, but for all of you who were eagerly awaiting the GA release here’s a few features you may enjoy!

Tooling improvements

I’m most excited about the new Roslyn classification colors. Visual Studio Code colors received high praise so we incorporated similar color schemes into Visual Studio. Your code editor is now just a little more colorful. Key words, user methods, local variables, parameter names, and overloaded operators all get new colors. You can even customize the colors for each syntax classifications in Tools > Options > Environment > Fonts and Colors and scroll to ‘User Members’.

At the bottom of files in your editor are the document health indicators as well as our code cleanup icon. The document health indicators let you know at a glance how many errors and warnings are present in the file you currently have open. You can click on the code cleanup icon to apply code style rules specified in Tools > Options or, if you have an editorconfig file that shares one code style across your team, it will apply styles specified in that file.

You can edit sdk-style project files with a simple double-click! You can also view these project files with preview in GoToAll (Ctrl+t) navigation and search the contents for file references.

Load a subset of projects in your solution with filtered solutions! You can now unload projects and save a .slnf file that will only open the projects you specified. This helps you get to the code you are interested in quickly without needing to load an entire solution.

Find all references categorizes by reference type. You can filter by read/write in the new ‘Kind’ column in the find all references window.

Run code style formatting over the entire solution at the command-line with the dotnet format global tool.

Now the omnibus of new code fixes and refactorings!

Foreach to LINQ

Add missing reference for unimported types

Sync namespace and folder name

Invert conditional expressions

Pull members up dialog for promoting members to an interface

Wrap/indent/align parameters/arguments

Remove unused expression values and parameters

This is a set of highlights of what’s new in Visual Studio 2019, for a complete list see the release notes. As always, I would love your feedback via twitter, on GitHub, or in the comments section below. Also, one important thing to note is that to use .NET Core 3.0 Preview you will need to download and install the SDK, it is not included with the Visual Studio 2019 installer yet.

The post Visual Studio 2019 .NET productivity appeared first on .NET Blog.

Today, we released the March 2019 Update for Windows 10 version 1809 and Windows Server 2019.

Quality and Reliability

This release contains the following quality and reliability improvements.

CLR

• • Addresses an issue in which the Framework throws an exception if the year in the parsed date is greater than or equal to the start year of the next era. Now, the framework will not throw such exception. [603100]
  • Updates Japanese Era dates that are formatted for the first year in an era and for which the format pattern uses the “y年” characters. The format of the year together with the symbol “元” is supported instead of using year number 1. Also, formatting day numbers that include “元” is supported. [646179]
  • Allows the output of Gannen characters in Japanese Era formatting of first year dates regardless of whether the format pattern includes single quotation marks around the “年” character. [777182]

Getting the Update

The Update is available via Windows Server Update Services and Microsoft Update Catalog.

Microsoft Update Catalog

You can get the update via the Microsoft Update Catalog. The following table is for Windows 10 version 1809 and Windows Server 2019.

Previous Monthly Rollups

The last few .NET Framework Monthly updates are listed below for your convenience:

• • • March 2019 Update
    • March 1, 2019 Cumulative Update for Windows 10 version 1809 and Windows Server 2019
    • February 2019 Preview Quality Rollup
    • February 2019 Security and Quality Rollup

The post .NET Framework April 2, 2019 Cumulative Update for Windows 10 version 1809 and Windows Server 2019 appeared first on .NET Blog.

ML.NET is an open-source and cross-platform machine learning framework (Windows, Linux, macOS) for .NET developers. Using ML.NET, developers can leverage their existing tools and skillsets to develop and infuse custom AI into their applications by creating custom machine learning models for common scenarios like Sentiment Analysis, Recommendation, Image Classification and more!.

Today we’re announcing the ML.NET 1.0 RC (Release Candidate) (version 1.0.0-preview) which is the last preview release before releasing the final ML.NET 1.0 RTM in 2019 Q2 calendar year.

Soon we will be ending the first main milestone of a great journey in the open that started on May 2018 when releasing ML.NET 0.1 as open source. Since then we’ve been releasing monthly, 12 preview releases so far, as shown in the roadmap below:

In this release (ML.NET 1.0 RC) we have initially concluded our main API changes. For the next sprint we are focusing on improving documentation and samples and addressing major critical issues if needed.

The goal is to avoid any new breaking changes moving forward.

Updates in ML.NET 1.0 RC timeframe

• Segregation of stable vs. preview version of ML.NET packages: Heading ML.NET 1.0, most of the functionality in ML.NET (around 95%) is going to be released as stable (version 1.0).

  You can review the reference list of the ‘stable’ packages and classes here.

  However, there are a few feature-areas which still won’t be in RTM state when releasing ML.NET 1.0. Those features still kept as preview are being categorized as preview packages with the version 0.12.0-preview.

  The main packages that will continue in preview state after ML.NET 1.0 is released are the following (0.12 version packages):

  • TensorFlow components
  • Onnx components
  • TimeSeries components
  • Recommendadtions components

  You can review the full reference list of “after 1.0” preview packages and classes (0.12.0-preview) here.

• IDataView moved to Microsoft.ML namespace : One change in this release is that we have moved IDataView back into Microsoft.ML namespace based on feedback that we received.

• TensorFlow-support fixes: TensorFlow is an open source machine learning framework used for deep learning scenarios (such as computer vision and natural language processing). ML.NET has support for using TensorFlow models, but in ML.NET version 0.11 there were a few issues that have been fixed for the 1.0 RC release.

  You can review an example of ML.NET code running a TensorFlow model here.

• Release Notes for ML.NET 1.0 RC: You can check out additional release notes for 1.0 RC here.

Breaking changes in ML.NET 1.0 Release Candidate

For your convenience, if you are moving your code from ML.NET v0.11 to v0.12, you can check out the breaking changes list that impacted our samples.

Planning to go to production?

If you are using ML.NET in your app and looking to go into production, you can talk to an engineer on the ML.NET team to:

• Get help implementing ML.NET successfully in your application.
• Provide feedback about ML.NET.
• Demo your app and potentially have it featured on the ML.NET homepage, .NET Blog, or other Microsoft channel.

Fill out this form and leave your contact information at the end if you’d like someone from the ML.NET team to contact you.

Get ready for ML.NET 1.0 before it releases!

As mentioned, ML.NET 1.0 is almost here! You can get ready before it releases by researching the following resources:

Get started with ML.NET here.

Next, going further explore some other resources:

• Tutorials and resources at the Microsoft Docs ML.NET Guide
• Sample apps using ML.NET at the machinelearning-samples GitHub repo
• Important ML.NET concepts for understanding the new API are introduced here
• “How to” guides that show how to use these APIs for a variety of scenarios can be found here

We will appreciate your feedback by filing issues with any suggestions or enhancements in the ML.NET GitHub repo to help us shape ML.NET and make .NET a great platform of choice for Machine Learning.

Thanks and happy coding with ML.NET!

The ML.NET Team.

This blog was authored by Cesar de la Torre plus additional contributions of the ML.NET team

The post Announcing ML.NET 1.0 RC – Machine Learning for .NET appeared first on .NET Blog.

Today, we are releasing the .NET Core April 2019 Update. These updates contain security and reliability fixes. See the individual release notes for details on included fixes.

• .NET Core 2.2.4 and .NET Core SDK 2.2.106 ( Download | Release Notes )
• .NET Core 2.1.10 and .NET Core SDK 2.1.506 ( Download | Release Notes)

Security

Microsoft Security Advisory CVE-2019-0815: ASP.NET Core Denial of Service Vulnerability

A denial of service vulnerability exists in ASP.NET Core 2.2 where, if an application is hosted on Internet Information Server (IIS) a remote unauthenticated attacker can use a specially crafted request to cause a Denial of Service.

The vulnerability affects any Microsoft ASP.NET Core 2.2 applications if it is hosted on an IIS server running AspNetCoreModuleV2 (ANCM) prior to and including 12.2.19024.2. The security update addresses the vulnerability by ensuring the IIS worker process does not crash in response to specially crafted requests.

Getting the Update

The latest .NET Core updates are available on the .NET Core download page.

See the .NET Core release notes ( 2.1.10 | 2.2.4 ) for details on the release including a issues fixed and affected packages.

Docker Images

.NET Docker images have been updated for today’s release. The following repos have been updated.

microsoft/dotnet
microsoft/dotnet-samples
microsoft/aspnetcore

Note: Look at the “Tags” view in each repository to see the updated Docker image tags.

Note: You must re-pull base images in order to get updates. The Docker client does not pull updates automatically.

Azure App Services deployment

Deployment of these updates Azure App Services has been scheduled and they estimate the deployment will be complete by Apr 23, 2019.

The post .NET Core April 2019 Updates – 2.1.10 and 2.2.4 appeared first on .NET Blog.

We are thrilled to announce the release of the .NET Framework 4.8 today. It’s included in the Windows 10 May 2019 Update. .NET Framework 4.8 is also available on Windows 7+ and Windows Server 2008 R2+.

You can install .NET 4.8 from our .NET Download site. For building applications targeting .NET Framework 4.8, you can download the NET 4.8 Developer Pack. If you just want the .NET 4.8 runtime, you can try:

• .NET 4.8 Web Installer – requires an internet connection during installation
• .NET 4.8 Offline installer – can be downloaded and installed later in a disconnected state

The .NET Framework 4.8 includes an updated toolset as well as improvements in several areas:

• [Runtime] JIT and NGEN Improvements
• [BCL] Updated ZLib
• [BCL] Reducing FIPS Impact on Cryptography
• [WinForms] Accessibility Enhancements
• [WCF] Service Behavior Enhancements
• [WPF] High DPI Enhancements, UIAutomation Improvements

You can see the complete list of improvements in the .NET Framework 4.8 release notes. Reference sources have also been updated for .NET 4.8.

Supported Windows Versions

Windows Client versions: Windows 10 version 1903, Windows 10 version 1809, Windows 10 version 1803, Windows 10 version 1709, Windows 10 version 1703, Windows 10 version 1607, Windows 8.1, Windows 7 SP1
Windows Server versions: Windows Server 2019, Windows Server version 1803, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows Server 2008 R2 SP1

New Features in .NET Framework 4.8

Runtime – JIT improvements

The JIT in .NET 4.8 is based on .NET Core 2.1.  All bug fixes and many code generation-based performance optimizations from .NET Core 2.1 are now available in the .NET Framework.

Runtime – NGEN improvements

NGEN images in the .NET Framework no longer contain writable & executable sections. This reduces the surface area available to attacks that attempt to execute arbitrary code by modifying memory that will be executed.

While there will still be writable & executable data in memory at runtime, this change removes those mapped from NGEN images, allowing them to run in restricted environments that don’t permit executable/writable sections in images.

Runtime – Antimalware Scanning for All Assemblies

In previous versions of .NET Framework, Windows Defender or third-party antimalware software would automatically scan all assemblies loaded from disk for malware. However, assemblies loaded from elsewhere, such as by using Assembly.Load(byte[]), would not be scanned and could potentially carry viruses undetected.

.NET Framework 4.8 on Windows 10 triggers scans for those assemblies by Windows Defender and many other antimalware solutions that implement the Antimalware Scan Interface. We expect that this will make it harder for malware to disguise itself in .NET programs.

BCL – Updated ZLib

Starting with .NET Framework 4.5 we used the native version of ZLib (a native external compression library used for data compression) from http://zlib.net in clrcompression.dll in order to provide an implementation for the deflate algorithm. In .NET Framework 4.8 we updated clrcompression.dll to use version 1.2.11 which includes several key improvements and fixes.

BCL – Reducing FIPS Impact on Cryptography

.NET Framework 2.0+ have cryptographic provider classes such as SHA256Managed, which throw a CryptographicException when the system cryptographic libraries are configured in “FIPS mode”. These exceptions are thrown because the managed versions have not undergone FIPS (Federal Information Processing Standards) 140-2 certification (JIT and NGEN image generation would both invalidate the certificate), unlike the system cryptographic libraries. Few developers have their development machines in “FIPS mode”, which results in these exceptions being raised in production (or on customer systems). The “FIPS mode” setting was also used by .NET Framework to block cryptographic algorithms which were not considered an approved algorithm by the FIPS rules.

For applications built for .NET Framework 4.8, these exceptions will no longer be thrown (by default). Instead, the SHA256Managed class (and the other managed cryptography classes) will redirect the cryptographic operations to a system cryptography library. This policy change effectively removes a potentially confusing difference between developer environments and the production environments in which the code runs and makes native components and managed components operate under the same cryptographic policy.

Applications targeting .NET Framework 4.8 will automatically switch to the newer, relaxed policy and will no longer see exceptions being thrown from MD5Cng, MD5CryptoServiceProvider, RC2CryptoServiceProvider, RIPEMD160Managed, and RijndaelManaged when in “FIPS mode”. Applications which depend on the exceptions from previous versions can return to the previous behavior by setting the AppContext switch “Switch.System.Security.Cryptography.UseLegacyFipsThrow” to “true”.

Windows Forms – Accessibility Enhancements

In .NET Framework 4.8 WinForms is adding three new features to enable developers to write more accessible applications. The features added are intended to make communication of application data to visually impaired users more robust. We’ve added support for ToolTips when a user navigates via the keyboard, we’ve added LiveRegions and Notification Events to many commonly used controls.

To enable these features your application needs to have the following AppContextSwitches enabled in the App.config file:

Windows Forms – UIA LiveRegions Support in Labels and StatusStrips

UIA Live Regions allow application developers to notify screen readers of a text change on a control that is located apart from the location where the user is working. Examples of where this would come in handy could be a StatusStrip that shows a connection status. If the connection is dropped and the Status changes, the developer might want to notify the screen reader of this change. Windows Forms has implemented UIA LiveRegions for both the Label control and the StatusStrip control.

Example use of the LiveRegion in a Label Control:

Narrator will now announce “Ready” Regardless of where the user is interacting with the application.
You can also implement your UserControl as a Live region:

Windows Forms – UIA Notification Events

In Windows 10 Fall Creators Update Windows introduced a new method of having an application notify Narrator that content has changed, and Narrator should announce the change. The UIA Notification event provides a way for your app to raise a UIA event which leads to Narrator simply making an announcement based on text you supply with the event, without the need to have a corresponding control in the UI. In some scenarios, this could be a straightforward way to dramatically improve the accessibility of your app.  For more information about UIA Notification Events, see this blog post.

An example of where a Notification might come in handy is to notify the progress of some process that may take some time.

An example of raising the Notification event:

Windows Forms – ToolTips on keyboard access

Currently a control tooltip can only be triggered to pop up by moving a mouse pointer into the control. This new feature enables a keyboard user to trigger a control’s tooltip by focusing the control using a Tab key or arrow keys with or without modifier keys. This particular accessibility enhancement requires an additional AppContextSwitch as seen in the following example:

1. Create a new WinForms application
2. Add the following XML to the App.config file

3. Add several buttons and a ToolTip control to the application’s form.
4. Set tooltips for the buttons.
5. Run the application and navigate between the buttons using a keyboard:

Windows Forms – DataGridView control accessible hierarchy changes

Currently the accessible hierarchy (UI Automation tree) shows the editing box tree element as a child of currently edited cell but not as a root child element of DataGridView. The hierarchy tree update can be observed using Inspect tool:

 WCF – ServiceHealthBehavior

Health endpoints have many benefits and are widely used by orchestration tools to manage the service based on the service health status. Health checks can also be used by monitoring tools to track and alert on the availability and performance of the service, where they serve as early problem indicators.

ServiceHealthBehavior is a WCF service behavior that extends IServiceBehavior.  When added to the ServiceDescription.Behaviors collection, it will enable the following:

• Return service health status with HTTP response codes: One can specify in the query string the HTTP status code for a HTTP/GET health probe request.
• Publication of service health: Service specific details including service state and throttle counts and capacity are displayed using an HTTP/GET request using the “?health” query string. Knowing and easily having access to the information displayed is important when trouble-shooting a mis-behaving WCF service.

Config ServiceHealthBehavior:

There are two ways to expose the health endpoint and publish WCF service health information: by using code or by using a configuration file.

1. Enable health endpoint using code 

2. Enable health endpoint using config

Return service health status with HTTP response codes:

Health status can be queried by query parameters (OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded). HTTP response code (200 – 599) can be specified for each query parameter. If the HTTP response code is omitted for a query parameter, a 503 HTTP response code is used by default.

Query parameters and examples:

1. OnServiceFailure:

• Example: by querying https://contoso:81/Service1?health&OnServiceFailure=450, a 450 HTTP response status code is returned when ServiceHost.State is greater than CommunicationState.Opened.

2. OnDispatcherFailure:

• Example: by querying https://contoso:81/Service1?health&OnDispatcherFailure=455, a 455 HTTP response status code is returned when the state of any of the channel dispatchers is greater than CommunicationState.Opened.

3. OnListenerFailure:

• Example: by querying https://contoso:81/Service1?health&OnListenerFailure=465, a 465 HTTP response status code is returned when the state of any of the channel listeners is greater than CommunicationState.Opened.

4. OnThrottlePercentExceeded: Specifies the percentage {1 – 100} that triggers the response and its HTTP response code {200 – 599}.

• Example: by querying https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500, when the throttle percentage is equal or larger than 95%, 500 the HTTP response code is returned; when the percentage is equal or larger than 70% and less then 95%,   350 is returned; otherwise, 200 is returned.

Publication of service health:

After enabling the health endpoint, the service health status can be displayed either in html (by specifying the query string: https://contoso:81/Service1?health) or xml (by specifying the query string: https://contoso:81/Service1?health&Xml) formats. https://contoso:81/Service1?health&NoContent returns empty html page.

Note:

It’s best practice to always limit access to the service health endpoint. You can restrict access by using the following mechanisms:

1. Use a different port for the health endpoint than what’s used for the other services as well as use a firewall rule to control access.
2. Add the desirable authentication and authorization to the health endpoint binding.

WPF – Screen narrators no longer announce elements with Collapsed or Hidden visibility

Elements with Collapsed or Hidden visibility are no longer announced by the screen readers. User interfaces containing elements with a Visibility of Collapsed or Hidden can be misrepresented by screen readers if such elements are announced to the user. In .NET Framework 4.8, WPF no longer includes Collapsed or Hidden elements in the Control View of the UIAutomation tree, so that the screen readers can no longer announce these elements.

WPF – SelectionTextBrush Property for use with Non-Adorner Based Text Selection

In the .NET Framework 4.7.2 WPF added the ability to draw TextBox and PasswordBox text selection without using the adorner layer (See Here). The foreground color of the selected text in this scenario was dictated by SystemColors.HighlightTextBrush.

In the .NET Framework 4.8 we are adding a new property, SelectionTextBrush, that allows developers to select the specific brush for the selected text when using non-adorner based text selection.

This property works only on TextBoxBase derived controls and PasswordBox in WPF applications with non-adorner based text selection enabled. It does not work on RichTextBox. If non-adorner based text selection is not enabled, this property is ignored.

To use this property, simply add it to your XAML code and use the appropriate brush or binding.

The resulting text selection will look like this:

You can combine the use of SelectionBrush and SelectionTextBrush to generate any color combination of background and foreground that you deem appropriate.

WPF – High DPI Enhancements

WPF has added support for Per-Monitor V2 DPI Awareness and Mixed-Mode DPI scaling in .NET 4.8. Additional information about these Windows concepts is available here.

The latest Developer Guide for Per monitor application development in WPF states that only pure-WPF applications are expected to work seamlessly in a high-DPI WPF application and that Hosted HWND’s and Windows Forms controls are not fully supported.

.NET 4.8 improves support for hosted HWND’s and Windows Forms interoperation in High-DPI WPF applications on platforms that support Mixed-Mode DPI scaling (Windows 10 v1803). When hosted HWND’s or Windows Forms controls are created as Mixed-Mode DPI scaled windows, (as described in the “Mixed-Mode DPI Scaling and DPI-aware APIs” documentation by calling SetThreadDpiHostingBehavior and SetThreadDpiAwarenessContext API’s), it will be possible to host such content in a Per-Monitor V2 WPF application and have them be sized and scaled appropriately. Such hosted content will not be rendered at the native DPI – instead, the OS will scale the hosted content to the appropriate size.

The support for Per-Monitor v2 DPI awareness mode also allows WPF controls to be hosted (i.e., parented) under a native window in a high-DPI application. Per-Monitor V2 DPI Awareness support will be available on Windows 10 v1607 (Anniversary Update). Windows adds support for child-HWND’s to receive DPI change notifications when Per-Monitor V2 DPI Awareness mode is enabled via the application manifest.

This support is leveraged by WPF to ensure that controls that are hosted under a native window can respond to DPI changes and update themselves. For e.g.- a WPF control hosted in a Windows Forms or a Win32 application that is manifested as Per Monitor V2 – will now be able to respond correctly to DPI changes and update itself.

Note that Windows supports Mixed-Mode DPI scaling on Windows 10 v1803, whereas Per-Monitor V2 is supported on v1607 onwards.

To try out these features, the following application manifest and AppContext flags must be enabled:

1. Enable Per-Monitor DPI in your application
   • • Turn on Per-Monitor V2 in your app.manifest

2. Turn on High DPI support in WPF

2. • Target .NET Framework 4.6.2 or greater

and

3. Set AppContext switch in your app.config

Alternatively,

Set AppContextSwitch Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false in App.Config to enable Per-Monitor V2 and Mixed-Mode DPI support introduced in .NET 4.8.

The runtime section in the final App.Config might look like this:

AppContext switches can also be set in registry. You can refer to the AppContext Class for additional documentation.

WPF – Support for UIAutomation ControllerFor property

UIAutomation’s ControllerFor property returns an array of automation elements that are manipulated by the automation element that supports this property. This property is commonly used for Auto-suggest accessibility. ControllerFor is used when an automation element affects one or more segments of the application UI or the desktop. Otherwise, it is hard to associate the impact of the control operation with UI elements. This feature adds the ability for controls to provide a value for ControllerFor property.

A new virtual method has been added to AutomationPeer:

To provide a value for the ControllerFor property, simply override this method and return a list of AutomationPeers for the controls being manipulated by this AutomationPeer:

WPF – Tooltips on keyboard access

Currently tooltips only display when a user hovers the mouse cursor over a control. In .NET Framework 4.8, WPF is adding a feature that enables tooltips to show on keyboard focus, as well as via a keyboard shortcut.

To enable this feature, an application needs to target .NET Framework 4.8 or opt-in via AppContext switch “Switch.UseLegacyAccessibilityFeatures.3” and “Switch.UseLegacyToolTipDisplay”.

Sample App.config file:

Once enabled, all controls containing a tooltip will start to display it once the control receives keyboard focus. The tooltip can be dismissed over time or when keyboard focus changes. Users can also dismiss the tooltip manually via a new keyboard shortcut Ctrl + Shift + F10. Once the tooltip has been dismissed it can be displayed again via the same keyboard shortcut.

Note: RibbonToolTips on Ribbon controls won’t show on keyboard focus – they will only show via the keyboard shortcut.

WPF – Added Support for SizeOfSet and PositionInSet UIAutomation properties

Windows 10 introduced new UIAutomation properties SizeOfSet and PositionInSet which are used by applications to describe the count of items in a set. UIAutomation client applications such as screen readers can then query an application for these properties and announce an accurate representation of the application’s UI.

This feature adds support for WPF applications to expose these two properties to UIAutomation. This can be accomplished in two ways:

• • 1. DependencyProperties 

New DependencyProperties SizeOfSet and PositionInSet have been added to the System.Windows.Automation.AutomationProperties namespace. A developer can set their values via XAML:

    2. AutomationPeer virtual methods 

Virtual methods GetSizeOfSetCore and GetPositionInSetCore have also been added to the AutomationPeer class. A developer can provide values for SizeOfSet and PositionInSet by overriding these methods:

 Automatic values 

Items in ItemsControls will provide a value for these properties automatically without additional action from the developer. If an ItemsControl is grouped, the collection of groups will be represented as a set and each group counted as a separate set, with each item inside that group providing its position inside that group as well as the size of the group. Automatic values are not affected by virtualization. Even if an item is not realized, it is still counted towards the total size of the set and affects the position in the set of it’s sibling items.

Automatic values are only provided if the developer is targeting .NET Framework 4.8 or has set the AppContext switch “Switch.UseLegacyAccessibilityFeatures.3” – for example via App.config file:

Closing

Please try out these improvements in the .NET Framework 4.8 and share your feedback in the comments below or via GitHub.

Thank you!

The post Announcing the .NET Framework 4.8 appeared first on .NET Blog.

Today, we are announcing .NET Core 3.0 Preview 4. It includes a chart control for Windows Forms, HTTP/2 support, GC updates to use less memory, support for CPU limits with Docker, the addition of PowerShell in .NET Core SDK Docker container images, and other improvements. If you missed it, check out the improvements we released in .NET Core 3.0 Preview 3 just last month.

Download .NET Core 3 Preview 4 right now on Windows, macOS and Linux.

ASP.NET Core and Entity Framework Core updates are also being released today.

WinForms Chart control now available for .NET Core

We’ve been hearing that some developers were not able to migrate their existing .NET Framework applications to .NET Core because they had a dependency on the Chart control. We’ve fixed that for you!

The System.Windows.Forms.DataVisualization package (which includes the chart control) is now available on NuGet, for .NET Core. You can now include this control in your .NET Core WinForms applications!

We ported the System.Windows.Forms.DataVisualization library to .NET Core over the last few sprints. The source for the chart control is available at dotnet/winforms-datavisualization, on GitHub. The control was migrated to ease porting to .NET Core 3, but isn’t a component we intend to innovate in. For more advanced data visualization scenarios check out Power BI.

The best way to familiarize yourself with the Charting control is to take a look at our ChartSamples project. It contains all existing chart types and can guide you through every step.

Enabling the Chart control in your .NET project

To use the Chart control in your WinForms Core project add a reference to the System.Windows.Forms.DataVisualization NuGet package. You can do it by either searching for System.Windows.Forms.DataVisualization in the NuGet Package Manager (don’t forget to check Include prerelease box) or by adding the following lines in your .csproj file.

<ItemGroup>
    <PackageReference Include="System.Windows.Forms.DataVisualization" Version="1.0.0-prerelease.19212.2"/>
</ItemGroup>

Note: The WinForms designer is currently under development and you won’t be able to configure the control from the designer just yet. For now you can either use a code-first approach or you can create and configure the control in a .NET Framework application using the designer and then port your project to .NET Core. Porting guidelines are available in the How to port desktop applications to .NET Core 3.0 post.

WPF

The WPF team published more components to dotnet/wpf between the Preview 3 and Preview 4 releases.

The following components are now available as source:

• Microsoft.NET.Sdk.WindowsDesktop — this is the MSBuild SDK (as in “SDK style project” SDK) for Windows Desktop apps.
• Microsoft.Dotnet.Wpf.ProjectTemplates — these are the project templates for WPF.
• PresentationBuildTasks — these are the tasks that are used to compile Xaml.

The team published an engineering write-up on what they’ve been working on. You can expect them to publish more code to GitHub soon.

Improving .NET Core Version APIs

We have improved the .NET Core version APIs in .NET Core 3.0. They now return the version information you would expect. These changes while they are objectively better are technically breaking and may break applications that rely on version APIs for various information.

You can now get access to the following information via existing APIs:

C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 3.0.0
RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4.19113.15
CoreFX Build: 3.0.0-preview4.19113.15
CoreFX Hash: add4cacbfb7f7d3f5f07630d10b24e38da4ad027

The code to produce that output follows:

WriteLine(".NET Core version:");
WriteLine($"Environment.Version: {Environment.Version}");
WriteLine($"RuntimeInformation.FrameworkDescription: {RuntimeInformation.FrameworkDescription}");
WriteLine($"CoreCLR Build: {((AssemblyInformationalVersionAttribute[])typeof(object).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute),false))[0].InformationalVersion.Split('+')[0]}");
WriteLine($"CoreCLR Hash: {((AssemblyInformationalVersionAttribute[])typeof(object).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false))[0].InformationalVersion.Split('+')[1]}");
WriteLine($"CoreFX Build: {((AssemblyInformationalVersionAttribute[])typeof(Uri).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute),false))[0].InformationalVersion.Split('+')[0]}");
WriteLine($"CoreFX Hash: {((AssemblyInformationalVersionAttribute[])typeof(Uri).Assembly.GetCustomAttributes(typeof(AssemblyInformationalVersionAttribute), false))[0].InformationalVersion.Split('+')[1]}");

Tiered Compilation (TC) Update

Tiered compilation (TC) is a runtime feature that is able to control the compilation speed and quality of the JIT to achieve various performance outcomes. It is enabled by default in .NET Core 3.0 builds.

The fundamental benefit and capability of TC is to enable (re-)jitting methods with slower but faster to produce or higher quality but slower to produce code in order to increase performance of an application as it goes through various stages of execution, from startup through steady-state. This contrasts with the non-TC approach, where every method is compiled a single way (the same as the high-quality tier), which is biased to steady-state over startup performance.

We are considering what the default TC configuration should be for the final 3.0 release. We have been investigating the performance impact (positive and/or negative) for a variety of application scenarios, with the goal of selecting a default that is good for all scenarios, and providing configuration switches to enable developers to opt apps into other configurations.

TC remains enabled in Preview 4, but we changed the functionality that is enabled by default. We are looking for feedback and additional data to help us decide if this new configuration is best, or if we need to make more changes. Our goal is to select the best overall default, and then provide one or more configuration switches to enable other opt-in behaviors.

There are two tiers, tier 0 and tier 1. At startup, tier 0 code can be one of the following:

• Ahead-of-time compiled Ready to Run (R2R) code.
• Tier 0 jitted code, produced by “Quick JIT”. Quick JIT applies fewer optimizations (similar to “minopts”) to compile code faster.

Both of these types of tier 0 code can be “upgraded” to tier 1 code, which is fully-optimized jitted code.

In preview 4, R2R tiering is enabled by default and tier 0 jitted code (or Quick JIT) is disabled. This means that all jitted code is jitted as tier 1, by default. Tier 1 code is higher quality (executes faster), but takes longer to generate, so can increase startup time. For Preview 3, TC, including Quick JIT, were enabled.

To enable Quick JIT (tier 0 jitted code):

<TieredCompilationQuickJit>true</TieredCompilationQuickJit>

To disable TC completely:

<TieredCompilation>false</TieredCompilation>

Please try out the various compilation modes, including the Preview 4 default, and give us feedback.

HTTP/2 Support

We now have support for HTTP/2 in HttpClient. The new protocol is a requirement for some APIs, like gRPC and Apple Push Notification Service. We expect more services to require HTTP/2 in the future.

ASP.NET also has support for HTTP/2, however it is an independent implementation that is optimized for scale.

In Preview 4, HTTP/2 is not enabled by default, but can be enabled with one of the following methods:

• Set AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2Support", true); app context setting
• Set DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2SUPPORT environment variable to true

These configurations (either one) need to be set before using HttpClient if you intend to use HTTP/2.

Note: the preferred HTTP protocol version will be negotiated via TLS/ALPN and HTTP/2 will only be used if the server selects to use it.

SDK Docker Images Contain PowerShell Core

PowerShell Core has been added to the .NET Core SDK Docker container images, per requests from the community. PowerShell Core is a cross-platform (Windows, Linux, and macOS) automation and configuration tool/framework that works well with your existing tools and is optimized for dealing with structured data (e.g. JSON, CSV, XML, etc.), REST APIs, and object models. It includes a command-line shell, an associated scripting language and a framework for processing cmdlets.

You can try out PowerShell Core, as part of the .NET Core SDK container image, by running the following Docker command:

docker run --rm mcr.microsoft.com/dotnet/core/sdk:3.0 pwsh -c Write-Host "Hello Powershell"

There are two main scenarios that having PowerShell inside the .NET Core SDK container image enables, which were not otherwise possible:

• Write .NET Core application Dockerfiles with PowerShell syntax for any OS.
• Write .NET Core application/library build logic that can be easily containerized.

Example syntax for launching PowerShell for a (volume-mounted) containerized build:

• docker run -it -v c:\myrepo:/myrepo -w /myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 pwsh build.ps1
• docker run -it -v c:\myrepo:/myrepo -w /myrepo mcr.microsoft.com/dotnet/core/sdk:3.0 ./build.ps1

For the second example to work, on Linux, the .ps1 file needs to have the following pattern, and needs to be formatted with Unix (LF) not Windows (CRLF) line endings:

#!/usr/bin/env pwsh
Write-Host "test"

If you are new to PowerShell and would like to learn more, we recommend reviewing the getting started documentation.

Note: PowerShell Core is now available as part of .NET Core 3.0 SDK container images. It is not part of the .NET Core 3.0 SDK.

Better support Docker CPU (–cpus) Limits

The Docker client allows limiting memory and CPU. We improved support for memory limits in Preview 3, and have now started improving CPU limits support.

Round up the value of the CPU limit

In the case where --cpus is set to a value close (enough) to a smaller integer (for example, 1.499999999), the runtime would previously round that value down (in this case, to 1). As a result, the runtime would take advantage of less CPU than requested, leading to CPU underutilization.

By rounding up the value, the runtime augments the pressure on the OS threads scheduler, but even in the worst case scenario (--cpus=1.000000001 — previously rounded down to 1, now rounded to 2), we have not observed any overutilization of the CPU leading to performance degradation.

Thread pool honors CPU limits

The next step is ensuring that the thread pool honors CPU limits. Part of the algorithm of the thread pool is computing CPU busy time, which is, in part, a function of available CPUs. By taking CPU limits into account when computing CPU busy time, we avoid various heuristic of the threadpool competing with each other: one trying to allocate more threads to increase the CPU busy time, and the other one trying to allocate less threads because adding more threads doesn’t improve the throughput.

Making GC Heap Sizes Smaller by default

While working on improving support for docker memory limits as part of Preview 3, we were inspired to make more general GC policy updates to improve memory usage for a broader set of applications (even when not running in a container). The changes better align the generation 0 allocation budget with modern processor cache sizes and cache hierarchy.

Damian Edwards on our team noticed that the memory usage of the ASP.NET benchmarks were cut in half with no negative effect on other performance metrics. That’s a staggering improvement! As he says, these are the new defaults, with no change required to his (or your) code (other than adopting .NET Core 3.0).

The memory savings that we saw with the ASP.NET benchmarks may or may not be representative of what you’ll see with your application. We’d like to hear how these changes reduce memory usage for your application.

Better support for many proc machines

Based on .NET’s Windows heritage, the GC needed to implement the Windows concept of processor groups to support machines with > 64 processors. This implementation was made in .NET Framework, 5-10 years ago. With .NET Core, we made the choice initially for the Linux PAL to emulate that same concept, even though it doesn’t exist in Linux.

We have since abandoned this concept in the GC and transitioned it exclusively to the Windows PAL. We also now expose a configuration switch, GCHeapAffinitizeRanges, to specify affinity masks on machines with >64 processors. Maoni Stephens wrote about this change in Making CPU configuration better for GC on machines with > 64 CPUs.

Hardware Intrinsic API changes

The ARM64 intrinsics are not going to be considered stable for .NET Core 3.0. They were removed from in box and moved to a separate System.Runtime.Intrinsics.Experimental package that is available on our MyGet feed. This is a similar mechanism to what we did for the x86 intrinsics in .NET Core 2.1

Note: The following changes did not make Preview 4. They are already in the master branch and will be part of Preview 5.

The Avx2.ConvertToVector256* methods were changed to return a signed, rather than unsigned type. This puts them inline with the Sse41.ConvertToVector128* methods and the corresponding native intrinsics. As an example, Vector256<ushort> ConvertToVector256UInt16(Vector128<byte>) is now Vector256<short> ConvertToVector256Int16(Vector128<byte>).

The Sse41/Avx.ConvertToVector128/256* methods were split into those that take a Vector128/256<T> and those that take a T*. As an example, ConvertToVector256Int16(Vector128<byte>) now also has a ConvertToVector256Int16(byte*) overload. This was done because the underlying instruction which takes an address does a partial vector read (rather than a full vector read or a scalar read). This meant we were not able to always emit the optimal instruction coding when the user had to do a read from memory. This split, allows the user to explicitly select the addressing form of the instruction when needed (such as when you don’t already have a Vector128<T>).

The FloatComparisonMode enum entries and the Sse/Sse2.Compare methods were renamed to clarify that the operation is ordered/unordered and not the inputs. They were also reordered to be more consistent across the SSE and AVX implementations. An example is that Sse.CompareEqualOrderedScalar is now Sse.CompareScalarOrderedEqual. Likewise, for the AVX versions, Avx.CompareScalar(left, right, FloatComparisonMode.OrderedEqualNonSignalling) is now Avx.CompareScalar(left, right, FloatComparisonMode.EqualOrderedNonSignalling).

Assembly Load Context Improvements

Enhancements to AssemblyLoadContext:

• Enable naming contexts
• Added the ability to enumerate ALCs
• Added the ability to enumerate assemblies within an ALC
• Made the type concrete – so instantiation is easier (no requirement for custom types for simple scenarios)

See dotnet/corefx #34791 for more details.

The appwithalc sample demonstrates these new capabilities. The output from that sample is displayed below.

Hello ALC(World)!

Enumerate over all ALCs:
Default

Enumerate over all assemblies in "Default" ALC:
System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
appwithalc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Runtime.Loader, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
System.Console, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Threading, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Text.Encoding.Extensions, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Load "library" assembly via new "my custom ALC" ALC
Foo: Hello

Enumerate over all assemblies in "my custom ALC" ALC:
library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

Enumerate over all ALCs:
Default
my custom ALC

Load "library" assembly via Assembly.LoadFile
Foo: Hello

Enumerate over all ALCs:
Default
my custom ALC
Assembly.LoadFile(C:\git\testapps\appwithalc\appwithalc\bin\Debug\netcoreapp3.0\library.dll)

Closing

Thanks for trying out .NET Core 3.0. Please continue to give us feedback, either in the comments or on GitHub. We are listening carefully and will continue to make changes based on your feedback.

Take a look at the .NET Core 3.0 Preview 1, Preview 2 and Preview 3 posts if you missed those. With this post, they describe the complete set of new capabilities that have been added so far with the .NET Core 3.0 release.

The post Announcing .NET Core 3 Preview 4 appeared first on .NET Blog.

Today, we are making the fourth preview of Entity Framework Core 3.0 available on NuGet, alongside .NET Core 3.0 Preview 4 and ASP.NET Core 3.0 Preview 4. We encourage you to install this preview to test the new functionality and assess the impact of the included breaking changes.

What’s new in EF Core 3.0 Preview 4?

This preview includes more than 50 bug fixes and functional enhancements. You can query our issue tracker for the full list of issues fixed in Preview 4, as well as for the issues fixed in Preview 3, and Preview 2.

Some of the most important changes are:

LINQ queries are no longer evaluated on the client

The new LINQ implementation that we will introduce in an upcoming preview will not support automatic client evaluation except on the last select operator on your query. In preparation for this change, in preview 4 we have switched the existing client evaluation behavior to throw by default.

Although it should still be possible to restore the old behavior by re-configuring client evaluation to only cause a warning, we recommend that you test your application with the new default. If you see client evaluation exceptions, you can try modifying your queries to avoid client evaluation. If that doesn’t work, you can introduce calls to AsEnumerable() or ToList() to explicitly switch the processing of the query to the client in places where this is acceptable. You can use raw SQL queries instead of LINQ if none of these options work for you.

See the breaking change details to learn more about why we are making this change.

If you hit any case in which a LINQ expression isn’t translated to SQL and you get a client evaluation exception instead, but you know exactly what SQL translation you expect to get, we ask you to create an issue to help us improve EF Core.

The EF Core runtime is no longer part of the ASP.NET Core shared framework

Note that this change was actually introduced in Preview 1 but was not previously announced in this blog.

The main consequence of this change is that no matter what type of application you are building or what database your application uses, you always obtain EF Core by installing the NuGet package for the EF Core provider of your choice.

In any operating system supported for .NET Core development, you can install the preview bits by installing a provider for EF Core 3.0 Preview 4. For example, to install the SQLite provider, type this in the command line:

$ dotnet add package Microsoft.EntityFrameworkCore.Sqlite -v 3.0.0-preview4.19216.3

Or from the Package Manager Console in Visual Studio:

PM> Install-Package Microsoft.EntityFrameworkCore.Sqlite -Version 3.0.0-preview4.19216.3

See the breaking change details for more information.

The dotnet ef tool is no longer part of the .NET Core SDK

This change allows us to ship dotnet ef as a regular .NET CLI tool that can be installed as either a global or local tool.For example, to be able to manage migrations or scaffold a DbContext, install dotnet ef as a global tool typing the following command:

$ dotnet tool install --global dotnet-ef --version 3.0.0-preview4.19216.3

For more information, see this breaking change’s details.

Dependent entities sharing tables with their principal entities can now be optional

This enables for example, owned entities mapped to the same table as the owner to be optional, which is a frequently requested improvement.

See issue #9005 for more details.

Key generation improvements for in-memory database

We have made several improvements to simplify using in-memory database for unit testing. For example, each generated property now gets incremented independently. Also, when the database is deleted, key generation is reset and starts at 1. Finally, if a property in an entity contains a value larger than the last value returned by the generator, the latter is bumped to start on the next available value.

For more details, see issue #6872.

Separate methods for working with raw SQL queries as plain strings or interpolated strings

The existence of method overloads accepting SQL as plain strings or interpolated strings made it very hard to predict which version would be used and how parameters would be processed. To eliminate this source of confusion, we added the new methods FromSqlRaw, FromSqlInterpolated, ExecuteSqlRaw, and ExecuteSqlInterpolated. The existing FromSql and ExecuteSqlCommand methods are now obsolete.

See issue #10996 for more details.

Database connection no longer remains open until a TransactionScope is disposed

This makes EF Core work better with database providers that are optimized to work with System.Transactions, like SqlClient and Npgsql.

See this breaking change’s details for more information.

Code Analyzer that detects usage of EF Core internal APIs

EF Core exposes some of its internal APIs in public types. For example, all types under nested EF Core namespaces named Internal are considered internal APIs even if they are technically public types. In the past, this made it easy for application developers and provider writers to unintentionally use internal APIs in their code. With this new analyzer, using EF Core internal APIs produces a warning by default. For example:

EF1001: Microsoft.EntityFrameworkCore.Internal.MethodInfoExtensions is an internal API that supports the Entity Framework Core infrastructure and not subject to the same compatibility standards as public APIs. It may be changed or removed without notice in any release.

If the usage is intentional, the warning can be suppressed like any code analysis warning.

See issue #12104 for more details.

Improved performance of iterating over tracked entities using .Local

We have improved the implementation so that iterating over the contents of .Local is around three times faster. If you are going to iterate multiple times, you should still consider calling ToObservableCollection() first.

See issue #14231 for more details.

The concept of query types has been renamed to entities without keys

Note that this change was included in preview 3 but wasn’t previously announced in this blog.

Query types were introduced in EF Core 2.1 to enable reading data from database tables and views that didn’t contain unique keys. Having query types as a separate concept from entity types has proven to obscure their purpose and what makes them different. It also led us to have to introduce some undesired redundancy and unintended inconsistencies in our APIs. We believe the consolidation of the concepts and eventual removal of the query types API will help reduce the confusion.

See the breaking change details for more information.

New preview of the Cosmos DB provider for EF Core

Although the work is still far from complete, we have been making progress on the provider in successive previews of EF Core 3.0. For example, the new version takes advantage of the new Cosmos DB SDK, enables customizing the names of properties used in the storage, handles value conversions, uses a deterministic approach for key generation, and allows specifying the Azure region to use.

For full details, see the Cosmos DB provider task list on our issue tracker.

What’s next?

As detailed in our list of new features, in 3.0 we plan to deliver an improved LINQ implementation, Cosmos DB support, support for C# 8.0 features like nullable reference types and async collections, reverse engineering of database views, property bag entities, and a new version of EF6 that can run on .NET Core.

In the first 4 previews, we focused most of our efforts on the improvements that we believed could have the highest impact on existing applications and database providers tying to upgrade from previous versions. Implementing these “breaking changes” and architectural improvements early on gives us more time to gather feedback and react to unanticipated issues. But it also means that many of those important features have had to wait until later previews. At this point, you can expect initial support for most of the 3.0 features to arrive within the next couple of preview cycles.

In order to make it easier for you to track our progress, from now on, we will be posting weekly status updates on GitHub. You can subscribe to notifications to get an email every time we post an update.

We would also like to take this opportunity to talk about important adjustments we are making moving forward:

EF Core 3.0 will target .NET Standard 2.1

After investigating several options, we have concluded that making EF Core 3.0 target .NET Standard 2.1 is the best path to take advantage of new features in .NET and C#, like integration with IAsyncEnumerable<T>. This is consistent with similar decisions announced last year for ASP.NET Core 3.0 and C# 8.0, and enables us to move forward without introducing compatibility adapters that could hinder our ability to deliver great new functionality on .NET Core down the road.

Although Preview 4 still targets .NET Standard 2.0, the RTM version will require 2.1 and therefore will not be compatible with .NET implementations that only support .NET Standard 2.0, like .NET Framework. Customers that need to run EF Core on .NET Framework, should plan to continue using EF Core 2.1 or 2.2.

EF 6.3 will target .NET Standard 2.1, in addition to already supported .NET Framework versions

We found that the API surface offered by .NET Standard 2.1 is adequate for supporting EF6 without removing any runtime features. In addition to .NET Standard 2.1, the EF 6.3 NuGet package will as usual support .NET Framework 4.0 (without async support) and .NET Framework 4.5 and newer. For the time being, we are only going to test and support EF 6.3 running on .NET Framework and .NET Core 3.0. But targeting .NET Standard 2.1 opens the possibility to have EF 6.3 working on other .NET implementations, as long as they fully implement the standard and don’t have other runtime limitations.

Closing

The EF team would like to thank everyone for their feedback and their contributions to this preview. Once more, we encourage you to try out the latest bits and submit any new feedback to our issue tracker.

The post Announcing Entity Framework Core 3.0 Preview 4 appeared first on .NET Blog.

Upcoming Updates for .NET Framework 4.8

The .NET Framework 4.8 product release is now available. The .NET Framework 4.8 product will receive updates on the same cadence and the usual channels (Windows Update, WSUS, Catalog) as all .NET Framework and Windows cumulative updates. For Windows 10, .NET Framework 4.8 updates will now be delivered as independent updates, alongside the Windows cumulative updates.  In this post, I explain how updates to .NET Framework 4.8 are delivered so you are ready for them.

What is new about .NET Framework 4.8 updates?

Updates for .NET Framework 4.8 on Windows 10 versions 1607, 1703, 1709, 1803 and Server 2016 will now be delivered independently and side by side with Windows cumulative updates. The way we update .NET Framework in Windows 10 version 1809 and Server 2019 is not changing and is described below.

What does not change?

Updates to .NET Framework 4.8 on Windows 8.1, Server 2012 R2, Server 2012, Windows 7 SP1, and Server 2008 R2 SP1 will continue to be delivered outside of the Windows cumulative update through the existing .NET Framework updates.

The update for .NET Framework 4.8 will be included into the .NET Framework Rollup, for each operating system. Likewise, for Windows 10 version 1809, Server 2019, and future releases, .NET Framework 4.8 will be updated as part of the existing .NET Framework updates.

The delivery of updates to all previous versions of .NET Framework (i.e. .NET 4.7.2, 4.7.1, 4.7, 4.6.2, 4.6.1, 4.6, 4.5.2, and 3.5) across all supported operating systems does not change. There is no change in the way you acquire or install these updates.

What should I expect?

You can expect the following experiences:

Windows update customers:

• If you rely on Windows Update to keep your machine up to date and have automatic updates enabled, you will not notice any difference.  Updates for both Windows and the .NET Framework 4.8 and previous versions will be silently installed, and as usual you may be prompted for a reboot after installation.
• If you manage Windows Update manually, you will notice that updates for .NET Framework 4.8 will be available alongside Windows cumulative updates. Please continue to apply the latest updates to keep your system up to date.

System and IT Administrators:

• System administrators relying on Windows Server Update Services (WSUS) and similar update management applications will observe a new update for .NET Framework 4.8 when checking for updates applicable to Windows 10 versions 1607, 1703, 1709, 1803 and Server 2016. For all other operating systems the update for .NET Framework 4.8 will continue to be included into the existing .NET Framework update.
• The Classifications for Updates for .NET Framework 4.8 remain the same as for the Cumulative Update for Windows and continue to show under “Windows” Products. Updates that deliver new Security content will have the “Security Updates” classification and updates that solely carry new quality updates will either have the “Updates” or “Critical Updates” classification, depending on their criticality.
• System administrators that rely on the Microsoft Update Catalog will be able to access updates for .NET Framework 4.8 by searching for each releases’ Knowledge Based (KB) update number.
• You can use the update title to filter between the Windows Cumulative updates and .NET Framework updates. All other update artifacts remain the same.

.NET Update release vehicles across operating systems

Updates for .NET Framework 4.8 are delivered as described in the below table.

Frequently Asked Questions (FAQ)

• What is the .NET Framework 4.8 product?

More information about the .NET Framework 4.8 product here: https://devblogs.microsoft.com/dotnet/announcing-the-net-framework-4-8/

• If I don’t upgrade to .NET Framework 4.8 will anything change for how I receive Windows or .NET updates?

No. Updates for previous versions of .NET Framework and for Windows operating systems components remain the same.

• Why are updates to all .NET Framework versions not delivered through a consistent single rollup vehicle across operating systems?

We aim to keep the .NET Framework update experience as smooth and consistent as possible across supported operating systems. Specifically for Windows 10 versions 1607, 1703, 1709, 1803 and Server 2016 systems (where .NET rollup updates did not exist), we chose to introduce the least possible change, and leave the experience untouched for updating previous versions of .NET Framework (i.e. .NET 4.7.2 and below). For .NET Framework 4.8 we are able to offer the same agility and flexibility as described in our recent post announcing cumulative updates for .NET Framework for Windows 10 October 2018 update across all operating systems.

• I am an IT Administrator managing updates for my organization, how do I ensure that my deployments include all existing versions of .NET Framework?

As noted above, continue to rely on the same mechanisms for Windows and .NET Framework updates. Ensure that within your WSUS, SCCM or similar environment, you select updates that correspond to the “Windows” Product, and continue to rely on the Classifications categories to select all applicable updates that align with your organization’s update criteria for Security and non-security content. This will ensure you continue to receive updates for all .NET Framework versions.

• I rely on downloading updates from the Microsoft Update Catalog to support my organization’s internet-disconnected scenarios. Do I need to do anything differently to update systems with .NET Framework 4.8?

Whether you depend directly on the Microsoft Update Catalog website or import updates from Catalog into your managed environments (e.g. WSUS, or SCCM), please continue to rely on the Knowledge Base(KB) number lookup functionality to access .NET Framework updates. For operating systems where .NET Framework rollup updates existing already, continue to search and download the KBs for each target operating system. On operating systems where .NET Framework rollups did not previously exist (i.e. Windows 10 versions 1607, 1703, 1709, 1803 and Server 2016), search for the corresponding KB numbers that are specific to updates for .NET Framework 4.8.

• Does anything change about the way updates to .NET Framework 3.5 get delivered once I upgrade to .NET Framework 4.8?

The .NET Framework 3.5 will continue to be delivered the same way (refer to the “.NET updates across Windows versions” table above).

For Windows 8.1 and previous operating systems, .NET Framework 3.5 updates are included in the .NET Framework Rollup.

For Windows 10 versions 1507, 1607, Server 2016, 1703, 1709, 1803, .NET Framework 3.5 updates are included in the Windows Cumulative updates.

For Windows 10 version 1809, Server 2019 and future versions, .NET Framework 3.5 updates are included in the .NET Framework Cumulative Update.

Please continue to install both .NET Framework 4.8 and Windows cumulative updates to be up to date for all .NET Framework versions.

The post Upcoming Updates for .NET Framework 4.8 appeared first on .NET Blog.

Today at Spark + AI summit we are excited to announce .NET for Apache Spark. Spark is a popular open source distributed processing engine for analytics over large data sets. Spark can be used for processing batches of data, real-time streams, machine learning, and ad-hoc query.

.NET for Apache Spark is aimed at making Apache® Spark accessible to .NET developers across all Spark APIs. So far Spark has been accessible through Scala, Java, Python and R but not .NET.

We plan to develop .NET for Apache Spark in the open (as a .NET Foundation member project) along with the Spark and .NET community to ensure that developers get the best of both worlds.

https://github.com/dotnet/spark Star

The remainder of this post provides more specifics on the following topics:

• What is .NET For Apache Spark?
• Getting Started with .NET for Apache Spark
• .NET for Apache Spark performance
• What’s next with .NET For Apache Spark
• Wrap Up

What is .NET for Apache Spark?

.NET for Apache Spark provides high performance APIs for using Spark from C# and F#. With this .NET APIs, you can access all aspects of Apache Spark including Spark SQL, DataFrames, Streaming, MLLib etc. .NET for Apache Spark lets you reuse all the knowledge, skills, code, and libraries you already have as a .NET developer.

The C#/ F# language binding to Spark will be written on a new Spark interop layer which offers easier extensibility. This new layer of Spark interop was written keeping in mind best practices for language extension and optimizes for interop and performance. Long term this extensibility can be used for adding support for other languages in Spark.

You can learn more details about this work through this proposal.

.NET for Apache Spark is compliant with .NET Standard 2.0 and can be used on Linux, macOS, and Windows, just like the rest of .NET. .NET for Apache Spark is available by default in Azure HDInsight, and can be installed in Azure Databricks and more.

Getting Started with .NET for Apache Spark

// 1. Create a Spark session
var spark = SparkSession
    .Builder()
    .AppName("word_count_sample")
    .GetOrCreate();

// 2. Create a DataFrame
DataFrame dataFrame = spark.Read().Text("input.txt");

// 3. Manipulate and view data
var words = dataFrame.Select(Split(dataFrame["value"], " ").Alias("words"));

words.Select(Explode(words["words"])
    .Alias("word"))
    .GroupBy("word")
    .Count()
    .Show();

The post Introducing .NET for Apache® Spark™ Preview appeared first on .NET Blog.

Today, we are announcing .NET Core 3 Preview 2. It includes new features in .NET Core 3.0 and C# 8, in addition to the large number of new features in Preview 1. ASP.NET Core 3.0 Preview 2  is also released today. C# 8 Preview 2 is part of .NET Core 3 SDK, and was also released last week with Visual Studio 2019 Preview 2.

Download and get started with .NET Core 3 Preview 2 right now on Windows, macOS and Linux.

In case you missed it, we made some big announcements with Preview 1, including adding support for Windows Forms and WPF with .NET Core, on Windows, and that both UI frameworks will be open source. We also announced that we would support Entity Framework 6 on .NET Core, which will come in a later preview. ASP.NET Core is also adding many features including Razor components.

Please provide feedback on the release in the comments below or at dotnet/core #2263. You can see complete details of the release in the .NET Core 3 Preview 2 release notes.

.NET Core 3 will be supported in Visual Studio 2019, Visual Studio for Mac and Visual Studio Code. Visual Studio 2019 Preview 2 was released last week and has support for C# 8. The Visual Studio Code C# Extension (in pre-release channel) was also just updated to support C# 8.

C# 8

C# 8 is a major release of the language, as Mads describes in Do more with patterns in C# 8.0, Take C# 8.0 for a spin and Building C# 8.0. In this post, I’ll cover a few favorites that are new in Preview 2.

Using Declarations

Are you tired of using statements that require indenting your code? No more! You can now write the following code, which attaches a using declaration to the scope of the current statement block and then disposes the object at the end of it.

Switch Expressions

Anyone who uses C# probably loves the idea of a switch statement, but not the syntax. C# 8 introduces switch expressions, which enable the following: terser syntax, returns a value since it is an expression, and fully integrated with pattern matching. The switch keyword is “infix”, meaning the keyword sits between the tested value (here, that’s o) and the list of cases, much like expression lambdas. The following examples use the lambda syntax for methods, which integrates well with switch expressions but isn’t required.

You can see the syntax for switch expressions in the following example:

There are two patterns at play in this example. o first matches with the Point type pattern and then with the property pattern inside the {curly braces}. The _ describes the discard pattern, which is the same as default for switch statements.

You can go one step further, and rely on tuple deconstruction and parameter position, as you can see in the following example:

In this example, you can see you do not need to define a variable or explicit type for each of the cases. Instead, the compiler can match the tuple being testing with the tuples defined for each of the cases.

All of these patterns enable you to write declarative code that captures your intent instead of procedural code that implements tests for it. The compiler becomes responsible for implementing that boring procedural code and is guaranteed to always do it correctly.

There will still be cases where switch statements will be a better choice than switch expressions and patterns can be used with both syntax styles.

Async streams

Async streams are another major improvement in C# 8. They have been changing with each preview and require that the compiler and the framework libraries match to work correctly. You need .NET Core 3.0 Preview 2 to use async streams if you want to develop with either Visual Studio 2019 Preview 2 or the latest preview of the C# extension for Visual Studio Code. If you are using .NET Core 3.0 Preview 2 at the commandline, then everything will work as expected.

IEEE Floating-point improvements

Floating point APIs are in the process of being updated to comply with IEEE 754-2008 revision. The goal of this floating point project is to expose all “required” operations and ensure that they are behaviorly compliant with the IEEE spec.

Parsing and formatting fixes:

• Correctly parse and round inputs of any length.
• Correctly parse and format negative zero.
• Correctly parse Infinity and NaN by performing a case-insensitive check and allowing an optional preceding + where applicable.

New Math APIs:

• BitIncrement/BitDecrement — corresponds to the nextUp and nextDown IEEE operations. They return the smallest floating-point number that compares greater or lesser than the input (respectively). For example, Math.BitIncrement(0.0) would return double.Epsilon.
• MaxMagnitude/MinMagnitude — corresponds to the maxNumMag and minNumMag IEEE operations, they return the value that is greater or lesser in magnitude of the two inputs (respectively). For example, Math.MaxMagnitude(2.0, -3.0) would return -3.0.
• ILogB — corresponds to the logB IEEE operation which returns an integral value, it returns the integral base-2 log of the input parameter. This is effectively the same as floor(log2(x)), but done with minimal rounding error.
• ScaleB — corresponds to the scaleB IEEE operation which takes an integral value, it returns effectively x * pow(2, n), but is done with minimal rounding error.
• Log2 — corresponds to the log2 IEEE operation, it returns the base-2 logarithm. It minimizes rounding error.
• FusedMultiplyAdd — corresponds to the fma IEEE operation, it performs a fused multiply add. That is, it does (x * y) + z as a single operation, there-by minimizing the rounding error. An example would be FusedMultiplyAdd(1e308, 2.0, -1e308) which returns 1e308. The regular (1e308 * 2.0) - 1e308 returns double.PositiveInfinity.
• CopySign — corresponds to the copySign IEEE operation, it returns the value of x, but with the sign of y.

.NET Platform Dependent Intrinsics

We’ve added APIs that allow access to certain perf-oriented CPU instructions, such as the SIMD or Bit Manipulation instruction sets. These instructions can help achieve big performance improvements in certain scenarios, such as processing data efficiently in parallel. In addition to exposing the APIs for your programs to use, we have begun using these instructions to accelerate the .NET libraries too.

The following CoreCLR PRs demonstrate a few of the intrinsics, either via implementation or use:

• Implement simple SSE2 hardware instrinsics
• Implement the SSE hardware intrinsics
• Arm64 Base HW Intrinsics
• Use TZCNT and LZCNT for Locate{First|Last}Found{Byte|Char}

For more information, take a look at .NET Platform Dependent Intrinsics, which defines an approach for defining this hardware infrastructure, allowing Microsoft, chip vendors or any other company or individual to define hardware/chip APIs that should be exposed to .NET code.

Introducing a fast in-box JSON Writer & JSON Document

Following the introduction of the JSON reader in preview1, we’ve added System.Text.Json.Utf8JsonWriter and System.Text.Json.JsonDocument.

As described in our System.Text.Json roadmap, we plan to provide a POCO serializer and deserializer next.

Utf8JsonWriter

The Utf8JsonWriter provides a high-performance, non-cached, forward-only way to write UTF-8 encoded JSON text from common .NET types like String, Int32, and DateTime. Like the reader, the writer is a foundational, low-level type, that can be leveraged to build custom serializers. Writing a JSON payload using the new Utf8JsonWriter is 30-80% faster than using the writer from Json.NET and does not allocate.

Here is a sample usage of the Utf8JsonWriter that can be used as a starting point:

The Utf8JsonWriter accepts IBufferWriter<byte> as the output location to synchronously write the json data into and you, as the caller, need to provide a concrete implementation. The platform does not currently include an implementation of this interface, but we plan to provide one that is backed by a resizable byte array. That implementation would enable synchronous writes, which could then be copied to any stream (either synchronously or asynchronously). If you are writing JSON over the network and include the System.IO.Pipelines package, you can leverage the Pipe-based implementation of the interface called PipeWriter to skip the need to copy the JSON from an intermediary buffer to the actual output.

You can take inspiration from this sample implementation of IBufferWriter<T>. The following is a skeleton array-backed concrete implementation of the interface:

JsonDocument

In preview2, we’ve also added System.Text.Json.JsonDocument which was built on top of the Utf8JsonReader. The JsonDocument provides the ability to parse JSON data and build a read-only Document Object Model (DOM) that can be queried to support random access and enumeration. The JSON elements that compose the data can be accessed via the JsonElement type which is exposed by the JsonDocument as a property called RootElement. The JsonElement contains the JSON array and object enumerators along with APIs to convert JSON text to common .NET types. Parsing a typical JSON payload and accessing all its members using the JsonDocument is 2-3x faster than Json.NET with very little allocations for data that is reasonably sized (i.e. < 1 MB).

Here is a sample usage of the JsonDocument and JsonElement that can be used as a starting point:

GPIO Support for Raspberry Pi

We added initial support for GPIO with Preview 1. As part of Preview 2, we have released two NuGet packages that you can use for GPIO programming.

• System.Device.Gpio
• Iot.Device.Bindings

The GPIO Packages includes APIs for GPIO, SPI, I2C and PWM devices. The IoT bindings package includes device bindings for various chips and sensors, the same ones available at dotnet/iot – src/devices.

Updated serial port APIs were announced as part of Preview 1. They are not part of these packages but are available as part of the .NET Core platform.

Local dotnet tools

Local dotnet tools have been improved in Preview 2. Local tools are similar to dotnet global tools but are associated with a particular location on disk. This enables per-project and per-repository tooling. You can read more about them in the .NET Core 3.0 Preview 1 post.

In this preview, we have added 2 new commands:

• dotnet new tool-manifest
• dotnet tool list

To add local tools, you need to add a manifest that will define the tools and versions available. The dotnet new tool-manifest command automates creation of the manifest required by local tools. After this file is created, you can add tools to it via dotnet tool install <packageId>.

The command dotnet tool list lists local tools and their corresponding manifest. The command dotnet tool list -g lists global tools.

There was a change in .NET Core Local Tools between .NET Core 3.0 Preview 1 and .NET Core 3.0 Preview 2. If you tried out local tools in Preview 1 by running a command like dotnet tool restore or dotnet tool install, you need to delete your local tools cache folder before local tools will work correctly in Preview 2. This folder is located at:

On mac, Linux: rm -r $HOME/.dotnet/toolResolverCache

On Windows: rmdir /s %USERPROFILE%\.dotnet\toolResolverCache

If you do not delete this folder, you will receive an error.

Assembly Unloadability

Assembly unloadability is a new capability of AssemblyLoaderContext. This new feature is largely transparent from an API perspective, exposed with just a few new APIs. It enables a loader context to be unloaded, releasing all memory for instantiated types, static fields and for the assembly itself. An application should be able to load and unload assemblies via this mechanism forever without experiencing a memory leak.

We expect this new capability to be used for the following scenarios:

• Plugin scenarios where dynamic plugin loading and unloading is required.
• Dynamically compiling, running and then flushing code. Useful for web sites, scripting engines, etc.
• Loading assemblies for introspection (like ReflectionOnlyLoad), although MetadataLoadContext (released in Preview 1) will be a better choice in many cases.

More information:

• Design doc
• Using Unloadability doc

Assembly unloading requires significant care to ensure that all references to managed objects from outside a loader context are understood and managed. When the loader context is requested to be unloaded, any outside references need to have been unreferenced so that the loader context is self-consistent only to itself.

Assembly unloadability was provided in the .NET Framework by Application Domains (AppDomains), which are not supported with .NET Core. AppDomains had both benefits and limitations compared to this new model. We consider this new loader context-based model to be more flexible and higher performance when compared to AppDomains.

Windows Native Interop

Windows offers a rich native API, in the form of flat C APIs, COM and WinRT. We’ve had support for P/Invoke since .NET Core 1.0, and have been adding the ability to CoCreate COM APIs and Activate WinRT APIs as part of the .NET Core 3.0 release. We have had many requests for these capabilities, so we know that they will get a lot of use.

Late last year, we announced that we had managed to automate Excel from .NET Core. That was a fun moment. You can now try this same demo yourself with the Excel demo sample. Under the covers, this demo is using COM interop features like NOPIA, object equivalence and custom marshallers.

Managed C++ and WinRT interop are coming in a later preview. We prioritized getting COM interop built first.

WPF and Windows Forms

The WPF and Windows Forms teams opened up their repositories, dotnet/wpf and dotnet/winforms, respectively, on December 4th, the same day .NET Core 3.0 Preview 1 was released. Much of the last month, beyond holidays, has been spent interacting with the community, merging PRs, and responding to issues. In the background, they’ve been integrating WPF and Windows Forms into the .NET Core build system, including adopting the Arcade SDK. Arcade is an MSBuild SDK that exposes functionality which is needed to build the .NET Platform. The WPF team will be publishing more of the WPF source code over the coming months.

The same teams have been making a final set of changes in .NET Framework 4.8. These same changes have also been added to the .NET Core versions of WPF and Windows Forms.

Visual Studio support

Desktop development on .NET Core 3 requires Visual Studio 2019. We added the WPF and Windows Forms templates to the New Project Dialog to make it easier starting your new applications without using the command line.

The WPF and Windows Forms designer teams are continuing to work on an updated designer for .NET Core, which will be part of a Visual Studio 2019 Update.

MSIX Deployment for Desktop apps

MSIX is a new Windows app package format. It can be used to deploy .NET Core 3 desktop applications to Windows 10.

The Windows Application Packaging Project, available in Visual Studio 2019 preview 2, allows you to create MSIX packages with self-contained .NET Core applications.

Note: The .NET Core project file must specify the supported runtimes in the <RuntimeIdentifiers> property:

<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>

Install .NET Core 3.0 Previews on Linux with Snap

Snap is the preferred way to install and try .NET Core previews on Linux distributions that support Snap. At present, only X64 builds are supported with Snap. We’ll look at supporting ARM builds, too.

After configuring Snap on your system, run the following command to install the .NET Core SDK 3.0 Preview SDK.

sudo snap install dotnet-sdk --beta --classic

When .NET Core in installed using the Snap package, the default .NET Core command is dotnet-sdk.dotnet, as opposed to just dotnet. The benefit of the namespaced command is that it will not conflict with a globally installed .NET Core version you may have. This command can be aliased to dotnet with:

sudo snap alias dotnet-sdk.dotnet dotnet

Some distros require an additional step to enable access to the SSL certificate. See our Linux Setup for details.

Platform Support

.NET Core 3 will be supported on the following operating systems:

• Windows Client: 7, 8.1, 10 (1607+)
• Windows Server: 2012 R2 SP1+
• macOS: 10.12+
• RHEL: 6+
• Fedora: 26+
• Ubuntu: 16.04+
• Debian: 9+
• SLES: 12+
• openSUSE: 42.3+
• Alpine: 3.8+

Chip support follows:

• x64 on Windows, macOS, and Linux
• x86 on Windows
• ARM32 on Windows and Linux
• ARM64 on Linux

For Linux, ARM32 is supported on Debian 9+ and Ubuntu 16.04+. For ARM64, it is the same as ARM32 with the addition of Alpine 3.8. These are the same versions of those distros as is supported for X64. We made a conscious decision to make supported platforms as similar as possible between X64, ARM32 and ARM64.

Docker images for .NET Core 3.0 are available at microsoft/dotnet on Docker Hub. We are in the process of adopting Microsoft Container Registry (MCR). We expect that the final .NET Core 3.0 images will only be published to MCR.

Closing

Take a look at the .NET Core 3.0 Preview 1 post if you missed that. It includes a broader description of the overall release including the initial set of features, which are also included and improved on in Preview 2.

Thanks to everyone that installed .NET Core 3.0 Preview 1. We appreciate you trying out the new version and for your feedback. Please share any feedback you have about Preview 2.

This post was written by Lena Hall, a Senior Cloud Developer Advocate at Microsoft.

F# Software Foundation has recently announced their new initiative — Applied F# Challenge! We encourage you to participate and send your submissions about F# on Azure through the participation form.

Applied F# Challenge is a new initiative to encourage in-depth educational submissions to reveal more of the interesting, unique, and advanced applications of F#.

The motivation for the challenge is uncovering more of advanced and innovative scenarios and applications of F# we hear about less often:

We primarily hear about people using F# for web development, analytical programming, and scripting. While those are perfect use cases for F#, there are many more brilliant and less covered scenarios where F# has demonstrated its strength. For example, F# is used in quantum computing, cancer research, bioinformatics, IoT, and other domains that are not typically mentioned as often.

You have some time to think about the topic for your submission because the challenge is open from February 1 to May 20 this year.

What should you submit?

Publish a new article or an example code project that covers a use case of a scenario where you feel the use of F# to be essential or unique. The full eligibility criteria and frequently asked questions are listed in the official announcement.

There are multiple challenge categories you can choose to write about:

F# for machine learning and data science.
F# for distributed systems.
F# in the cloud: web, serverless, containers, etc.
F# for desktop and mobile development.
F# in your organization or domain: healthcare, finance, games, retail, etc.
F# and open-source development.
F# for IoT or hardware programming.
F# in research: quantum, bioinformatics, security, etc.
Out of the box F# topics, scenarios, applications, or examples.

Why should you participate in the challenge?

All submissions will receive F# stickers as a participation reward for contributing to the efforts of improving the F# ecosystem and raising awareness of F# strengths in advanced or uncovered use cases.

Participants with winning submissions in each category will also receive the title of a Recognized F# Expert by F# Software Foundation and a special non-monetary prize.

Each challenge category will be judged by the committees that include many notable F# experts and community leaders, including Don Syme, Rachel Blasucci, Evelina Gabasova, Henrik Feldt, Tomas Perticek, and many more.

As the participation form suggests, you will also have an opportunity to be included in a recommended speaker list by F# Software Foundation.

Spread the word

Help us spread the word about the Applied F# Challenge by encouraging others to participate with #AppliedFSharpChallenge hashtag on Twitter!

ML.NET is an open-source and cross-platform machine learning framework (Windows, Linux, macOS) for .NET developers. Using ML.NET, developers can leverage their existing tools and skillsets to develop and infuse custom AI into their applications by creating custom machine learning models.

ML.NET allows you to create and use machine learning models targeting common tasks such as classification, regression, clustering, ranking, recommendations and anomaly detection. It also supports the broader open source ecosystem by proving integration with popular deep-learning frameworks like TensorFlow and interoperability through ONNX. Some common use cases of ML.NET are scenarios like Sentiment Analysis, Recommendations, Image Classification, Sales Forecast, etc. Please see our samples for more scenarios.

Today we’re announcing the release of ML.NET 0.10. ( ML.NET 0.1 was released at //Build 2018). Note that ML.NET follows a semantic versioning pattern, so this preview version is 0.10. There will be additional versions such as 0.11 and 0.12 before we release v1.0.

This release focuses on the overall stability of the framework, continuing to refine the API, increase test coverage and as an strategic milestone, we have moved the IDataView components into a new and separated assembly under Microsoft.Data.DataView namespace so it will favor interoperability in the future.

The main highlights for this blog post are described below in further details:

• IDataView as a shared type across libraries in the .NET ecosystem
• Support for multiple ‘feature columns’ in recommendations (FFM based)
• Additional updates in v0.10 timeframe
• Explore the community samples and share yours!
• Planning to go to production?
• Get Started!

IDataView as a shared type across libraries in the .NET ecosystem

The IDataView component provides a very efficient, compositional processing of tabular data (columns and rows) especialy made for machine learning and advanced analytics applications. It is designed to efficiently handle high dimensional data and large data sets. It is also suitable for single node processing of data partitions belonging to larger distributed data sets.

For further info on IDataview read the IDataView design principles

What’s new in v0.10 for IDataView

In ML.NET 0.10 we have segregated the IDataView component into a single assembly and NuGet package. This is a very important step towards the interoperability with other APIs and frameworks.

Why segregate IDataView from the rest of the ML.NET framework?

This is a very important milestone that will help the ecosystem’s interoperability between multiple frameworks and libraries from Microsoft of third parties. By seggregating IDataView, different libraries will be able to reference it and use it from their API and allow users to pass large volumes of data between two independent libraries.

For example, from ML.NET you can of course consume and produce IDataView instances. But what if you need to integrate with a different framework by creating an IDataView from another API such as any “Data Preparation framework” library? If those frameworks can simply reference a single NuGet package with just the IDataView, then you can directly pass data into ML.NET from those frameworks without having to copy the data into a format that ML.NET consumes. Also, the additional framework wouldn’t depend on the whole ML.NET framework but just reference a very clean package limited to the IDataView.

The image below is an aspirational approach when using IDataView across frameworks in the ecosystem:

Another good example would be any plotting/charting library in the .NET ecosystem that could consume data using IDataView. You could take data that was produced by ML.NET and feed it directly into the plotting library without that library having a direct reference to the whole ML.NET framework. There would be no need to copy, or change the shape of the data at all. And there is no need for this plotting library to know anything about ML.NET.

Basically, IDataView can be an exchange data format which allows producers and consumers to pass large amounts of data in a standarized way.

For additional info check the PR #2220

Support for multiple ‘feature columns’ in recommendations (FFM based)

In previous ML.NET releases, when using the Field-aware Factorization Machine (FFM) trainer (training algorithm) you could only provide a single feature column like in this sample app

In 0.10 release we’ve added support for multiple ‘feature columns’ in your training dataset when using an FFM trainer by allowing to specify those additional column names in the trainer’s ‘Options’ parameter as shown in the following code snippet:

var ffmArgs = new FieldAwareFactorizationMachineTrainer.Options();

// Create the multiple field names.
ffmArgs.FeatureColumn = nameof(MyObservationClass.MyField1); // First field.
ffmArgs.ExtraFeatureColumns = new[]{ nameof(MyObservationClass.MyField2), nameof(MyObservationClass.MyField3) }; // Additional fields.

var pipeline = mlContext.BinaryClassification.Trainers.FieldAwareFactorizationMachine(ffmArgs);

var model = pipeline.Fit(dataView);

You can see additional code example details in this code

Additional updates in v0.10 timeframe

Support for returning multiple predicted labels

Until ML.NET v0.9, when predicting (for instance with a multi-class classification model), you could only predict and return a single label. That’s an issue for many business scenarios. For instance, in an eCommerce scenario, you could want to automatically classify a product and assign it to multiple product categories instead of just a single category.

However, when predicting, ML.NET internally already had a list of the multiple possible predictions with a score/proability per each in the schema’s data, but the API was simply not returning the list of possible predicted labels but a single one.

Therefore, this improvement allows you to access the schema’s data so you can get a list of the predicted labels which can then be related to their scores/proabilities provided by the float[] Score array in your Prediction class, such as in this sample prediction class.

For additional info check this code example

Minor updates in 0.10

• Introducing Microsoft.ML.Recommender NuGet name instead of Microsoft.ML.MatrixFactorization name: Microsoft.ML.Recommender] is a better naming for NuGet packages based on the scenario (Recommendations) instead of the trainer’s name (Microsoft.ML.MatrixFactorization).

• Added support in TensorFlow for using using text and sparse input in TensorFlow: Specifically, this adds support for loading a map from a file through dataview by using ValueMapperTransformer. This provides support for additional scenarios like a Text/NLP scenario) in TensorFlowTransform where model’s expected input is vector of integers.

• Added Tensorflow unfrozen models support in GetModelSchema: For a code example loading an unfrozen TensorFlow check it out here.

Breaking changes in ML.NET 0.10

For your convenience, if you are moving your code from ML.NET v0.9 to v0.10, you can check out the breaking changes list that impacted our samples.

Instrumented code coverage tools as part of the ML.NET CI systems

We have also instrumented code coverage tools (using https://codecov.io/) as part of our CI systems and will continue to push for stability and quality in the code.

You can check it out here which is also a link in the home page of the ML.NET repo:

Once you click on that link, you’ll see the current code coverage for ML.NET:

Explore the community samples and share yours!!

As part of the ML.NET Samples repo we also have a special Community Samples page pointing to multiple samples provided by the community. These samples are not maintained by Microsoft but are very interesting and cover additional scenarios not covered by us.

Here’s an screenshot of the current community samples:

There are pretty cool samples like the following:

‘Photo-Search’ WPF app running a TensorFlow model exported to ONNX format

UWP app using ML.NET

Other very interesting samples are:

• ML.NET custom Transform implementation

• ML.NET samples in VB.NET

Share your sample with the ML.NET community!

We encourage you to share your ML.NET demos and samples with the community by simply submitting its brief description and URL pointing to your GitHub repo or blog posts, into this repo issue “Request for your samples!”.

We’ll do the rest and publish it at the ML.NET Community Samples page!

Planning to go to production?

If you are using ML.NET in your app and looking to go into production, you can talk to an engineer on the ML.NET team to:

1. Get help implementing ML.NET successfully in your application.
2. Demo your app and potentially have it featured on the .NET Blog, dot.net site, or other Microsoft channel.

Fill out this form and someone from the ML.NET team will contact you.

Get started!

If you haven’t already get started with ML.NET here.

Next, going further explore some other resources:

• Tutorials and resources at the Microsoft Docs ML.NET Guide
• Code samples at the machinelearning-samples GitHub repo
• Important ML.NET concepts for understanding the new API are introduced here
• “How to” guides that show how to use these APIs for a variety of scenarios can be found here
• Download the Visual Studio templates for ML.NET from the Visual Studio Marketplace

We will appreciate your feedback by filing issues with any suggestions or enhancements in the ML.NET GitHub repo to help us shape ML.NET and make .NET a great platform of choice for Machine Learning.

Thanks and happy coding with ML.NET!

The ML.NET Team.

This blog was authored by Cesar de la Torre and Eric Erhardt plus additional contributions of the ML.NET team

Today, we are releasing the .NET Core February 2019 Update. These updates contain security and reliability fixes. See the individual release notes for details on included reliability fixes.

• .NET Core 2.2.2 and .NET Core SDK 2.2.104 ( Download | Release Notes )
• .NET Core 2.1.8 and .NET Core SDK 2.1.504 ( Download | Release Notes )
• .NET Core 1.1.11 and .NET Core SDK 1.1.12 ( Download | Release Notes )
• .NET Core 1.0.14 and .NET Core SDK 1.1.12 ( Download | Release Notes )

Security

Microsoft Security Advisory CVE-2019-0657: .NET Core Domain Spoofing Vulnerability

A domain spoofing vulnerability exists in .NET Framework and .NET Core which causes the meaning of a URI to change when International Domain Name encoding is applied. An attacker who successfully exploited the vulnerability could redirect a URI. This issue effects .NET Core 1.0, 1.1 2.1 and 2.2.

The security update addresses the vulnerability by not allowing certain Unicode characters from the URI.

Getting the Update

The latest .NET Core updates are available on the .NET Core download page. This update is also included in the Visual Studio 15.0.21 (.NET Core 1.0 and 1.1) and 15.9.7 (.NET Core 1.0, 1.1 and 2.1) updates, which is also releasing today.

See the .NET Core release notes ( 1.0.14 | 1.1.11 | 2.1.8 | 2.2.2 ) for details on the release including a issues fixed and affected packages.

Docker Images

.NET Docker images have been updated for today’s release. The following repos have been updated.

microsoft/dotnet (includes the latest aspnetcore release)
microsoft/dotnet-samples
microsoft/aspnetcore (aspnetcore version 1.0 and 1.1)

Note: Look at the “Tags” view in each repository to see the updated Docker image tags.

Note: You must re-pull base images in order to get updates. The Docker client does not pull updates automatically.

Azure App Services deployment

Deployment of these updates Azure App Services has begun. We’ll keep this section updated as the regions go live. Deployment to all regions is expected to complete in a few days.

Lifecycle Information

The following lifecycle documents describe Microsoft support policies and should be consulted to ensure that you are using supported .NET Core versions.

• .NET Core Support Policy
• .NET Core Supported OS Lifecycle Policy
• .NET Core 2.0 has reached end-of-life

Updated: February 19, 2019

• The advisory is now resolved with no action needed from Microsoft Customers. The issue was not applicable to any valid or supported configuration. There is no consequence for .NET 4.8 Preview customers.  We strive to share timely information to protect our customer’s productivity, in this case, our finding was thankfully of no consequence for customers on supported configurations.

Updated: February 15, 2019

• A new advisory has been released today for issues customers have reported with .NET 4.8 Preview and this security update for Windows 10 update 1809 installed.

Updated: February 14, 2019

• Added the previously released previous release update information in quality and reliability for easier reference.

Yesterday, we released the February 2019 Security and Quality Rollup.

Security

CVE-2019-0613 – Remote Code Execution Vulnerability

This security update resolves a vulnerability in .NET Framework software if the software does not check the source markup of a file. An attacker who successfully exploits the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on by using administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts that have full user rights. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who have administrative user rights.

CVE-2019-0657 – Domain Spoofing Vulnerability

This security update resolves a vulnerability in certain .NET Framework APIs that parse URLs. An attacker who successfully exploits this vulnerability could use it to bypass security logic that’s intended to make sure that a user-provided URL belonged to a specific host name or a subdomain of that host name. This could be used to cause privileged communication to be made to an untrusted service as if it were a trusted service.

CVE-2019-0657

Quality and Reliability

This release contains the following previously released quality and reliability improvements, January 2019 Preview of Quality Rollup.

Getting the Update

The Security and Quality Rollup is available via Windows Update, Windows Server Update Services, Microsoft Update Catalog, and Docker.

Microsoft Update Catalog

You can get the update via the Microsoft Update Catalog. For Windows 10 1507, Windows 10 update 1607, Windows 10 update 1703, Windows 10 update 1709 and Windows update 1803, the .NET Framework updates are part of the Windows 10 Monthly Rollup.  For Windows 10 update 1809 the .NET Framework updates are part of the Cumulative Update for .NET Framework which is not part of the Windows 10 Monthly Rollup.

The following table is for Windows 10 and Windows Server 2016+ versions.

The following table is for earlier Windows and Windows Server versions.

Docker Images

We are updating the following .NET Framework Docker images for today’s release:

• microsoft/aspnet
• microsoft/dotnet-framework
• microsoft/dotnet-framework-samples

Note: Look at the “Tags” view in each repository to see the updated Docker image tags.

Note: Significant changes have been made with Docker images recently. Please look at .NET Docker Announcements for more information.

Previous Monthly Rollups

The last few .NET Framework Monthly updates are listed below for your convenience:

• January 22, 2018 Cumulative Update for Windows 10 version 1809 and Windows Server 2019
• January 2019 Preview of Quality Rollup
• January 2019 Security and Quality Rollup
• December 2018 Security and Quality Rollup
• November 2018 Preview of Cumulative Update for Windows 10 version 1809 and Windows Server 2019

Take the survey now! 

Final Update 2/19/19 @1:30 PM (PST): This advisory is now resolved with no action needed from Microsoft Customers. The issue was not applicable to any valid or supported configuration. There is no consequence for .NET 4.8 Preview customers.

We strive to share timely information to protect our customer’s productivity, in this case, our finding was thankfully of no consequence for customers on supported configurations.

Update 2/15/19 @3:35 PM (PST): As we continue our investigation, we are finding the issue to be restricted to a limited and isolated set of test-only systems that are using non-official versions of the .NET 4.8 Preview. As of 2/15/19 around 12:00 pm (PST) we further tightened our delivery mechanisms to ensure that the February .NET security updates are only deployed to their expected target systems.

The February 2019 Security and Quality Rollup for Windows 10 update 1809 was released earlier this week. We have received multiple customer reports of issues when a customer has installed .NET Framework 4.8 Preview then installed the February security update, 4483452. These reports are specific to only to the scenario when a customer has installed both .NET Framework 4.8 Preview and the February security update.

We are actively working on investigating and addressing this issue. If you installed the February 2019 security update and have not seen any negative behavior, we recommend that you leave your system as-is but closely monitor it and ensure that you apply upcoming .NET Framework updates.

We will continue to update this post as we have new information.

Guidance

We are working on guidance and will update this post and as we have new information.

Workaround

There are no known workarounds at this time.

Symptoms

After installing .NET Framework 4.8 Preview then the February 2019 security update, 4483452, Visual Studios will crash with this error message:

“Exception has been thrown by the target of an invocation.”

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.

Upgrade to .NET Core 2.1

The supported upgrade path for .NET Core 1.x applications is via .NET Core 2.1 or 2.2. Instructions for upgrading can be found in the following documents:

• Migrate to .NET Core 2.1
• Migrate to ASP.NET Core 2.1

Note: The migration documents are written for .NET Core 2.0 to 2.1 migration, but equally apply to .NET Core 1.x to 2.1 migration.

.NET Core 2.1 is a long-term support (LTS) release. We recommend that you make .NET Core 2.1 your new standard for .NET Core development, particularly for apps that are not updated often.

.NET Core 2.0 has already reached end-of-life, as of October 1, 2018. It is important to migrate applications to at least .NET Core 2.1.

Microsoft Support Policy

Microsoft has a published support policy for .NET Core. It includes policies for two release types: LTS and Current.

.NET Core 1.0, 1.1 and 2.1 are LTS releases. .NET Core 2.2 is a Current release.

• LTS releases are designed for long-term support. They included features and components that have been stabilized, requiring few updates over a longer support release lifetime. These releases are a good choice for hosting applications that you do not intend to update.
• Current releases include new features that may undergo future change based on feedback. These releases are a good choice for applications in active development, giving you access to the latest features and improvements. You need to upgrade to later .NET Core releases more often to stay in support.

Both types of releases receive critical fixes throughout their lifecycle, for security, reliability, or to add support for new operating system versions. You must stay up to date with the latest patches to qualify for support.

The .NET Core Supported OS Lifecycle Policy defines which Windows, macOS and Linux versions are supported for each .NET Core release.

Today, we released the February 2019 Preview of Quality Rollup.

Quality and Reliability

This release contains the following quality and reliability improvements.

CLR

• Addresses an issue in System.Threading.Timer where a single global queue that was protected by a single process-wide lock causing a issues with scalability where Timers are used frequently on multi-CPU machine.  The fix can be opted into with an AppContext switch below.  See instructions for enabling the switch.  [750048]
  • Switch name: Switch.System.Threading.UseNetCoreTimer
  • Switch value to enable: true
    Don’t rely on applying the setting programmatically – the switch value is read only once per AppDomain at the time when the System.Threading.Timer type is loaded.

SQL

• Addresses an issue that caused compatibility breaks seen in some System.Data.SqlClient usage scenarios. [721209]

WPF

• Improved the memory allocation and cleanup scheduling behavior of the weak-event pattern.   The fix can be opted into with an AppContext switch below.  See instructions for enabling the switch.  [676441]
  • Switch name: Switch.MS.Internal.EnableWeakEventMemoryImprovements
  • Switch name: Switch.MS.Internal.EnableCleanupSchedulingImprovements
  • Switch value to enable: true

Getting the Update

The Preview of Quality Rollup is available via Windows Update, Windows Server Update Services, and Microsoft Update Catalog.

Microsoft Update Catalog

You can get the update via the Microsoft Update Catalog. For Windows 10 update 1607, Windows 10 update 1703, Windows 10 update 1709 and Windows update 1803, the .NET Framework updates are part of the Windows 10 Monthly Rollup.

The following table is for Windows 10 and Windows Server 2016+ versions.

The following table is for earlier Windows and Windows Server versions.

Previous Monthly Rollups

The last few .NET Framework Monthly updates are listed below for your convenience:

• February 2019 Security and Quality Rollup
• January 22, 2018 Cumulative Update for Windows 10 version 1809 and Windows Server 2019
• January 2019 Preview of Quality Rollup
• January 2019 Security and Quality Rollup