Build Leaner, Faster Web Applications with ASP.NET

Editor's Notes

1. Description. ASP.NET 5 is a lean and composable framework for building web and cloud applications. ASP.NET 5 is fully open source and available on GitHub. In this session we’ll put it all into context, answering questions such as what does that ASP.NET 5 mean for compatibility? What powerful new cloud scenarios does ASP.NET 5 enable? Etc. We’ll cover it all both inside and outside of Visual Studio, including support for Mac and Linux.
2. [Start with Customer evidence] Running on 4/5 machines (efficient) We’re working on having ASP.NET 5 Customer evidence for connect, we’ll update this deck when done. You can contact davidsb after Nov 23 for an update. https://customers.microsoft.com/Pages/CustomerStory.aspx?recid=14667 Case Study: https://customers.microsoft.com/Pages/Download.aspx?id=14668 [Additional customer stories] http://www.asp.net/get-started
3. Key message: There is certain fragmentation that we’ve to tackle, and be more systematic about how we focus on specific workloads Transition: Today, we can talk about just 2 different versions When we originally shipped the .NET Framework in 2002 there was only a single framework. Shortly after, we released the .NET Compact Framework which was a subset of the .NET Framework that fit within the footprint of smaller devices, specifically the old Windows Mobile. The compact framework was a separate code base from the .NET Framework. It included the entire vertical: a runtime, a framework, and an application model on top. Since then, we’ve repeated this sub-setting exercise many times: Silverlight, Windows Phone and most recently for Windows Store. This yields to fragmentation because the .NET Platform isn’t a single entity but a set of platforms, owned by different teams, and maintained independently. Of course, there is nothing wrong with offering specialized features in order to cater to a particular need. But it becomes a problem if there is no systematic approach and specialization happens at every layer with little to no regards for corresponding layers in other verticals. The outcome is a set of platforms that only share APIs by the fact that they started off from a common code base. Over time this causes more divergence unless explicit (and expensive) measures are taken to converge APIs. What is the problem with fragmentation? If you only target a single vertical then there really isn’t any problem. You’re provided with an API set that is optimized for your vertical. The problem arises as soon as you want to target the horizontal, that is multiple verticals. Now you have to reason about the availability of APIs and come up with a way to produce assets that work across the verticals you want to target. Today it’s extremely common to have applications that span devices: there is virtually always a back end that runs on the web server, there is often an administrative front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices. Thus, it’s critical to support developers in building components that can span all the .NET verticals.
4. Key message: Differentiate the purpose and scenarios between .NET Framework and .NET Core. They Key point on .NET Core is that it’s self-contained and specialized on specific workloads. Make sure that we make the point that BOTH are valid. There is no decrease in investment on the .NET Framework side. Transition. There is a common shared layer to these 2 pieces
5. Key Message: Compilers, certain runtime components, libraries…. Are shared across and any improvement on these will impact on both frameworks, for instance ‘Roslyn’ Transition: With these pieces we enable/serve different application models
6. Key messages: Briefly comment on these, YES Windows Forms is there, as well as Web forms, we’ll talk more about it later, and YES ASP.NET Core works both in .NET Framework 4.6 and .NET Core Transition: We’re going to focus on the ASP.NET pieces
7. Transition: Let’s talk about the fundamental differences between these 2 options
8. An alternative visualization, more focused on the relationship between ASP.NET versions and .NET versions
9. Reference– Damian Edwards on NDC: https://vimeo.com/131191236 Column in the middle represents the stack, an application stack that we’re used to do. Left side represents what asp.net has been until recently, and on the right hand we have at the bottom, Windows:Linux and OS X. This is one of the reasons that determines that we have so many differences Highlights Operating system [Traditional] [New] Runtime loader. [Traditional] Something that loads my runtime. On Windows there is a flag, that boots the CLR and then runs your application, a little bit different on web applications we’ve the native component WebEngine4 that loads the CLR . [New] Runtime [New] Dotnetcore CLR helps us satisfy the cross plat need… and we also have mono, not on this slide, but available Platform libraries [Traditional] BCL [New] still have that if we run in .net crl, if we run .net core, then we use packages. Nuget packages . Application host [Traditional] [New] DNX appears in multiple layers, it has different components Web Server [Traditional] [New] http.sys (selfhost), Kestrel is based on libuv (same abstraction layer than node.js). And btw you can use kestrel on windows Application Frameworks [Traditional] [New] Nuget is an essential part, we even ship the runtime on nuget Libraries [Traditional] [New] Application [Traditional] [New] And most of the new things are open source. Transition. It’s also slightly different how the project is structure, let’s see the key differences
10. Goal of the demo – Create a new ASP.NET 5 project on Visual Studio 2015 and walk the audience by the key differences at the project level + some nugget context Check https://channel9.msdn.com/events/Ignite/2015/BRK3714 for context As well as a new runtime, ASP.NET 5 projects get a new project system. Instead of using Visual Studio’s usual .csproj or .vbproj files, ASP.NET 5 projects put everything in various JSON files. This is partly because Visual Studio is not technically required. But it also offers some benefits—it’s easier to control some aspects of your project because Visual Studio offers autocompletion for the various JSON files, making them much easier to edit directly than the old-style project files. (You can still do most things in Solution Explorer if you want though.) (UWP app projects do the same, incidentally, although you do need Visual Studio to write those.) One notable improvement that comes from the new project system is its new compilation model (which relies on the new ‘Rosyln’ C# and VB.NET compilers that ship with Visual Studio 2015). It makes it unnecessary to fully compile your project each time you want to change some code. You can just save it, and then see the effect of that immediately by refreshing the browser. You no longer have to wait 10 seconds or more for the code to compile first. ASP.NET 5 projects make a clear distinction between the content that is to be deployed to your site, and all other files. (For example, important though your C# or VB.NET source files are to the operation of your site, you don’t want users to be able to download your source over HTTP.) This is increasingly important with modern web development now that a lot of the artifacts that make it into the server such as CSS and JavaScript are processed in some way. For example, you could use languages such as SASS and LESS which are converted into CSS to be consumed by the browser, and it’s that CSS output that needs to go onto the web server, not the SASS or LESS source. Likewise, you’ll often want to minify JavaScript files before deploying them. Before ASP.NET 5, there wasn’t a great way to deal with these issues, but now the project structure is set up to support it directly. Nuget In an ASP.NET project, NuGet is now the main way to refer to external libraries. Although you can add a reference directly to a DLL from an ASP.NET 5 project, this only works when you’re building against the full .NET Framework – DLLs added this way will be unavailable if you build for .NET Core. Likewise, you can add references to framework components in the conventional way, but again, you cannot use DLLs this way when targeting .NET Core. But using NuGet (for either.NET Framework class library types or other libraries) works for both .NET Core and full .NET. This means you are likely to depend on a lot more packages than you would have done in the past. Fortunately, ASP.NET 5 introduces a change in how NuGet packages are handled that helps a great deal here: indirect references are handled automatically. For example, if you use a package that depends on a particular framework package (e.g. System.IO) you do not need to add a reference to that framework package explicitly—Visual Studio will infer the dependency automatically. This is a big improvement on how NuGet has worked in the past—in general, any project that depends on some package also needed to add dependencies to anything that package depended on. And while the NuGet dialogs would automatically add those for you, keeping them up to date could become problematic over time. Now, since your dependency list only contains the components on which your project depends directly, updating is much simpler. You can manage dependencies through the NuGet package manager, which you reach by right-clicking on the References node as has always been the case (although the package manager now looks substantially different.) Alternatively, you can edit the project.json file manually. Visual Studio will provide IntelliSense if you do that. Transition. ASP.NET 5 is just one of the available options on the .NET stack for web development
11. Option 1 – ASP.NET 4.6 + .NET Framework 4.6. There are a ton of websites built on top of the full .NET Framework and it’s a perfectly valid solution, either you choose the productivity of webforms or you prefer to work with MVC for a more granular option Option 2 – Create ASP.NET Core sites and services and run them on top of the full .NET framework, a slightly different application model that you can choose, but leveraging (if you want) all the BCL classes. Option 3 – Cloud-optimized option. Due to the ability of configuring the pipeline and the different modules of both the application platform and the underlying .NET Core you can optimize for performance and benefit from the side-by-side running benefits. Transition. Different options that you can choose from to develop the so called modern web applications Read: https://weblogs.asp.net/scottgu/introducing-asp-net-5 Transition: We’re working on options and investing on enabling the platforms and tools for modern development web needs
12. … and how easy or difficult is for a developer, to ideate, develop, design, deploy, debug… web applications. [References]Lap Around VS2015 as Web IDE - https://channel9.msdn.com/Shows/Web+Camps+TV/Modern-Web-Development-Tools-in-Visual-Studio-2015-with-Mads-Kristensen Updates for ASP.NET 4.6 Blog post - http://blogs.msdn.com/b/webdev/archive/2015/04/30/updates-for-asp-net-4-6-web-forms-mvc-5-web-api-2.aspx Web Forms 4.6 - https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/812 Info about HTTP/2 - http://http2.github.io/
13. … and how easy or difficult is for a developer, to ideate, develop, design, deploy, debug… web applications. [References]Lap Around VS2015 as Web IDE - https://channel9.msdn.com/Shows/Web+Camps+TV/Modern-Web-Development-Tools-in-Visual-Studio-2015-with-Mads-Kristensen Updates for ASP.NET 4.6 Blog post - http://blogs.msdn.com/b/webdev/archive/2015/04/30/updates-for-asp-net-4-6-web-forms-mvc-5-web-api-2.aspx Web Forms 4.6 - https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/812 Info about HTTP/2 - http://http2.github.io/
14. Watch https://channel9.msdn.com/Events/dotnetConf/2015/Introduction-to-ASPNET5 0:25 Transition: When we talk about speed, about being fast, we should also take into consideration the developer productivity
15. Tour around the repo, show collaborations, how to use gitter
16. Techempower
17. [References]Updates for ASP.NET 4.6 Blog post - http://blogs.msdn.com/b/webdev/archive/2015/04/30/updates-for-asp-net-4-6-web-forms-mvc-5-web-api-2.aspx Web Forms 4.6 - https://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/812 Info about HTTP/2 - http://http2.github.io/
18. [References]Docker - https://channel9.msdn.com/Series/Docker-for-NET-Developers/Docker-Overview-for-NET-Developers Diagnostics Run/Debug in Cloud Tracing/Logging without re-deploy Open Source https://github.com/aspnet Cross-Platform Entity Framework Entity Framework 6.x Evolution of current EF Runs on .NET Framework 4.6 Entity Framework 7 LINQ and EF skills re-use, easy to move most existing apps Cloud optimized (small memory footprint and high throughput) Device optimized (lightweight, works with SQLite) Supports relational and non-relational stores Runs on .NET Core 5 and .NET Framework 4.6 Cross-platform ready (based on .NET Core 5) Design for disconnected/web scenarios Both versions are OPEN SOURCE! Entity Framework narrative As with ASP.NET 5, the rewriting of Entity Framework 7 hasn’t meant that it is unrecognizable: many core concepts remain in place. For example, there is still a class called DbContext that is your main point of entry to your data source, and collections of entities are still represented by a class called DbSet. Any investment in earlier versions of the Entity Framework remains valuable—developers will be able to apply their existing knowledge to this new version. Some features have been removed. In some cases, these are areas that had already been superseded, and which only remained in v6.1 for backwards compatibility reasons. For example, the old ObjectContext class was long ago replaced by DbContext. Since EF7 does not provide full backwards compatibility, this hangover from very early versions can finally be removed. Also, certain features which are not widely used (either because they proved unpopular, or because better new alternatives exist) have been removed. For example, some complex type mappings which were rarely used have gone. And the ‘multiple entity sets per type’ (MEST) feature’s capabilities are now better supported through inheritance, so that has gone too. There are also some features which have disappeared, but which are expected to return in later releases. A full rewrite required substantial effort, and there wasn’t time to get everything from previous versions into this release. The most notable absence is Lazy Loading, a feature that the Entity Framework team plan to put back in the future. This new version also adds some new functionality. For example, it now supports some non-relational data sources such as Azure Table Storage. And there is new functionality for traditional relational storage too, such as the ability to perform batched updates, or for a model to specify unique constraints besides keys. Also, in keeping with the lightweight spirit of .NET Core, the framework has been refactored into multiple subcomponents, making it possible to use only those parts you actually want, rather than having an all-or-nothing heavyweight framework.
19. http://www.hanselman.com/blog/PublishingAnASPNET5AppToDockerOnLinuxWithVisualStudio.aspx
20. Entity Framework Entity Framework 6.x Evolution of current EF Runs on .NET Framework 4.6 Entity Framework 7 LINQ and EF skills re-use, easy to move most existing apps Cloud optimized (small memory footprint and high throughput) Device optimized (lightweight, works with SQLite) Supports relational and non-relational stores Runs on .NET Core 5 and .NET Framework 4.6 Cross-platform ready (based on .NET Core 5) Design for disconnected/web scenarios Both versions are OPEN SOURCE! Entity Framework narrative As with ASP.NET 5, the rewriting of Entity Framework 7 hasn’t meant that it is unrecognizable: many core concepts remain in place. For example, there is still a class called DbContext that is your main point of entry to your data source, and collections of entities are still represented by a class called DbSet. Any investment in earlier versions of the Entity Framework remains valuable—developers will be able to apply their existing knowledge to this new version. Some features have been removed. In some cases, these are areas that had already been superseded, and which only remained in v6.1 for backwards compatibility reasons. For example, the old ObjectContext class was long ago replaced by DbContext. Since EF7 does not provide full backwards compatibility, this hangover from very early versions can finally be removed. Also, certain features which are not widely used (either because they proved unpopular, or because better new alternatives exist) have been removed. For example, some complex type mappings which were rarely used have gone. And the ‘multiple entity sets per type’ (MEST) feature’s capabilities are now better supported through inheritance, so that has gone too. There are also some features which have disappeared, but which are expected to return in later releases. A full rewrite required substantial effort, and there wasn’t time to get everything from previous versions into this release. The most notable absence is Lazy Loading, a feature that the Entity Framework team plan to put back in the future. This new version also adds some new functionality. For example, it now supports some non-relational data sources such as Azure Table Storage. And there is new functionality for traditional relational storage too, such as the ability to perform batched updates, or for a model to specify unique constraints besides keys. Also, in keeping with the lightweight spirit of .NET Core, the framework has been refactored into multiple subcomponents, making it possible to use only those parts you actually want, rather than having an all-or-nothing heavyweight framework. SIGNALR NARRATIVE SignalR is another important framework to get an update to support .NET Core. In case you’re not familiar with it, SignalR is a framework for providing push notifications. It makes it possible for the server to send messages to web or mobile clients. This is a tricky problem to solve, because the basic architecture of the web has clients deciding when everything happens. HTTP is designed to have servers respond to client-originated requests. (And the ubiquity of firewalls essentially rules out the possibility of clients hosting their own local HTTP servers in order to support communication in the other direction.) This does not work especially well for applications that need to update the UI in response to live events. For example, if you want to build a chat application, client-side code has no way of knowing when other users in the system have typed in new messages. Or consider an application that needs to show real time alerts—again, the client has no way of knowing when it should make a request, because it has no way of knowing when the underlying event that should trigger an alert has actually happened. Modern web browsers support the recently-introduced Web Sockets standard, which can solve these problems. However, this is by no means ubiquitous (and even where browsers support it, there may be IT infrastructure issues making it difficult to support), so there are a few well established tricks that abuse HTTP in creative ways to enable server-triggered operations. SignalR provides a straightforward API that handles all of this for you. It will work out whether web sockets are available, and use them if possible, falling back to the standard hacks where required, but you don’t need to worry about this because you can use the same API in either case. It also supports a range of scales. It provides a relatively simple implementation that can run in your web server by default, but if you need to scale out your web farm either to support large numbers of concurrent users, or for availability reasons, this simple implementation is unsuitable. So SignalR is also able to work on top of Azure’s Service Bus to support multiple web servers. That requires a bit more work to set up, but the API for using it remains the same. So by using SignalR, you get the option to scale out if you need it, without being forced into setting up something complex when you have more modest requirements. All of this was true for SignalR 2, which has been available for some time on ASP.NET 4. But that wouldn’t run on .NET Core. Version 3 fixes that. Unlike ASP.NET and Entity Framework, this new version doesn’t make substantial changes. This is just a port of v2 that is able to run on .NET Core. So if you have been using SignalR V2, V3 will look more or less identical.
21. Option 1 – ASP.NET 4.6 + .NET Framework 4.6. There are a ton of websites built on top of the full .NET Framework and it’s a perfectly valid solution, either you choose the productivity of webforms or you prefer to work with MVC for a more granular option Option 2 – Create ASP.NET 5 sites and services and run them on top of the full .NET framework, a slightly different application model that you can choose, but leveraging (if you want) all the BCL classes. Option 3 – Cloud-optimized option. Due to the ability of configuring the pipeline and the different modules of both the application platform and the underlying .NET Core you can optimize for performance and benefit from the side-by-side running benefits. Transition. Different options that you can choose from to develop the so called modern web applications Read: https://weblogs.asp.net/scottgu/introducing-asp-net-5 Transition: We’re working on options and investing on enabling the platforms and tools for modern development web needs
22. Introduction to ASP.NET 5 MVA Course https://www.microsoftvirtualacademy.com/en-us/training-courses/introduction-to-aspnet-5-13786?l=PvSZtxoXB_5101937557
23. Introduction to ASP.NET 5 MVA Course https://www.microsoftvirtualacademy.com/en-us/training-courses/introduction-to-aspnet-5-13786?l=PvSZtxoXB_5101937557