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 Hanselman, Damian Edwards, Jon 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 live.asp.net where the meeting’s schedule is posted and hosted.

This week’s meeting is below:

Asp.Net Core is released!   Go to https://dot.net 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 https://www.microsoft.com/net  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 live.asp.net 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 live.asp.net 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 live.asp.net.   This SHA will match up with the SHA listed in the commits for the application on GitHub:

In 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:

Next, 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:

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:

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

With 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:  https://github.com/aspnet/live.asp.net/commit/b94a26ad42a7763caf54f70a79b0c83b192a72ef#diff-274660eb4b1b1d963a330b471e10f41c

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.