Notes from the ASP.NET Community Standup – March 22, 2016

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

This week’s meeting is below:

This week, Jon was not on the call to share the community links of the week but Scott and Damian jumped right in to discussing the week’s accomplishments.

Accomplishments

The BUILD conference is ‘eating the world’ according to Scott.  He is focused on preparing and Damian is working through preparations for ASP.NET Core RC2.  The goal with the ASP.NET Core team is not to complete it for a conference date, but to deliver a product when it is properly completed with a set of high quality features.

Damian is hearing comments from the community that folks are ‘losing confidence’.  Microsoft is very invested in this effort, with more than five teams working on the framework and platforms.  The team is patching the RC1 dnx and dnu tooling so that it will interoperate with the .NET CLI version of the world when it arrives in RC2.

Scott pushed on this, and they decided to depart from the typical standup format and pair-program with the current, most unstable ASP.NET Core build.

We learned how to enable the unstable DNX feed using an environment variable:

SET DNX_UNSTABLE_FEED=https://www.myget.org/F/aspnetcidev/api/v2

This environment variable is then picked up by the dnvm (dot net version manager) utility and displayed when dnvm is executed at the command-line:

dnvm output

Scott then proceeded to update dnx to the latest version from the unstable feed with the command:

dnvm upgrade -u

He updated the CoreCLR version of the dnx with the following command:

dnvm upgrade -u -r coreclr

The folks who are following along with the latest ASP.NET Core work go through this dnx update process daily and it is not expected that this is something that will need to be done by developers when the RTM version of ASP.NET Core is published.

Damian showed Scott how to get the current nightly build of the .NET CLI.  They opened a browser and navigated to:  http://github.com/dotnet/cli   In the readme document, there is a list of installers for different processor architectures and operating systems.  Scott grabbed the binaries for the Windows x64 version that matched his machine and extracted the zip file into:

%LOCALAPPDATA%\Microsoft\dotnet\cli

Next, Scott put the location of the CLI folder that was just populated on his user path.

Scott was then able to run the dotnet command-line tool by executing `dotnet`

In this state, Scott’s machine bridged the .NET CLI and dnx tools.  The design implemented utilizes dnx to get RC1 tooling working in Visual Studio with the .NET CLI.  The tooling in Visual Studio is constructed so that it will use the version of dnx that is configured with the default alias.

Scott created a new project by executing “dotnet new” at the command-line and was then able to open that as a project in Visual Studio 2015 by instructing it to open the project.json file inside of the new project folder.  Damian pointed out that Visual Studio will call the dnx and dnu commands that will execute and behave the same as the dotnet commands.

Unfortunately, the random continuous integration package versions that Scott grabbed were not functioning properly and Scott was unable to use those versions to run a simple ‘Hello-World’ application.

Damian explained the ideal workflow for new ASP.NET Core developers: a developers starts with a click on a download button at the ASP.NET Website and receive the dotnet executable.  They should then be able to run dotnet new to start a new application, dotnet run to compile and run that application and then dotnet publish to place the output of the app in a separate folder appropriate for publication.  Once delivered, users should be able to run dotnet <assemblyname> to run the application that was published.

Questions:

Question: Why are you ‘wasting time’ keeping dnx running instead of focusing on .NET CLI?

— The new dnx is a shim layer that will enable Visual Studio to work with the .NET CLI builds.  This will be kept up until the new Visual Studio tools are ready to support .NET CLI.

Question: Is there support in Azure Cloud Service for Web Roles using ASP.NET Core?

— Nothing new… You would need to get it running manually on the webrole by creating a webrole deployment project to bring in the entire set of .NET Core tooling.  Scott did something similar with Ruby in the past.

Question: Is NETStandard the proper casing for the TFM?

— Yes, the NET is a marketing reference to the .NET Framework and should be uppercase.

Question: System.Net.Mail is not available yet on .NET Core.  Should I wait or use another library?

— Good question, check in the dotnet/corefx repo for an issue about this.  Previously, there was a blog post shared during the standup from Eric Anderson about using Mailgun to send emails.

Thank you to everyone that tuned in to the live recording and asked questions.  The team is always looking forward to hearing for you.  Join us on March 29th at 22:45 UTC, 18:45 ET, 15:45PT or just check the timer at http://live.asp.net for exact time in your timezone as well as a reminder that you can add to your calendar.