ASP.NET vNext ANUG 20140817

ASP.NET vNext
Intro and Hands-On

Agenda
Introduction and my opinions
Break + sandwiches
Hack

About me
Christian Horsdal
Independent Consultant
www.horsdal-consult.dk
c.horsdal@gmail.com
@chr_horsdal

Highlights
K runtime
Modularized .NET
Bin deploy
OWIN
Less dependent on Visual Studio

ASP.NET 12 Years Ago
IIS
.NET BCL
ASP.NET
HTTP
Modules
ASP.NET WebForms
HTTP
Handlers
Request
pipeline
HTTP
Context
Caching Session
State

ASP.NET Today
IIS
.NET BCL
ASP.NET
ASP.NET MVC ASP.NET Web API
HTTP
Modules
ASP.NET WebForms
HTTP
Handlers
Request
pipeline
HTTP
Context
et al.
Caching Session
State

ASP.NET – things not in Vnext
IIS
.NET BCL
ASP.NET
HTTP
Modules
ASP.NET WebForms
HTTP
Handlers
Request
pipeline
HTTP
Context
et al.
Caching Session
State

ASP.NET vNext – Guiding Principles
No dependency on System.Web
this is huge
Cross platform
Low friction
(this is my interpretation)

No System.Web
The System.Web namespace supplies classes and
interfaces that enable browser-server communication.
This namespace includes the HttpRequest class,
which provides extensive information about the current
HTTP request; the HttpResponse class, which
manages HTTP output to the client; and the
HttpServerUtility class, which provides access to
server-side utilities and processes. System.Web also
includes classes for cookie manipulation, file transfer,
exception information, and output cache control.

No System.Web
System.Web is at the very core of ASP.NET
Context
Request
Response
Session
Pipeline (that nasty global.asax stuff)
WebForms is intimately coupled to System.Web

No System.Web
MVC is not (so) tightly coupled to System.Web
Nor is WebAPI

No System.Web
Your MVC/WebAPI project may be, though
HttpContext, HttpRequest, HttpResponse
SessionState
Caching

No System.Web
Unless you want to…
Because legacy code
Because WebForms
Which still will improved on

ASP.NET – and things changes in Vnext
IIS
.NET BCL
ASP.NET
HTTP
Modules
ASP.NET WebForms
HTTP
Handlers
Request
pipeline
HTTP
Context
Caching Session
State

MVC + WebAPI
…will be unified
One controller type
Micorsoft.AspNet.Mvc.Controller
Or POCO controllers

MVC + WebAPI
One depedency injection solution
…registering ”services” during startup.
…inject in all
…including SignalR

MVC + WebAPI
Poke around in code

ASP.NET – and things changed in Vnext
IIS
.NET BCL
ASP.NET
HTTP
Modules
ASP.NET WebForms
HTTP
Handlers
Request
pipeline
HTTP
Context
Caching Session
State

Cloud Optimized Framework
Because cloud. CLOUD. CLOUD
Trimmed down
Opt-in to more through NuGets
Not in GAC

Framework not in GAC
Bin deploy
Side-by-side deploy
Good or bad for operations?

Detour: OWIN
Applicaiton
Middleware
Middleware
Server
Middleware
Middleware
IDictionary<string, object>

OWIN
using AppFunc =
Func<IDictionary<string, object>, // Environment
Task>; // Done

OWIN – Request Environment
Required Key Name
Yes "owin.RequestBody"
Yes "owin.RequestHeaders"
Yes "owin.RequestMethod"
Yes "owin.RequestPath"
Yes "owin.RequestPathBase"
Yes "owin.RequestProtocol"
Yes "owin.RequestQueryString"
Yes "owin.RequestScheme"

OWIN – Response Environment
Required Key Name
Yes "owin.ResponseBody"
Yes "owin.ResponseHeaders"
No "owin.ResponseStatusCode"
No "owin.ResponseReasonPhrase"
No
"owin.ResponseProtocol"

OWIN in vNext
public class Startup
{
public void Configure(IBuilder app)
{
app.UseOwin(x => x.UseNancy());
}
}

OWIN in vNext
public class Startup
{
public void Configure(IBuilder app)
{
var buildFunc = app.UseOwin();
buildFunc(next => MyApp);
}
public Task MyApp(IDictionary<string, object> environment)
{
var responseText = "Hello World";
var responseBytes = Encoding.UTF8.GetBytes(responseText);
var responseStream = (Stream)environment["owin.ResponseBody"];
var responseHeaders = (IDictionary<string, string[]>)environment["owin.ResponseHeaders"]
responseHeaders["Content-Length"] =
new string[] { responseBytes.Length.ToString(CultureInfo.InvariantCulture) };
responseHeaders["Content-Type"] = new string[] { "text/plain" };
return responseStream.WriteAsync(responseBytes, 0, responseBytes.Length);
}
}

Startup.cs
Choose frameworks
MVC
SignalR
Third party
Setup OWIN pipeline

Startup.cs
Read configuration
Format is configurable, default json
Setup DI
Across everything

Startup.cs
Poke around in code

K Runtime
Command line for all things vNext
Or so it seems it will be
K Version Manager (kvm)
K Package Manager (kpm)
K Runtime Environment (kre)
K

K Runtime
Application
Frameworks (MVC, WebAPI, 3rd party) & OWIN middleware
KRE
CoreCLR FullCLR Mono

K Version Manager
PS C:projectsvNext-playHelloNancy> kvm list
Active Version Runtime Architecture Location
------ ------- ------- ------------ --------
1.0.0-alpha2 svr50 x86 C:Userschors_000.krepackages
1.0.0-alpha2 svrc50 x86 C:Userschors_000.krepackages
* 1.0.0-alpha3-10201 svr50 x86 C:Userschors_000.krepackages
PS C:projectsvNext-playHelloNancy> kvm use 1.0.0-alpha3*
Adding C:Userschors_000.krepackagesKRE-svr50-x86.1.0.0-alpha3*bin to process PATH

K Version Manager
Install KREs
Upgrade KREs
Set KRE per process
I.e. per powershell window

K Package Manager
Restores NuGets
But slightly smarter – kinda
Packages application

Detour: project.json
Superseedes package.config
Superseedes .csproj
{
"dependencies": {
"Microsoft.AspNet.Server.IIS" : "1.0.0-alpha2",
"Microsoft.AspNet.Server.WebListener" : "1.0.0-alpha2",
"Microsoft.AspNet.Owin": "1.0.0-alpha2",
"Nancy" : "0.24-Pre1412"
},
"configurations" : {
"net451" : { },
"k10" : { }
}
}

project.json
Projects are NuGet or class libraries
Same syntax
Interchangeable
More or less no difference

project.json
{
"dependencies": {
"Nancy" : "0.24-Pre1412"
},
"net451" : { },
"k10" : { }
}
}

project.json
DOES NOT LIST ALL FILES IN PROJECT

project.json
Commands:
Arbitrary powershell
No more weird MSBuild mockery (I hope)
{
"dependencies": {
"Nancy" : "0.24-Pre1412"
},
"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener
--server.urls http://localhost:5000"
},

K
Command line for KRE
Executes commands from project.json
In context of a KRE

K + Roslyn
= dynamic compilation of entire site

K, KPM, KVM, KRE
No ties to Visual Studio
Point-in-case: Kulture

Why Do I Care?
More OWIN
Better opportunity for .NET OSS
OWIN Middleware eco system will blosson
 Nice modular way of working

Why Do I Care?
Modularized .NET + bin deploy
Smaller footprint on disk and memory (!)
Faster development from MS on some parts
Side-by-side on different versions

Why Do I Care?
K and cross platform:
Broader potential developer crowd
K as enabler for own tooling
K as enabler for 3rd party / OSS tooling
(and I’m not thinking about Jetbrains)

Visual Studio 14 CTP*
Everybody got this???

k
Goto https://github.com/aspnet/Home
Make sure you allow remote scripts
Run the crazy command

Exercise: URL shortener
Follow shortened url
HTTP GET “/shorts” Redirect to original URL
Submit URL to shorten
HTTP POST “/” Shorten, store, return shortened URL
Get front page
HTTP GET “/” Web page with a simple form

Storing shortened URLs
Common MongoHQ database
Code at:
https://gist.github.com/horsdal/cbbf50bcbf3ff0904477
See Facebook

Things to do a long the way
Play with dynamic compile
Switch KRE with kvm
Write some stupid OWIN middleware
Do the URL shortener in MVC
Do the URL shortener in raw OWIN
K pack your app and move it
Add dependency to project.json, save and watch projects references
If CTP3 add xUnit test project as ASP.NET vNEXT class lib

ASP.NET vNext ANUG 20140817

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à ASP.NET vNext ANUG 20140817

Similaire à ASP.NET vNext ANUG 20140817 (20)

Plus de Christian Horsdal

Plus de Christian Horsdal (9)

Dernier

Dernier (20)

ASP.NET vNext ANUG 20140817