Beruflich Dokumente
Kultur Dokumente
NET Core
Luis Ruiz Pavn
Unai Zorrilla Castro
Eduard Toms
Quique Martnez
CREATIVIDAD:
Diseo Cubierta: Pablo Iglesias Francisco
Fruta Cubierta: El aguacate es un fruto extico carnoso que se obtiene del rbol tropical del mismo
nombre. En algunas partes de Amrica del Sur se conoce como Palta. Se cree que es originario de
Mxico, y su nombre procede del del nhuatl ahucatl (testculo en espaol). Presenta unas
dimensiones de 5-6 cm de longitud. El peso normal oscila entre 200-400 g. La corteza es gruesa y
dura de color verde cuyo tono depende de la variedad. La pulpa es aceitosa de color crema a verde
amarillento. Posee una nica semilla redondeada de color pardo claro y 2-4 cm, que aparece
recubierta de una delgada capa leosa.
Agradecimientos
Nunca pens que escribir un libro llevara tanto trabajo, ms an cuando uno no es
escritor ni por vocacin, ni por profesin, y adems tiene que compaginarlo al mismo
tiempo con su vida familiar y laboral.
As debo agradecer a mi familia la comprensin que ha tenido conmigo durante este
tiempo.
A mi madre Antonia, porque de no ser por ella y por sus sabios consejos no sera lo
que soy y no habra podido llegar hasta aqu.
A mi padre, Luis, que me ha enseado lo importante que es trabajar duro y nunca tirar
la toalla en los momentos duros.
A mi mujer Natalia, porque la debo todo en esta vida, porque sin ella yo no soy nada
y porque me ha regalado lo ms bonito de esta vida, mis 2 hijas, Paula y Martina.
A mis hermanas Roco, Vero y Ana, que son un pilar fundamental en mi vida.
A mis sobrinos Ciro, Javier, Candela y Alejandro.
A mis cuados Miguel, JJ y Arse por cuidar de mis hermanas.
A mis suegros Pilar y Manolo y a mi cuada Ruth, por quererme como uno ms en la
familia y por su ayuda incondicional.
A Unai, por ofrecerme la oportunidad de formar parte de este libro.
Luis Ruiz Pavn
Hace ya un tiempo que pens que nunca ms tendra que pasar por el trance de escribir
un prlogo de un libro. Despus de hacer este trabajo diversas veces las ganas de
enfrentarme a un folio en blanco haban desaparecido. No tena demasiadas ilusiones por
escribir sobre versiones 5, 6, 7 de un producto ya conocido en que me pareca estar
repitiendo continuamente lo mismo. Sin embargo, hace ya unos meses, entre mis
compaeros de libro y yo pensamos que tanto .NET Core como ASP.NET Core 1 eran
lo suficientemente motivantes como lanzarnos de nuevo a esta aventura. Nuevas cosas
que ensear y sobre todo aprender, porque escribiendo un libro se aprende un montn de
cosas.
De nuevo, mucha gente de la comunidad aqu en Espaa est involucrada en esta
nueva versin del producto, sobre la que nosotros ahora escribimos, una comunidad llena
de tiburones que crean mucho contenido y comparten en muchos grupos de usuarios sus
experiencias y lecciones aprendidas. Para esta comunidad de tiburones va dedicado este
libro, para que sigan luchando contra los rapes, para que sigan creciendo, para que sigan
disfrutando con lo que hacen y sigan hacindonos disfrutar a los dems.
Por supuesto este libro se lo dedico tambin a mi mujer e hija, a las cuales no hago
ms que robarles tiempo para estas aventuras. Gracias!!
Para finalizar este libro est dedicado tambin a todos mis compaeros de Plain
Concepts, compaeros con los que aprendo todos los das.
Unai Zorrilla Castro
A Neus y Noa que, a pesar de sufrir mi falta de tiempo, nunca han dejado de
animarme. Sin ellas no hubiera sido posible.
Eduard Toms i Avellana
La verdad es que este es el primer prlogo que escribo y espero que no sea el ltimo.
Esta experiencia me ha servido para saber lo duro que es enfrentarse a una hoja en blanco
y para que me entren ganas de querer afrontar esta aventura de nuevo.
Desde pequeo he tenido una gran virtud, siempre he sabido rodearme de gente mejor
que yo para mejorar todo lo posible y esta vez no iba a ser diferente. Por el ello lo primero
que me gustara es dar las gracias a Unai, Luis y Eduard por dejarme aportar un pequeo
granito de arena en esta aventura llamada libro. Sobre todo, a Unai que ha orquestado
todo esto para que tengamos este libro con nosotros. Tengo la suerte de no solo compartir
con ellos esta aventura, sino que comparto el da a da de mi trabajo y siempre es un
placer trabajar con gente como ellos.
El da a da, cuando tu trabajo y tu pasin se unen siempre se lo tienes que agradecer a
los que te rodean, ya que al final son ellos los que sacrifican muchas cosas para estemos
involucrados en lo que muchas veces nos gusta llamarle comunidad.
Por ello quiero dar las gracias a mis padres Manuel y Donilia que me han dado todo
lo necesario y los valores para ser quien soy a da de hoy.
A Sheila que es la persona con la que he decidido empezar un viaje juntos llamado
vida y es la que ve como semana a semana tengo que hacer una maleta y arrancar un
iv
viaje para participar en eventos o por trabajo ya que como ella dice esto es lo que te hace
feliz.
A mi familia y familia poltica que siempre estn ah cuando los he necesitado.
Y por ltimo a Plain Concepts, la empresa que no solo me ha hecho crecer como
profesional, sino que me ha hecho ser mejor persona y me ha dado muchos momentos a
recordad durante estos aos.
Por todo esto y ms muchas gracias!
Quique Martnez
Contenido
AGRADECIMIENTOS ............................................................................................... III
CONTENIDO ............................................................................................................VII
AUTORES ................................................................................................................ XIII
PRLOGO ................................................................................................................ XV
CAPTULO 1: INTRODUCCIN A .NET CORE 1.0...........................................19
1.- Por qu .NET CORE? ............................................................................................................. 19
2.- .NET standard Library y .NET standard platform ............................................................. 20
3.- Qu es .NET CORE? .............................................................................................................. 24
3.1.- CoreFx.............................................................................................................................. 28
3.2.- CoreCLR ........................................................................................................................ 29
3.3.- CoreRT ............................................................................................................................ 29
3.4.- CLI 31
3.4.1.- El comando new ..................................................................................................... 32
3.4.2.- El comando restore............................................................................................... 32
3.4.3.- El comando run ...................................................................................................... 34
3.4.4.- El comando build.................................................................................................... 35
3.4.5.- El comando test...................................................................................................... 37
3.4.6.- El comando pack .................................................................................................... 39
3.4.7.- El comando publish................................................................................................ 40
3.5.- Instalacin de .NET Core SDK .................................................................................. 41
3.5.1.- Instalacin en Windows ....................................................................................... 42
3.5.2.- Instalacin en Linux ............................................................................................... 48
3.5.3.- Instalacin en MacOS............................................................................................ 51
3.5.4.- Instalacin de Dotnet en Docker ...................................................................... 54
CAPTULO 2: INTRODUCCIN A ASP.NET CORE 1.0 ...................................65
1.- Introduccin................................................................................................................................ 65
1.1.- Estructura de una aplicacin ASP.NET Core ......................................................... 67
1.1.1.- Global.json ............................................................................................................... 74
1.1.2.- Project.json .............................................................................................................. 75
1.1.3.- La carpeta wwwroot ............................................................................................. 83
1.2.- Anatoma de una aplicacin ASP.NET Core ........................................................... 87
1.3.- Desarrollando ASP.NET Core con dotnet watch ................................................. 88
CAPTULO 3: STARTUP..........................................................................................93
1.- Introduccin................................................................................................................................ 93
1.1.- El constructor ................................................................................................................. 94
1.2.- El mtodo Configure..................................................................................................... 95
1.3.- El mtodo ConfigureServices ..................................................................................... 96
1.4.- Servicios disponibles ..................................................................................................... 97
2.- Configuraciones por entorno................................................................................................. 98
2.1.- Development .................................................................................................................. 99
2.2.- Staging ............................................................................................................................. 100
2.3.- Production ..................................................................................................................... 100
2.4.- Las variables de entorno ............................................................................................ 100
2.4.1.- Variables de entorno en Windows ................................................................. 101
2.4.2.- Variables de entorno en Linux ......................................................................... 104
2.4.3.- Variables de entorno en OS X ......................................................................... 105
2.5.- Convenciones de configuracin ............................................................................... 106
2.5.1.- Determinando el entorno en tiempo de ejecucin .................................... 106
2.5.2.- Convenciones de la clase Startup .................................................................... 108
CAPTULO 4: MIDDLEWARES ............................................................................111
1.2.3.4.-
Introduccin.............................................................................................................................. 111
Los mtodos run, map y use ................................................................................................ 113
Creando nuestro primer middleware ................................................................................ 118
Middlewares comunes ............................................................................................................ 122
4.1.- Uso de ficheros estticos........................................................................................... 122
4.1.1.- Manejo de errores y pginas de excepcin ................................................... 124
Contenido ix
Introduccin.............................................................................................................................. 217
ASP.NET Core autenticacin y autorizacin .................................................................. 218
ASP.NET Core identity ......................................................................................................... 225
Autorizacin en ASP.NET Core .......................................................................................... 238
4.1.- Autorizacin simple..................................................................................................... 238
4.2.- Autorizacin basada en roles.................................................................................... 239
4.3.- Autorizacin basada en claims.................................................................................. 242
4.4.- Autorizacin basada en polticas personalizadas ................................................. 244
4.5.- Autorizacin basada en recursos............................................................................. 248
Contenido xi
Autores
Luis Ruiz Pavn
Desarrollador por vocacin y, desde hace 15 aos, dedicado de manera profesional al
mundo del desarrollo de software. Ha trabajado con multitud de tecnologas y lenguajes,
aunque en los ltimos 10 aos se ha centrado sobre todo en tecnologas Microsoft. Es
Most Valuable Professional desde 2012 en la categora de ASP.NET. Es co-fundador del
grupo de usuarios de Madrid MsCoders, cuyo objetivo principal es el de servir como
lugar de encuentro y reunin quincenal donde se debatan y compartan temas tcnicos
especialmente relacionados con tecnologas Microsoft. Trabaja en Plain Concepts.
Unai Zorrilla Castro
Lleva cerca de 15 aos desarrollando software como consultor independiente y en
diversas empresas privadas, realizando las tareas de arquitectura de software bajo
plataforma .NET y tocando distintas ramas tecnolgicas. Autor de varios libros y ponente
habitual en conferencias de desarrollo, colabora activamente con la comunidad, con la
que le gusta estar en permanente contacto. Ha sido galardonado con el reconocimiento
MVP de Microsoft en diversas categoras desde el ao 2006. Es socio fundador y
Development Team Leader en Plain Concepts.
Eduard Toms i Avellana
Eduard Toms es ingeniero informtico y atesora ms de 12 aos de experiencia
como desarrollador. Est especializado en desarrollo de aplicaciones web y mviles.
Mantiene un blog sobre desarrollo en general y ASP.NET MVC en particular en
http://geeks.ms/etomas. Colabora con la comunidad impartiendo charlas presenciales, en
formato webcast y en eventos de distintos grupos de usuarios. Hace de su pasin su
profesin desarrollando en Plain Concepts.
Quique Martnez Aln
Un apasionado de la arquitectura de software y del Cloud Computing (en concreto
Microsoft Azure), ha sido nombrado Microsoft MVP de esta tecnologa durante los
ltimos 4 aos, y adems pertenece a los Azure Insiders. Le encanta ser ponente en
eventos tcnicos y colaborar todo lo posible en comunidades de desarrollo. Actualmente
tiene el placer de trabajar en Plain Concepts.
xiii
CAPTULO
Introduccin a .NET
Core 1.0
Te imaginas poder crear aplicaciones .NET para Windows, Linux y Mac con
un editor multiplataforma y con un conjunto de herramientas adaptadas al
desarrollo moderno de aplicaciones? Suena muy bien verdad? Pues eso ya es
real. Ahora .NET Core es Open Source, multiplataforma y abre nuevos escenarios
para todos los desarrolladores .NET.
Framework monoltico.
Adems de todos estos puntos que hemos citado, otro de los problemas actuales
derivados de .NET Framework tiene que ver con las instalaciones.
Como seguramente sabrs, es un requisito previo que antes de ejecutar cualquier
aplicacin .NET Framework en una mquina, tengamos instalada la versin
correspondiente de .NET Framework. Y debemos tener mucho cuidado con las
actualizaciones que hagamos, pues podramos romper otras aplicaciones que ya se estn
ejecutando en produccin. Si una nueva versin de .NET Framework es liberada y
queremos utilizar esta nueva versin para un nuevo desarrollo y aprovechar las nuevas
caractersticas que traiga consigo, una vez terminado nuestro desarrollo, tendremos que
proveer o instalar antes la nueva versin de .NET Framework. Y es algo conocido en el
mundo del desarrollo de software que o somos dueos y seores de nuestros servidores
o si por el contrario trabajamos en una empresa o para un cliente que tiene un
departamento de IT, no actualizar a la ligera las mquinas a la nueva versin de .NET
sin antes realizar algn tipo de laboratorio experimental para ver que nada afecta a lo que
ya existe y est funcionando en produccin.
As pues, debido a todos los cambios que se han efectuado en .NET Core a nivel de
arquitectura, disponemos de un framework mucho ms modular y ligero, que consume
menos memoria y aprovecha mejor los recursos. Otro punto no menos importante es la
multiplataforma, ya que puede ejecutarse en Linux, MacOS y Windows.
As pues, podemos afirmar que .NET Core es el futuro, fruto de la innovacin y el
esfuerzo por parte de Microsoft para ofrecernos a los desarrolladores las mejores
herramientas adaptadas para el desarrollo moderno.
Tanto .NET Framework como .NET Core comparten muchos componentes: los
lenguajes (C#/VB.NET), el compilador Roslyn, el compilador JIT encargado de
convertir el cdigo IL a cdigo nativo de 32 y 64 bits (RyuJIT), el recolector de basura,
etc.
Para paliar un poco esta problemtica y hacernos la vida algo ms fcil a los
desarrolladores, Microsoft cre la Biblioteca de clases portables o PCL. Se trata de un
nuevo tipo de proyecto incluido en Visual Studio, que nos permite crear aplicaciones
multiplataforma y bibliotecas de una manera rpida y sencilla para garantizar
portabilidad binaria entre diferentes modelos de aplicacin.
Figura 2.- Podemos elegir las plataformas de destino en las que compartirn este
cdigo.
que ambas definen APIs que pueden ser usadas para compartir cdigo entre diferentes
plataformas, pero existe una serie de diferencias. En este caso la .NET Standard Library
no se vincula a un conjunto de plataformas, sino a una versin de .NET Standard. Es lo
que se conoce con el trmino anglosajn open-ended o bsicamente, que no estn
ligadas a una lista esttica de monikers como las bibliotecas portables, por ejemplo
portable-a+b+c. En este caso aparece un nuevo moniker llamado netstandard, as pues
cuando desarrollemos una biblioteca no vamos a vincularla a ese conjunto esttico, sino
que lo vincularemos a una versin de netstandard. Para entender su funcionamiento,
fjate en la siguiente imagen:
Si nuestra biblioteca apunta a la versin 1.3 de .NET Platform Standard, quiere decir
que solo podr ejecutarse de .NET 4.6 en adelante, en .NET Core, en Universal Windows
Platform y en Mono/Xamarin. Adems nuestra biblioteca puede consumir bibliotecas de
versiones 1.0, 1.1 y 1.2 de .NET Platform Standard.
Para entender todo esto desde un punto de vista ms prctico, unos de los arquitectos
de .NET Core y ASP.NET ha creado este fragmento de cdigo
https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7
donde
explica la relacin de la NET Standard Library, las APIs soportadas y las diferentes
plataformas. As pues, te recomendamos que le eches un vistazo detenidamente.
.NET Core consiste en una mquina virtual o como se conoce en el idioma anglosajn
Common Language Runtime y que en .NET Core se llama CoreCLR. NET Core tambin
se compone de un conjunto de bibliotecas modulares base, CoreFx tambin llamado
.NET Core Framework. Esto permite al desarrollador incluir solo aquellas bibliotecas
que son necesarias sin necesidad de sobrecargar nuestra aplicacin y no incorporar
aquello que no necesitamos. Tambin est formado por un conjunto de herramientas de
lnea de comandos multiplataforma conocidas como .NET CLI (dotnet). Adems, como
alternativa a CoreCLR, disponemos tambin de CoreRT, que es otra mquina virtual
optimizada para escenarios AOT (Ahead Of time Compilation) y que ms adelante
veremos con ms detenimiento y conoceremos su importancia. Adems de todos estos
proyectos, .NET Core tambin se apoya en los compiladores Roslyn y LLILC.
Los principales valores de NET Core son:
como FreeBSD y Alpine donde .NET Core est siendo portado, pero no estn
oficialmente soportadas. Las aplicaciones deben ser recompiladas por entorno,
lo que hace que se puedan ejecutar de manera nativa.
Cdigo abierto: el cdigo fuente de .NET Core est disponible en GitHub con
licencia MIT y Apache 2. La direccin es https://github.com/dotnet/core.
Una vez visto que es .NET Core y que tipos de despliegues existen, vamos a ver
cules son los cuatro pilares de .NET Core:
Todos estos proyectos son de cdigo abierto, por lo que se puedes consultar su cdigo
fuente y contribuir a travs de GitHub: https://github.com. En cada uno de los
apartados iremos viendo cules son las urls de cada uno de los repositorios de cdigo
fuente.
3.1.- CoreFx
https://github.com/dotnet/corefx
CoreFx o .NET Core Libraries es la biblioteca de clases base de .NET Core. Incluye
System.Collections, System.IO, System.Xml, y otros muchos espacios de nombres
fundamentales. Al contrario que en .NET Framework que todo era monoltico, CoreFx
ha sido diseada de manera modular basndose en paquetes de NuGet. Cada uno de sus
componentes es un paquete de NuGet que puede ser instalado en solitario junto con sus
dependencias.
La ventaja de que el framework est basado en paquetes NuGet, es que diferentes
reas del framework pueden ir evolucionando ms rpidamente y a diferentes
velocidades, comparado con el tradicional .NET framework, que tena releases
completos mucho ms pesados y las reas ms lentas de evolucin podran frenar la
rpida evolucin de otras reas del framework
Hay una parte conocida como mscorlib (Microsoft Common Object Runtime
Library) donde residen los tipos base de .NET Core, entre los que se encuentran String,
Int, DateTime y otros muchos ms que puede ver en el siguiente enlace
https://github.com/dotnet/coreclr/tree/master/src/mscorlib. Este cdigo vive en el
repositorio de CoreCLR porque debe ser desarrollado y versionado junto con el runtime
.NET.
El resto de CoreFx es agnstico de la implementacin del runtime, lo que quiere decir
que puede ejecutarse en cualquier .NET runtime compatible.
3.2.- CoreCLR
https://github.com/dotnet/coreclr
3.3.- CoreRT
https://github.com/dotnet/corert
3.4.- CLI
https://github.com/dotnet/cli
.NET Core CLI (.NET Core Command Line Interface) es un conjunto de herramientas
multiplataforma por lnea de comandos que nos permite crear aplicaciones y bibliotecas
con .NET Core. Es la base sobre la que otras herramientas de alto nivel, como por
ejemplo los entornos integrados de desarrollo (IDEs), editores, sern construidas. Si
trabajamos con Visual Studio, el uso de CLI ser bastante transparente gracias a la
integracin con el IDE. La CLI se instala a travs del SDK de .NET Core
Como cualquier otro SDK, dependiendo de nuestro escenario podemos instalarlo
usando los instaladores nativos de cada sistema operativo o instalar el SDK usando los
scripts de instalacin.
Los instaladores nativos se usan principalmente para instalar el SDK en nuestras
mquinas de desarrollo. El SDK se distribuye a travs de instaladores especficos para
cada sistema operativo, en el caso de Ubuntu como paquetes DEB y en el caso de
Windows como instaladores MSI. Cuando ejecutamos el instalador, ste se encarga de
preparar el entorno por nosotros, para una vez finalizada la instalacin, est disponible
para ser usado por el usuario. Esta instalacin requiere privilegios de administracin.
Por otra parte, los scripts de instalacin estn pensados para desplegarse en entornos
como desarrollo, staging o produccin. Lo ideal para desplegar el SDK en este tipo de
entornos, es automatizar todo el proceso a travs de un servidor de integracin continua
(Jenkins, Travis, MSBuild, etc.) para evitar tener que estar haciendo una instalacin
atendida en cada nuevo entorno que aparezca. La instalacin del SDK a travs de script
no necesita privilegios de administracin.
Por defecto, la CLI de .NET Core se instala side-by-side, lo que significa que
podemos tener mltiples versiones de la CLI en nuestra mquina.
A continuacin se muestra la lista de comandos que vienen por defecto instalados con
la CLI:
new
restore
run
build
test
publish
pack
Seguidamente vamos a ir viendo uno por uno todos los comandos anteriores.
Con dotnet new vamos a poder crear un pequeo ejemplo de proyecto .NET Core
para poder hacer nuestras pruebas desde la lnea de comandos.
Cuando ejecutamos el comando dotnet new sobre un directorio, se generan un par
de ficheros:
1. Un fichero Program.cs o Program.fs (dependiendo del lenguaje que hayamos
escogido) que contiene el cdigo de ejemplo de un sencillo Hola Mundo.
2. Un fichero project.json.
Los argumentos que recibe el comando dotnet new son:
1. -l --lang: es el lenguaje con el que se crear el proyecto. Los dos posibles valores
son C# o F#. El valor por defecto es C# por lo que no ser necesario
especificarlo. Los valores csharp, fsharp, cs o fs son opciones vlidas.
2. -t --type: es el tipo de proyecto que queremos crear. Los posibles valores son
console, web, lib y xunittest. El valor por defecto es console.
Un ejemplo de uso sera el siguiente:
dotnet new l f# -t web
Con esta instruccin crearemos un proyecto de tipo web con el lenguaje F#.
El comando dotnet restore llama a NuGet para restaurar todas las dependencias de
nuestra aplicacin. NuGet analiza el fichero project.json y descarga los paquetes que
sean necesarios. Para restaurar dichas dependencias, NuGet necesita tener configurados
unos feeds, que son donde estn ubicados los paquetes. Dichos feeds suelen estar
ubicados en el fichero de configuracin Nuget.config; de hecho cuando instalamos la
CLI se crea uno por defecto. Nosotros podemos aadir ms feeds creando nuestro propio
fichero Nuget.config en el directorio de nuestro proyecto, por ejemplo, un feed privado
nuestro o a Myget. Los feeds tambin se pueden especificar por lnea de comandos al
comando restore.
Podemos especificar el directorio donde queremos que se restauren los paquetes
usando el argumento --packages. Si no lo especificamos, se usa la ubicacin por defecto
de NuGet que es el directorio .nuget/packges que se encuentra el directorio personal del
usuario (por ejemplo, /home/user1 en sistemas operativos Linux o C:\Users\user1 en
Windows). Este directorio acta como cach local, quiere decir que NuGet buscar si
existe ya un paquete en este directorio, si existe lo usar y si no lo descargar del
repositorio de internet.
Una vez ejecutado el comando restore, si miramos en el directorio de nuestra
aplicacin, descubriremos que se ha creado un nuevo fichero project.lock.json.
El fichero project.lock.json contiene el conjunto de dependencias de NuGet y otra
serie de informacin que describe nuestra aplicacin. Adems, este fichero es usado por
otros comandos como dotnet build y dotnet run.
Los argumentos que recibe el comando restore son:
1. [root]: una lista de proyectos o carpetas de proyectos para restaurar sus
dependencias. La lista se puede obtener de una ruta al fichero project.json,
global.json o a una carpeta. Se ejecuta de manera recursiva y para cada uno
de los ficheros project.json que encuentre.
2. -s --source: podemos especificar la ubicacin que se utilizar durante la
restauracin de dependencias. Este parmetro sobrescribir todas las
ubicaciones especificadas en el fichero Nuget.config. Podemos especificar
mltiples ubicaciones especificando varias veces este parmetro.
3. --packages: sirve para especificar el directorio donde se descargarn los
paquetes.
4. --disable-parallel: deshabilitar la restauracin de paquetes en paralelo.
5. -f fallbacksource: usado para indicar una o varias ubicaciones de paquetes
alternativas por si la operacin de restauracin de dependencias falla.
Podemos indicar mltiples ubicaciones definiendo varias veces este
parmetro.
Esta es la ejecucin por defecto. Restaura todas las dependencias para el proyecto
que se encuentra en el directorio actual.
dotnet restore netcoretests\project.json
Nos permite ejecutar nuestra aplicacin desde el cdigo fuente y con un solo
comando. En realidad lo que run est haciendo es compilar el cdigo fuente si no ha
sido compilado previamente o si hay cambios en el cdigo fuente, y del resultado de
dicha compilacin si no hay errores, ejecuta el programa.
Para la compilacin usa el comando dotnet build, que compila el cdigo fuente a un
ensamblado .NET. El resultado de dicha compilacin se almacena en el directorio bin,
al igual que en .NET tradicional. Si dicho directorio no existe, lo crea.
Por ltimo, debemos usar dotnet run slo en el mbito de nuestro proyecto. Para
ejecutar una dll debemos usar el driver de dotnet
dotnet app.dll
Figura 7.- Ejecucin de dotnet build sin antes haber ejecutado un restore.
El comando dotnet test se usa para ejecutar las pruebas de un proyecto. Estas pruebas
son bibliotecas de clases que tienen dependencias con algn entorno de pruebas como
pueden ser xUnit, Nunit, etc. y que dotnet test usa para poder ejecutarlas. Estos
frameworks son paquetes de NuGet que instalan y restauran como una dependencia ms
del proyecto.
En los proyectos de pruebas tenemos que especificar adems cul es el test Runner
con el que queremos que se ejecuten las pruebas. Esto se hace a travs del fichero
project.json y una propiedad llamada testRunner. El valor de esta propiedad debe ser
el nombre del entorno de pruebas unitarias.
A continuacin se muestra el fichero project.json con las propiedades que
necesitamos:
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable"
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.1.1",
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-192208-24"
},
"testRunner": "xunit",
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
},
"imports": [
"dotnet5.4",
"portable-net451+win8"
]
}
}
}
9. --port: este parmetro es usado por los IDEs y editores ligeros para precisarle
al test dnde est el puerto desde donde estn escuchando para que pueda
conectarse.
A continuacin se muestran un par ejemplos de uso del comando test:
dotnet test
Esta es la ejecucin por defecto. Ejecuta todas las pruebas del proyecto que se
encuentran en el directorio actual.
dotnet test /projects/project1/project.json
Es la ejecucin por defecto. Genera los paquetes de NuGet para el directorio actual.
dotnet pack --no-build
Ejecucin por defecto que publica una aplicacin usando el framework que se haya
establecido en el fichero project.json del directorio actual.
dotnet publish ~/projects/project1/project.json
....