Notes from the ASP.NET Community Standup – June 28th 2016

Jeffrey Fritz

This is the next in a series of blog posts that will cover the topics discussed in the ASP.NET Community Standup. The community standup is a short video-based discussion with some of the leaders of the ASP.NET development teams covering the accomplishments of the team on the new ASP.NET Core framework over the previous week. Within 30 minutes, Scott HanselmanDamian EdwardsJon Galloway and an occasional guest or two discuss new features and ask for feedback on important decisions being made by the ASP.NET development teams.

Each week the standup is hosted live on Google Hangouts and the team publishes the recorded video of their discussion to YouTube for later reference. The guys answer your questions LIVE and unfiltered. This is your chance to ask about the why and what of ASP.NET! Join them each Tuesday on where the meeting’s schedule is posted and hosted.

This week’s meeting is below:


Asp.Net Core is released!   Go to and get it now!  Everyone’s going on vacation because its DONE!   No.. Not really, the team is at it planning and getting ready for the next features in the web framework.

The surprise inclusion in this release is a browser-based REPL (Read-Eval-Print-Loop) for .NET at  From here, there’s a great set of tutorials and in-browser development experience for .NET.  We’re jazzed about this new way to present and teach .NET concepts.  You can now get started learning .NET without installing Visual Studio or and SDKs.  Or even get started learning .NET WHILE you wait for Visual Studio to install.

This week, instead of answering piles of questions about 1.0 RTM, Damian shared a live upgrade experience of the website that hosts the Community Standup.  It was a painless process and we’ll review some of the highlights of the changes Damian applied to the application.

Damian showed us a block of comments that he added to the bottom of the page to show some information about the environment that the application is running in.


Scott made a point that running small web sites in the cloud, like Azure Web Applications, don’t need x64 processing and can run very nicely in smaller x86 processes.

Damian showed us the staging environment for the site and how he can detect whether the Azure deployment (code named kudu) deployed his application and what the Git SHA hash for that deployment is.  You can see this code on lines 37-82 of the DeploymentEnvironment class in   This SHA will match up with the SHA listed in the commits for the application on GitHub:

GitHub commit SHA hashIn order to protect the Dev version of the source that Damian had last modified, he created a new branch in his local source repository by executing the command:

git checkout -b rtm

This creates a new branch using a technique called “feature branches” where new features or experiments on your source code is performed in a local space where it is isolated from current working code.

Damian then walked through the installed for the .NET Tooling Preview 2, as he has not applied the latest patch to the machine he was demonstrating from.  To push his code to use the Preview 2 version of the dotnet command-line tool, Damian updated the global.json file to point to the new version of the tool:

Global.JSON updates from RC2 to RTMNext, he updated project.json to reference the 1.0.0 version of his packages and the tools that were updated get pointed to a Preview 2 version:

Project.JSON updates from RC2 to RTM

There was a slight name change on one of the classes used for Authentication, the OpenIdConnectResponseTypes was renamed to drop the S on the end:

Auth UpdateFinally, Damian applied an update for the system reflection information that we showed earlier as an output to his page:

Layout Change to Support new System Environment APIsWith that change, Damian was able to run the application using the ASP.NET Core RTM.  A complete diff of the changes Damian made can be found on GitHub at:

Damian and Scott went through the exercise of deploying the application to a Azure Web App staging slot.  The deployment took some time due to retrieving and loading all of the dependencies from NuGet, npm, and a non-optimized compilation process.

Looking Forward

Next week, we’ll talk about our early thoughts for the roadmap including SignalR.  There is a SignalR 2.2.1 servicing release for ASP.NET and the team will be starting on “SignalR Core”.  Scott pointed out new updates to Visual Studio Code that automatically adds the C# extension and debugger if you don’t have that installed and are working with C# files.  Next time, Scott suggested that the team reviews how to install daily builds of the SDK if you’d like to run with the absolute latest version of the tools.


Discussion is closed.

Feedback usabilla icon