1. ASP.NET Core 1.0 MVC 6 OWIN Fast-Start per sviluppatori web
Gianluca Bertelli, Alessandro Bigi

2. Agenda .NET Core ASP.NET Core ASP.NET Core MVC DevOps: HTTP Servers
Demo #1: Hello World!
ASP.NET Core MVC
Demo #2: Tag Helpers
Demo #3: OpenIDConnect & Azure AD
DevOps: HTTP Servers
Kestrel & IIS Integration
Q&A
Agenda –

3. .NET Core Gianluca Bertelli–

4. .NET CORE My C# Code Console App + ASP.NET Core Class Library
Framework
netcoreapp1.0
Core Class Library
CoreClr
DOTNET
CoreClr
DOTNET
CoreClr
DOTNET
.NET Core
Runtime
Attenzione, le definizioni sono un po’ diverse dal consueto:
FRAMEWORK = è il modello di applicazione che si va a costruire, costituito dalla base class library (.net standard) + le classi specifiche per l’applicazione. Ne esistono diversi (es. . netcoreapp1.0, net46, net452.. netstandard1.6..)
RUNTIME = è il motore, specifico per ogni piattaforma, che implementa .NET core. Ne esistono diverse versioni, una per ogni sistema operativo supportato (x64-x86). Ci sono runtime che implementano piu di un framework (vedi .NET che implementa 4.5, 4.5.1, 4.6..etc)
In Windows abbiamo DOTNET.EXE che esegue tutti I comandi come compile/build/publish ed è allo stesso tempo l’ambiente di esecuzione (quindi il mio codice gira dentro di lui).
Quando faccio il build dotnet.exe viene rinominato col nome del mio progetto, ma il progretto rimane nella DLL (anche se non sembra è un sempre dotnet.exe)
Windows
Linux
Mac OS X –

5. Project.json ASP.NET Core App
"dependencies": { "Microsoft.NETCore.App": "1.0.1", "Microsoft.AspNetCore.Hosting": " 1.1.0" "Microsoft.AspNetCore.Server.Kestrel": "1.0.1" }, "frameworks": { "netcoreapp1.0": {} }
Web Server
ATTENZIONE PROJECT.JSON VERRA’ DISMESSO E SI TORNA A .CSPROJ E MSBUILD.
Tuttavia le nozioni rimangono valide
Specificare il framework netcoreapp1.0 significa eseguire con l’engine di .NET CORE = CORECLR.DLL
Specificare il framework net46 significa eseguire con l’engine di .NET classico = CLR.DLL –

6. ASP.NET Core Alessandro Bigi–

7. Fast Choose your Editors and Tools Open Source with Contributions
Cross-Platform
OSS
Seamless transition from on-premises to cloud
Faster Development Cycle
Totally Modular
Fast –

8. Startup Startup Program.cs Services Middleware Web Host Builder
ConfigureServices ( )
.UseStartup ( )
Program.cs
Web Host Builder
Services
Middleware
Configure ( ) –

9. Open Web Interface for .NET
Middleware
Open Web Interface for .NET
Host
Middleware 1
Middleware 3
Middleware 2
Request
Response
Context
next
Exception Handler
Authentication
Static Files –

10. Demo #1 Hello WPC! Alessandro Bigi–

11. ASP.NET Core MVC Alessandro Bigi–

12. ASP.NET Core MVC Self-hosting Routing Razor Improvements
Dependency Injection
TagHelpers
Web API
Attribute routing
Inline defaults
Optionality
Constraints
Route fall-through
Async
@await
Flush points
C# 6 support
@using
Controllers & Views
Built-in and custom tag helpers
Editor intellisense
Core without Views
Content Negotiation
Swagger via Swashbuckle –

13. MVC 5 Web Pages MVC Web API Razor HTML Helpers HTML Helpers
Controllers
Actions
Filters
Model binding DI
Controllers
Actions
Filters
Model binding DI –

14. ASP.NET Core MVC (MVC 6) MVC ASP.NET Core MVC Web API Web UI Web API
Tag Helpers
New Razor
Routing
IIS / self-host DI –

15. Demo #2 Tag Helpers Alessandro Bigi–

16. Demo #3 OpenIDConnect & Azure AD
Gianluca Bertelli –

17. DevOps: HTTP Servers Gianluca Bertelli–

18. DevOps: HTTP Servers Internet KESTREL IIS WEB LISTENER NGINX APACHE
.UseWebListener()
DevOps: HTTP Servers
Internet
.UseIISIntegration()
KESTREL
IIS
WEB LISTENER
Basato su HTTP.SYS
HTTP2
Port Sharing
HTTPS + SNI
Windows Authentication
Default
High performance
Unix sockets
NGINX
APACHE
.UseKestrel()
.NET CORE SERVERS
WebListener vs HttpListener
CUSTOM –

19. Sessioni consigliate 29/11 30/11 1/12
WPC070: CLR Deep Dive Antonio Esposito
30/11
WPC038: Migrare ASP.NET 4 verso ASP.NET Core, Andrea Saltarello
1/12
WPC073: .NET Core e Visual Studio in azione Raffaele Rialdi
ASP.NET Core 1.0 Hands-On
Gabriele Gaggi
Sessioni consigliate –

20. Domande e Risposte
Q&A –

21. Contatti OverNet Education
Tel
@overnete
Contatti OverNet Education –

22. .NET STANDARD My C# Code .NET Standard .NET BCL MONO Library
Core Class Library
Runtime
.NET 4.6
MONO
CoreClr
Runtime
Windows
Windows
Windows
Runtime
Linux
Linux
Replacement of PCL .
Alcuni runtime implementano APPMODEL aggiuntivi, MONO (XAMARIN/FORMS), .NET (WPF…)
Specificare il runtime (di default non lo è) significa indicare al compilatore su quali piattaforme potra’ girare, è una sezione del project.json:
"runtimes": {
"win10-x64": {},
"win7-x86": {},
"osx x64": {},
"ubuntu x64": {} }
Cosi facendo si puo’ fare il build per le diverse piattaforme manualmente (rimuovere "type": "platform“ dal file):
dotnet build –r “XXXX”
Se non specifico i runtime il codice viene eseguito sulla piattaforma corrente, se specifico esempio win10
Mac OS X
Mac OS X –

23. 1.1 1.3 1.6 2.0 .NET STANDARD .NET 4.5 .NET 4.6 .NET 4.6.x–

24. Project.json Shared library { "dependencies": {
"NETStandard.Library": "1.6.0" },
"frameworks": {
"netstandard1.6": {} } –

25. Hosting Listener Server Host ASP.NET Core App–

26. Compilers and runtime components
.NET Compiler Platform (Roslyn), C#, VB, F#, Languages, RyuJIT, SIMD
.NET Framework Libraries
.NET Core Libraries
.NET Framework 4.6
.NET Core 1.0
ASP.NET 4.6
ASP.NET Core 1.0
OSS –

27. What’s new in 1.1 URL Rewriting Middleware
Azure App Service logging provider
Response Caching Middleware
Azure Key Vault configuration provider
WebListener Server for Windows
View Components as Tag Helpers
Redis and Azure Storage Data Protection Key Repositories
Middleware as MVC filters
Cookie-based TempData provider
Hosting and performance improvements
View compilation
URL Rewriting Middleware
We are bringing URL rewriting functionality to ASP.NET Core through a middleware component that can be configured using IIS standard XML formatted rules, Apache Mod_Rewrite syntax, or some simple C# methods coded into your application.  When you want to run your ASP.NET Core application outside of IIS, we want to enable those same rich URL rewriting capabilities regardless of the web host you are using.  If you are using containers, Apache, or nginx you will be able to have ASP.NET Core manage this capability for you with a uniform syntax that you are familiar with.
URL Rewriting allows mapping a public URL space, designed for consumption of your clients, to whatever representation the downstream components of your middleware pipeline require as well as redirecting clients to different URLs based on a pattern.
For example, you could ensure a canonical hostname by rewriting any requests to to instead be for everything after the re-write rules have run. Another example is to redirect all requests to to You can even configure URL rewrite such that both rules are applied and all requests to example.com are always redirected to SSL and rewritten to www.
Response Caching Middleware
Response Caching similar to the OutputCache capabilities of previous ASP.NET releases can now be activated in your application by adding the Microsoft.AspNetCore.ResponseCaching and the Microsoft.Extensions.Caching.Memory packages to your application.  You can add this middleware to your application in the Startup.ConfigureServices method and configure the response caching from the Startup.Configure method.  For a sample implementation, check out the demo in the ResponseCaching repository.
You can now add GZipCompression to the ASP.NET HTTP Pipeline if you would like ASP.NET to do your compression instead of a front-end web server.  IIS would have normally handled this for you, but in environments where your host does not provide compression capabilities, ASP.NET Core can do this for you.  We think this is a great practice that everyone should use in their server-side applications to deliver smaller data that transmits faster over the network.
WebListener Server for Windows
WebListener is a server that runs directly on top of the Windows Http Server API. WebListener gives you the option to take advantage of Windows specific features, like support for Windows authentication, port sharing, HTTPS with SNI, HTTP/2 over TLS (Windows 10), direct file transmission, and response caching WebSockets (Windows 8).  This may be advantageous for you if you want to bundle an ASP.NET Core microservice in a Windows container that takes advantage of these Windows features.
ViewComponents are an ASP.NET Core display concept that provides for a razor view that is triggered from a server-side class that inherits from the ViewComponent base class.  You can now invoke from your views using Tag Helper syntax and get all the benefits of IntelliSense and Tag Helper tooling in Visual Studio. Previously, to invoke a View Component from a view you would use the Component.InvokeAsync method and pass in any View Component arguments using an anonymous object:
@await Component.InvokeAsync("Copyright", new { website = "example.com", year = 2016 })
Instead, you can now invoke a View Component like you would any Tag Helper while getting Intellisense for the View Component parameters:
<vc:copyright website=“example.com” year=2016></vc:copyright>
Middleware as MVC filters
Middleware typically sits in the global request handling pipeline. But what if you want to apply middleware to only a specific controller or action? You can now apply middleware as an MVC resource filter using the new MiddlewareFilterAttribute.  For example, you could apply response compression or caching to a specific action, or you might use a route value based request culture provider to establish the current culture for the request using the localization middleware.
To use middleware as a filter you first create a type with a Configure method that specifies the middleware pipeline that you want to use:
You then apply that middleware pipeline to a controller, an action or globally using the MiddlewareFilterAttribute:
[MiddlewareFilter(typeof(MyCustomPipeline))]
Cookie-based TempData provider
To use the cookie-based TempData provider you register the CookieTempDataProvider service in your ConfigureServices method after adding the MVC services as follows:
services.AddMvc(); services.AddSingleton<ITempDataProvider, CookieTempDataProvider>();
View compilation
The Razor syntax for views provides a flexible development experience where compilation of the views happens automatically at runtime when the view is executed. However, there are some scenarios where you do not want the Razor syntax compiled at runtime. You can now compile the Razor views that your application references and deploy them with your application
Azure App Service logging provider
The Microsoft.AspNetCore.AzureAppServicesIntegration package allows your application to take advantage of App Service specific logging and diagnostics. Any log messages that are written using the ILogger/ILoggerFactory abstractions will go to the locations configured in the Diagnostics Logs section of your App Service configuration in the portal (see screenshot).  We highly recommend using this logging provider when deploying an application to Azure App Service.  Prior to this feature, it was very difficult to capture log files without a third party provider or hosted service.
Azure Key Vault configuration provider
Azure Key Vault is a service that can be used to store secret cryptographic keys and other secrets in a security hardened container on Azure.  You can set up your own Key Vault by following the Getting Started docs. The Microsoft.Extensions.Configuration.AzureKeyVault package then provides a configuration provider for your Azure Key Vault. This package allows you to retrieve configuration from Key Vault secrets on application start and hold it in memory, using the normal ASP.NET Core configuration abstractions to access the configuration data.
Redis and Azure Storage Data Protection Key Repositories
The Microsoft.AspNetCore.DataProtection.AzureStorage and Microsoft.AspNetCore.DataProtection.Redis packages allow storing your Data Protection keys in Azure Storage or Redis respectively. This allows keys to be shared across several instances of a web application so that you can  share an authentication cookie, or CSRF protection across many load balanced servers running your ASP.NET Core application. As data protection is used behind the scenes for a few things in MVC it’s extremely probable once you start scaling out you will need to share the keyring. Your options for sharing keys before these two packages would be to use a network share with a file based key repository. –

28. Startup Configure Use Next Response Build Middleware Run middleware–

29. ASP.NET Core ASP.NET 4 HTTP Modules Middleware Project Katana
Microsoft.AspNet.Owin
Flexibility
OWIN
public class Startup {
public void Configuration(IAppBuilder app)
app.UseMyOwinMiddleware(); }
public class Startup {
public void Configure(IApplicationBuilder app)
app.UseOwin(pipeline =>
pipeline(next => OwinHello);
}); }
ASP.NET Core implementa nativamente un concetto di Middleware in sostituzione degli HTTPHandlers.
Maggiore flessibilità
Ordinamento del middleware non dipende dagli eventi della pipeline (application lifecycle) ma dall’ordine di configurazione
NON E’ ESATTAMENTE COME OWIN
OWIN definisce uno standard leggermente diverso, anche se simile.
Si può fare un BRIDGE con app.useOwin()
Microsoft.AspNet.Owin
Project Katana è stato portato in ASP.NET Core:
Microsoft.Owin -
Microsoft.Owin.Diagnostics -
Microsoft.Owin.FileSystems -
Microsoft.Owin.StaticFiles -
Microsoft.Owin.Hosting, Microsoft.Owin.Testing, OwinHost -
Microsoft.Owin.Security.* -
Microsoft.Owin.Host.HttpListener - Microsoft.AspNet.Server.WebListener (no public link yet)
Microsoft.Owin.Host.SystemWeb - Microsoft.AspNet.Server.IIS (no public link yet)
Microsoft.Owin.Cors - TBD –