For this first day at Build, I attended several sessions revolving around .NET Core and the Cognitive Services running on Azure.

Three Runtimes, one standard… .NET Standard: All in Visual Studio 2017
Scott Hanselman, Scott Hunter

This session was more about a global overview of all the major frameworks available in Visual Studio than an in-depth talk on .NET Standard.

We were reminded that Microsoft recently put reference resources for Architecture in .NET on

To start, the Scotts explained us what are the available .NET Platforms (.NET FX, .NET Core, Mono) and how .NET Standard helps for easier code sharing across platforms.
One sentence that I found particularly relevant for describing .NET Standard is « .NET Standard is a contract that .NET Platforms must comply to »

Nothing was announced for the availability of .NET Standard 2.0 (that is currently in preview) but as said during the Keynote, .NET Core 2.0 and ASP.NET Core 2.0 are available today as preview also.

Microsoft estimates that currently 70% of the NuGet Packages are .NET Standard 2.0 compliant due to the large new API surface covered by this new version of .NET Standard.
Those packages don’t need to be recompiled to be used on any platforms!
The other 30% are mostly framework-specific like WPF libs or ASP.NET libs, so they won’t ever be .NET Standard compliant.

When VS2017 was first introduced, it came with a Live Unit Testing feature that were only usable with .NET FX projects.
It was announced that the upcoming VS2017 Update 3 (currently in preview) will add this feature to .NET Core projects!
This update will also come with support for C# 7.1.

After that we were given a brief tour of Visual Studio for Mac and how it come closer and closer to the classic Visual Studio: same tooling, same project templates, and so on.

A conference named « .NET Conf » will take place in September 2017 for 3 days and will cover any kind of subject about .NET.

Introducing ASP.NET Core 2.0
Daniel Roth, Maria Naggaga Nakanwagi, Scott Hanselman

This session was about the differences and new features introduced by ASP.NET Core 2.0 preview compared to ASP.NET Core 1.1.
I recommend that you watch the replay as there was a lot of technical goodness that I can’t really transcribe here.

If you want to develop ASP.NET Core 2.0 apps, you will need VS2017.3 currently in preview.
Microsoft says that ASP.NET Core 2.0 is 25% faster than 1.1.

The first thing that we saw was the dotnet cli and how easy and quick it is to bootstrap an ASP.NET Core app without ever going into Visual Studio.
It can be resumed by those two commands : dotnet new, dotnet run.
The first one creates a sample ASP.NET Core project and the second one compiles and runs it.

« dotnet new » will bootstrap an ASP.NET Core project based on the version of the dotnet tooling.
This version can be set by a « global.json » file placed either in your user folder (to globally define the dotnet tooling version) or per folder.
That way you can have dotnet 1.1 running inside a folder, and dotnet 2.0 running inside another one.

One great thing that was announced is Microsoft resolved several shortcomings of the new « all NuGet packages » strategy.
.NET Core introduced a lot of small packages especially for ASP.NET Core.
For example, you had one packages for servicing Static Files, one for MVC, one for Configuration, and so on.
This resulted in a lot of packages to download on our machines and significantly large packages to publish in production (every dlls that were used were uploaded along our web app)

Those shortcomings were resolved by a single new NuGet package named « Microsoft.AspNetCore.All », this package includes all the small packages used almost all the time like MVC.
And to avoid downloading gigabytes of packages, this « Microsoft.AspNetCore.All » is already included in the dotnet tooling version 2.0.
That means that when publishing our web app, we only need to deploy our own dll, resulting in way smaller package.

ASP.NET Core 2.0 introduces a new startup pattern.
DI configuration is not done in the Startup.cs file anymore, but in the Program.cs file.

ASP.NET Core 2.0 also introduces a new version of Web Pages.
We can now create Razor pages (cshtml) that don’t need to be backed by a controller.
For that, just create a folder named « Pages » and create cshtml files inside it.

Those cshtml files need to have the « @page » tag defined inside them to be treated as Pages.

Then if you call the url « http://localhost/mypage », it will resolve to the /Pages/mypage.cshtml. No need for a controller that would only return a view.

More complex scenario are enabled by defining inlined « PageModel » which is a class that represents the « @page » tag.
You can then define behaviors for GET,PUT,POST,etc. verbs and also read parameters passed by url.
Like for this url « http://localhost/mypage/5 », you can define the following @page « {id: int} ».
The PageModel instance of the page will then have access to the id passed by the url.

It is no more necessary to add the Application Insights package when creating ASP.NET Core apps.
When deploying to Azure, Azure will recognize the type of application and will propose to automatically inject Application Insights.
This also enables the new « Snap points » feature for debugging live production apps directly from Visual Studio.

Using Microsoft Cognitive Services to bring the power of speech recognition to your apps
Ivo Santos, Khuram Shahid, Panos Periorellis

This session talked about the speech recognition services available in Cognitive Services, especially TTS/STT, Custom Speech Service and Speaker Recognition.

Speech API is rather classic and enables Text-to-Speech and Speech-to-Text scenario.
Using it is simple:

Custom Speech Services is interesting as it allows to finely customized speech recognition based on our business requirements.
An example that was given is a kiosk in an airport where customers would ask for the next flight to a city in a noisy environment (announcements, chattering, etc)
Custom Speech Services offers a portal where we can train the speech recognition AI with sample acoustic data, and we can also upload vocabularies applied to our business.

Using Custom Speech Services in code is exactly the same as Speech API, you just need to specify an url given by the portal that represent your trained AI.

Lastly we were demoed the new Speaker Recognition API that recognizes who speak.
This is particularly promising as it is an on-the-fly trained AI which differentiates talking people at first, and then is capable of recognizing the same person throughout the conversation.
The demo was a bot running a trivia game, and which was attributing points to the person answering just by recognizing who talked. But it didn’t really worked.