Notes from the ASP.NET Community Standup – June 2, 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:
Scott Hanselman was unable to join us this week, but Scott Hunter joined us for some updates and to answer some questions that have been raised since the RC2 release. Since it has been a few weeks since our last video, Jon had a generous collection of community content to share:
Links of the Week
Mehul Harry announces the DevExtreme TagHelpers now support ASP.NET Core RC2.
Jonathan Mezach overviews the .NET Platform Standard and shows how to use “imports” to include libraries that don’t target a specific netstandard version.
Here’s an intersting e-commerce system by Thien Nguyen Le Quynh that’s based on ASP.NET Core targeting Windows and Linux using SQL Server and PostgreSQL.
Jerrie Pelser shows how to use environment variables and the Secret Manager tool to avoid checking user secrets in to source control.
Marcin Zabłocki shows how he got ASP.NET Core debugging working on Ubuntu 16.04.
David Pine shows how to upgrade tools and application code from ASP.NET Core RC1 to RC2.
Muhammad Rehan Saeed presents a nice comparison between Azure Active Directory and IdentityServer.
Tugberk Ugurlu describes the tooling changes he’s making as he updates his ASP.NET Core applications to RC2.
Here’s a deep dive into the ASP.NET Core CORS library, examinining implementation patterns and configuration.
Dave Paquette examines the recently added Distributed Cache Tag Helper, which allows you to store your ASP.NET Core cache outside of the ASP.NET Core host process.
Eric L. Anderson highlights some important differences in migrating from ASP.NET Core RC1 to RC2.
Pratap Lakshman announces MSTest Framework support for ASP.NET Core RC2.
Tony Sneed walks through how to use Entity Framework 6 in an ASP.NET Core application.
Julie Lerman documents the process of updating an ASP.NET Core / EF application to ASP.NET Core RC2.
Ben Cull overviews the basic EF Migration commands and provides a workaround to get migrations working for a Class Library project.
Jurgis Pasukonis walks through creating a new ASP.NET Core application on OS X, running it in Docker, and deploying to AWS container service.
Shayne Boyer shows how he called a WCF service from an ASP.NET Core application.
Simone Chiaretta shows how to set up debugging for .NET Core RC2 applications in Visual Studio Code.
Jon Smith shares some comprehensive templates for React applications in both ASP.NET Core and ASP.NET MVC 5.
Rick Strahl shows how to take advantage of strongly typed configuration settings in ASP.NET Core.
Sergio Sisternes walks through the process of deploying an ASP.NET Core application to Docker, along with some interesting “extra credit” steps once that’s running.
Khalid Abuhakmeh shares a fluent builder approach for conditional middleware configuration.
Hisham Bin Ateya shares a nice Bootstrap based language switcher tag helper.
Scott and Damian took some time to reflect on some of the comments we have heard regarding the recent announcements and discussions for .NET Core. They started with the post about ‘Making it easier to port to .NET Core‘.
They heard the confusion about the migration and portability capabilities discussed in this post. Scott says that the .NET Core team really wants to have a great experience building for mobile devices with Xamarin and UWP and also a great experience when building applications for the web or a server. Sometimes there are conflicting designs that need to be resolved, such as the larger framework available for the development of mobile applications and the ASP.NET Core framework attempting to deliver a smaller server-focused version of the framework. The direction discussed in that blog post is not an attempt to take away from the server framework’s goal.
Damian asked about the concerns some folks had about the use of mscorlib and if it means that the software constructed on GitHub is no longer useful. Scott indicated that the work done on GitHub to refactor and make smaller assemblies is still very valid, and they are discussing the best way to bring compatibility with mscorlib targeted assemblies to ASP.NET Core. There are details around how applications will reference mscorlib, the .NET Core assembly, or even a Xamarin assembly at compile time. Its very early in the planning process, and the team is sharing their initial thoughts. The key goal is that ASP.NET Core should get better compatibility with the .NET frameworks that the majority of the world is currently using.
Scott went on to explain a few compatibility goals that the .NET teams have:
- An existing Xamarin customer should be able to take their code to UWP projects. A UWP project should be able to take code and use it in a Xamarin project, and either of those codebases should be usable on a server. Unity should be similarly compatible with server, Xamarin, and UWP code.
- We want to make packages the delivery vehicle for .NET without having to make a bunch of compiled binaries in separate folder in the package. Package contents should get much simpler for maintainers and consumers. They should be simpler and very compatible across Unity, Xamarin, UWP, Desktop, and Server.
- Scott calls this ‘taking the development platform back’ and having the .NET team lead the direction of the framework. PCL was the smallest intersection of the capabilities of the various frameworks, and the .NET team wants to expand that definition to make it easier to re-use code. The example Scott references is that the UWP removed APIs from .NET because there were APIs in Windows that did the same thing. Scott wants to ensure that .NET developers can use these common APIs everywhere.
Damian went on to clarify the shared vision concept of the .NET frameworks. The shared capabilities are summarized in this graphic from Scott Hunter’s .NET Overview session at Build 2016:
The .NET Standard defines a common API surface for those shared features with a full implementation that is enabled for you when compiling for your specific target platform. There are things that could be brought back from mscorlib and NOT placed in .NET Standard, they could be placed only in those verticals appropriate for the target platform. This planning is still in the early stages, and the teams are working through these concepts.
Jon asked about timing: when are these changes going to occur, with a planned RTM in June, does this impact that? Damian clarified that this is a roadmap and a plan for features to add to .NET standard going forward. These plans should help to make .NET APIs common and available for polyglot developers who work on more than just server or just mobile. The APIs made available in .NET Core 1.0 RTM won’t change, they’ll grow and some will be contributed back to the .NET Standard. The plan has always been to add more APIs after 1.0 RTM, and this is the beginning of those discussions. Things like ADO.NET are in discussion as an API that could be made available after RTM.
The planned release in June will have the RTM of the ASP.NET Core framework with a preview 2 version of the tools, debuggers, and templates that support it. As more details emerge around future plans, the team will blog about it.
Scott indicated that sometimes the context of the standup videos, including the On .NET standup, gets lost. The team plans to blog more about their status, and writeups like this one will have more clarity about what the team is working on. Scott gave an example of the MSBuild changes that were discussed – the team finally got into a room and started discussing the direction last week. Something discussed as a direction doesn’t mean that its fully designed and engineers are writing code. Damian described that their process starts with a planned goal that has a number of directions for the team and those directions need to be planned out before engineers can write code to meet the original goals.
Scott indicated that the .NET vision and the goals being described in the open are just that: ideas. As part of the open approach from Microsoft, we want to discuss concepts as the development platform evolves.
With regards to the project.json to MSBuild change, the team ran into challenges in building a project.json model that supported MSBuild based libraries and capabilities while working with tools that only supported MSBuild. The team couldn’t justify spending two more years to build compatibility with every project type when they could go back to the incumbent and enhance it with the capabilities that we learnd from two years of development on project.json. As we realized that we wouldn’t deliver much more value in adding that compatibility compared to switching back to an MSBuild based model. We don’t plan to give up those features of project.json, and they will appear in MSBuild and csproj in the future.
Damian went on the clarify that the team wants to spend their time innovating framework features in the standard library and shared components so that all .NET developers can benefit. In this way, the vertical frameworks can focus on the innovations specific to their vertical.
If you have questions about these discussions or topics, please ask your questions below and someone from the team will answer you. This is a collaborative effort, and it is important to us that you get the information you need about these discussions. This also enables everyone to see and interact with the documentation about these changes.
Scott wants to ensure that the context of the major announcements happen on this blog and allow the standup videos to focus on discussing those features specific to the vertical. Scott is excited that the ASP.NET team is able to start talking about and working on web features.
A question came up about the difference between the RTM of the ASP.NET Core framework and the tooling being in a preview release. The runtime and framework has been in a real solid place, with a number of customers already running in production with the RC1 release and waiting for the RTM of ASP.NET Core. We were holding back the framework and runtime for the tooling, even though ASP.NET Core and .NET Core have been through their stress tests and security checks. We don’t want to keep you waiting for the resolution of some of these tooling changes that you may not need because the current ASP.NET Core meets your needs. If you need the interoperability of the planned MSBuild tool, you will need to wait for that to be completed.
The team is committed to eliminating any kind of migration effort between RTM and the VS15 tooling release. They plan to make opening a project is VS15 as easy as opening your VS2015 project and it will be converted to the new MSBuild model. The release of framework as an RTM with tooling still in preview is a bit weird, but not without precedent as the UWP tools went through a similar release schedule in 2015. The ASP.NET team knows that the tools are going to change, but the framework is not planned to change. They want to be able to enhance the tools without holding customers back any longer.
Scott also responded to some comments about “the .NET team got involved with ASP.NET Core and now things are in a strange place”. The ASP.NET and .NET efforts are being worked on by a single team that owns both products. Its one team, and in fact the folks that initiated the discussion to use MSBuild instead of project.json were responsible for ASP.NET. The team cares about all of the platforms: Unity, Desktop, Server, and Xamarin and wants everyone to succeed.
Tune in to dotNetConf the week of June 7-June 9 and we’ll be back the week after with another video.