Notes from the ASP.NET Community Standup – April 19, 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 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:
This week’s standup featured Scott and Damian, with Jon on assignment so our boss Scott Hunter sat in with the guys while they were at the DevIntersection conference in Orlando, Florida this week. Damian took a minute at the beginning to explain to Scott how sunglasses work and then the three set forth on the topic for this week’s standup, which is all about the accomplishments of the dev team this week.
Scott pointed out that regularly featured blogger here on the standup, Shayne Boyer was in the room with them also… and pointed out that Shayne has a fine looking beard. (Transcriptionist note: I think this may be in response to the comment from April 5th when Scott relayed that attendees at Build commented that he had a “weak” beard. If Scott’s isn’t strong, then Shayne’s is Magnus Ver Magnusson)
Damian gave an all-day workshop at DevIntersection, and had the FIRST internal RC2 tooling build since November. This is an important milestone, as the team now has completed tooling and framework builds that can be tested and cleaned for quality. Scott Hunter and Damian had each found some issues with this build and are not yet making this version of the tools public. Damian and Scott Hunter discussed the possible timeframes to complete the quality work on this RC2 version. The agreed projected release of this version could be in the next 4-6 weeks.
Scott Hanselman described the difference between the runtime framework and this tooling release. The tooling is the part that provides the UI and project models and templates in Visual Studio for .NET Core and the other web tools. This also means that the installer and continuous integration process for ASP.NET Core and .NET Core are completely configured and can deliver new builds for testing on a regular basis.
This is a raw build with updates needed to polish the UI. For example, the new ‘New Project’ window now breaks out Web and .NET Core options:
A little confusing, but needs some polish before we ship it.
The .NET Core option shows all of the project types that can be built on the .NET Core framework. This means that the ASP.NET Core on .NET Core project type is in this section as well.
These screens lead to a simpler “One ASP.NET template” dialog that is in process of being cleaned up:
Scott had a package downgrade issue when starting a new project. Closing and reopening the project installed the latest version of the package, and this was an artifact of an older package referencing an older version of a package. As part of diagnosing this, Damian showed that the current ‘New Project’ experience installs packages differently from re-opening a project. Creating a new project grabs a copy of the local packages that were deployed with Visual Studio, optimizing against remote connections to NuGet.org to create a new project.
Scott Hunter showed and started talking about the new static void Main method that is present in the Program.cs file in a new ASP.NET Core RC2 project. That code is below:
This shows that the entry point of the web application is no longer some magic entry point, this is where .NET applications start – in static void main. The web application is compiled to a DLL and the dotnet.exe command-line-interface knows how to locate this method and start the application. This structure allows the application to be portable, as the dotnet.exe is native to the operating system and knows how to load the DLL on its platform. The application can be made standalone, but we need to capture information about the target platform that would be compiled to.
The UseKestrel statement is the webserver for your ASP.NET Core application and it runs in your process. By adding the UseIISIntegration statement, the information from the AspNetCoreModule hosting the process in IIS will pass all of the IIS context information into the Kestrel webserver. This statement runs a noop when executing on a non-Windows platform.
In project.json, there is a new child element in the “dotnet-razor-tooling” that indicates “type: build” to show that this dependency is only needed during build-time and now during run-time. The “type: platform” indicates that the content of that reference should not be copied during a publish operation and should be available with the runtime on a target environment. If the “type: platform” element is removed, the content of the package is copied into the publish target.
Scott pointed out the frameworks->imports element that calls out a number of target-framework-monikers from other platforms like “dotnet5.6”, “dnxcore50”, and “portable-net45+win8”. These are nested on a framework named “netcoreapp1.0”. As that target framework does not yet exist, this imports statement is a lie that you can tell the build process to indicate that the build process can try using these frameworks in packages in the order listed.
The netcoreapp1.0 framework depends on netstandard1.5 which derives from netstandard1.4 and so on back to netstandard1.1 depends on netstandard1.0 which depends on nothing. The team also pointed out that at some point in the future they want to greatly simplify the default project.json so that a basic ASP.NET Core project doesn’t require all of the ceremony of a large project.json file. That’s still to be discussed and planned, and not in the plans for the near future.
Scott Hunter pointed out that this is a journey, and many cool features are coming in the future after the team delivers the first version of the product.
Further down the project.json file, Scott called out the “content” element. Damian explained that this is the collection of folders and files that need to be included in the published output. In a future release, this element will be renamed to publish_include (transcription note: its not clear what the final spelling will be from this video) The scripts element at the end is the same collection of events that you can connect scripts to in order to execute during the publish processes.
Scott asked about an update to the dnvm list command. Damian indicated that its not available yet for RC2, but a spec for a “dotnet runtimes” command is being talked about to deliver this feature in the future. The team wants it to look in the local folder, the user profile folder, and the machine-wide list of runtimes.
Scott Hanselman indicated that the discussions that you saw in this video are a typical day at the office between the teammates. With that, the guys signed off and they’ll be back next week to answer your questions.
Light
Dark
0 comments