11. “Es un entorno de desarrollo (IDE), la
herramienta sobre la cual los programadores
de tecnologías .NET desarrollan el software”
12. Es una Plataforma de Desarrollo, la
cual esta compuesta por:
o Un entorno de ejecución (Runtime) NO es un sistema operativo
o Bibliotecas de funcionalidad NO es un lenguaje de programación
o (Base Class Library) NO es un entorno de desarrollo
o Lenguajes de programación NO es un servidor de aplicaciones
o Compiladores
13.
14. Cliente Servidor
Aplicación de
Escritorio *
Aplicación Web
Aplicación de
Consola *
Aplicación
.NET Compact Framework
Móvil
* Sólo si la aplicación es distribuida
15. VB C++ C# J# …
Common Language Specification
Visual Studio .NET
ASP.NET: Servicios Web Windows
y Web Forms Forms
ADO.NET: Datos y XML
Biblioteca de Clases Base
Common Language Runtime
20. Compilación
Código Compilador Código
Fuente Lenguaje MSIL
Metadata
Antes de la
instalación o
Ejecución cuando se ejecuta
por primera vez
Código JIT Compiler
Nativo
21. Código VB.NET C# C++.NET
Fuente
Compilador Compilador Compilador Componente
VB.NET C# C++ .NET No Manejado
Código Assembly Assembly Assembly
Código MSIL Código MSIL Código MSIL
Manejado
Common Language Runtime
Compilador JIT
Código Nativo
Sistema Operativo (Windows)
22.
23. Descripción de Tipos
Clases
MiBiblioteca.DLL Clases Base
Interfaces Implementadas
Metadata Atributos de las Clases
Métodos de las Clases
Recursos Manifiesto del Assembly
Nombre
Versión
Código Compilado
Cultura
MSIL
Otros Assemblies
Permisos de Seguridad
Tipos Externos
24. Visual Studio 6.0
Visual Basic
VBA
Visual FoxPro Visual Studio 2012
Visual Studio 2008
VBScript .NET Framework 4.5
.NET Framework 3.0 – 3.5
C++ Visual Studio .NET 2003 .NET Compact Framework
J++ .NET Framework 1.1
JScript .NET Compact Framework
ASP J#
2000 2001 2002 2003 2004 2005 2006 2008 2010 2012
Visual Studio .NET 2002 Visual Studio 2005
.NET Framework 1.0 .NET Framework 2.0
Visual Basic .NET .NET Compact Framework 2.0
C#
Visual Studio 2010
.NET Framework 4.0
25.
26. VB C# J# IronPhyton Ruby … … …
CLS y CTS
WF & WCF
ASP.NET WPF / XAML WCS Dynamic Data
Enhancements
Additional Entity
ADO.NET WCF LINQ
Framework
Enhancements
Windows Add-in
WF Framework
MVC Data Services
Forms
Biblioteca de Clases
Common Language Runtime (CLR)
Windows 7/8, Windows Vista, Windows XP, Windows Server 2008
Actualmente hay 3 versiones de la plataforma Microsoft .NET: La versión 1.0 : fue liberada a principios del año 2002, e incluía la versión 1.0 del .NET Framework, la versión 2002 de Visual Studio y varios lenguajes de programación nuevos compatibles con la plataforma (como C#.NET y Visual Basic.NET) La versión 1.1 : fue liberada en 2003, aproximadamente un año después que su predecesora. Esta versión introdujo el .NET Framework 1.1 junto con Visual Studio .NET 2003, la primer versión del .NET Compact Framework y un nuevo lenguaje de programación llamado J#.NET. La versión 2.0 : fue liberada a finales del año 2005, y es la primer gran renovación que sufrió la plataforma en su tiempo de vida. Con la idea de ser una “evolución” en lugar de una “revolución”, esta versión trajo consigo las versiones 2.0 del .NET Framework y el .NET Compact Framework, asi como también una nueva versión de Visual Studio. Ya existen planes en desarrollo para la próxima generación de la plataforma .NET, nombre código “Orcas”, que verá la luz aproximadamente al mismo tiempo que el sistema operativo Windows Vista.
Visual Studio .NET Integrated Development Environment Demo The Integrated Development Environment of Visual Studio .NET saves development time and energy with a vast number of features including its ability to support many design tools and languages and to allow designers to create their own tools: Easier to write code Easier to share knowledge Leverage existing skills Customize the environment Macros and more powerful add-ins The integrated help system supports Microsoft Help 2.0 as well as Dynamic Help. Microsoft Help 2.0 Improves filtering, F1, searching and performance Attributed, consistent topics Online Interface Developer community Headlines Search MSDN ®
La figura representa el modelo de compilación y ejecución de aplicaciones .NET, al cual muchas veces se denomina “de compilación diferida”, o “de compilación en dos etapas”. Esto es asi ya que el primer paso para poder ejecutar una aplicación dentro del CLR es compilar su código fuente para obtener un assembly con código MSIL. Este paso es realizado por cada uno de los compiladores de los distintos lenguajes de alto nivel soportados por .NET. Luego, el CLR se encarga de compilar el código MSIL a código nativo que hace uso específico de los servicios del sistema operativo y la plataforma de hardware subyacente. Todos los compiladores de los nuevos lenguajes .NET de Microsoft siguen este modelo de ejecución, con excepción de C++ .NET, que es el único lenguaje al que se le ha dejado la capacidad de emitir también código “no manejado”. Esto se debe a que ciertas aplicaciones, como los drivers de dispositivos, necesitan tener acceso a los recursos del sistema operativo a muy bajo nivel para lograr un rendimiento óptimo y mayor performance.
First, let’s drill into the Base Framework. The Base Framework is the most important part of the .NET Framework… primarily because it is the part that I worked on. But seriously, the Base Framework is super important because no matter what kind of application you are building are using you’ll end up needing to use this functionality. The system namespace contains all the base data types for the platform. Ints, floats, are defined here – arrays, strings, the root object and so forth. Within that, we have a whole slew of various base services that are consistently available in the base platform. Collections: growable arrays, hash table IO: file, streams NET: stuff that allows you to do tcpip, sockets
On top of the base classes we have the Data and Xml support. The ADO.NET supports both the tightly connected ADO style record set support that many applications use today as well as a new more loosely coupled model called that uses DataSets. This model allows for a more distributed nature style of programming that is becoming more common. We also provide the SQLTypes namespace that provide datatypes that map directly onto the types that you're accustomed to when you do database programming, say in TSQL. Nullable datatypes. Things that can basically have an int value, or be NULL. In the System.xml namespace we have all of the xml support. It truly is a world class set of functionality we’re providing here. There is of course a parser, and an xml writer – both of which are fully w3c compliant. There is a w3c dom implementation. On top of that there is an xslt for doing xsl transformations. We have an implementation of xpath that allows you to navigate data graphs in xml. And we have the serialization namespace that provides all of the core infrastructure for moving objects to xml representation and vice versa.
For your Smart client development we have Windows Forms. Windows Forms are a combination of the best from both Visual Basic and MFC. It gives you both a RAD compositional model, along with inheritance all with a completely object oriented framework. So you can build components through inheritance, then you can visually aggregate these components using a visual forms designer like you’re used to in VB. It provides a very rich component model that has a lot of design time support so you can fairly easily build new components that can have very rich and seamless integration into the platform and into any available visual design tools. Finally, in the system.drawing namespace you can find the implementation of GDI+. GDI+ is the next generation of the GDI 2D graphics support in the system. It has some really cool features for things such as alpha blending, anti-aliasing…and native support for jpeg, gif, tif and all of the web formats.
For development of applications and services that run on the server, we have the ASP.NET architecture. In System.Web.UI we have support for dynamically generating UI on the server and sending it down to clients. This is commonly in HTML, but it could also be in DHTML or even WAP for cell phones. The ASP.NET model allows you to build applications in much the same way you build client applications today: Just click and drag buttons and even higher level controls on a form. The infrastructure provides all the state management and other support. In System.Web.Services you’ll find the infrastructure for building great Xml based web services. With this support you just write classes and methods and the infrastructure handles turning the calls into SOAP. At the bottom you will find at the lower level things that are shared between web services and web ui: things like caching, configuration, security, state management and so forth.
El CLR administra dos segmentos de memoria, los cuales son utilizados de distinta forma a lo largo del ciclo de vida de una aplicación: El Stack, o Pila: es una sección de memoria que almacena los “tipos de valor” (Value Types), llamados asi porque tanto su referencia como su valor se encuentran en la misma posición de memoria. Ejemplos de tipos por valor en el CLR son los caracteres, los números enteros y los booleanos. A estos tipos de dato también se los conoce como “tipos primitivos”. El stack se comporta como una lista LIFO (Last In – First Out), donde se van apilando valores uno encima de otro y sólo se puede recuperar un valor desapilando los que tiene por encima. La memoria ocupada por los Value Types es liberada automáticamente por el CLR una vez que se finaliza el procedimiento o el bloque de código donde fueron declarados. El Heap, o “Montón”: es unas sección de memoria que almacena los “tipos de referencia” (Reference Types), llamados asi porque su almacenamiento se encuentra dividido En el stack se almacena una referencia al contenido de la variable En el heap se guarda el valor propiamente dicho de la variable Ejemplos de tipos por referencia son los Strings (cadenas de caracteres) y cualquier tipo de dato definido por el usuario (por ejemplo clases e interfaces que se creen a lo largo del desarrollo de una aplicación). La memoria ocupada por los Reference Types es liberada automáticamente por el Garbage Collector del CLR, de manera no determinística (esto quiere decir que no se puede tener conocimiento acerca de en qué momento se liberará la memoria). El CLR no puede ser invocado por los desarrolladores, y nuca debe hacerse ninguna presuposición acerca de cuándo y cómo se ejecutará.
Una aplicación .NET se compone, entonces, de uno o más assemblies. Otra de las características de los Assemblies es que no necesitan estar registrados en la Registry de Windows, como sus predecesores COM. De esta forma, instalar una aplicación .NET puede ser tan simple como copiar todos los assemblies necesarios a la computadora de destino, y basta con borrarlos a todos para tener una desinstalación limpia y completa. Dado que .NET no depende de la Registry, y que cada assembly contiene información acerca de su versión y las versiones de los componentes de que depende, múltiples versiones de assemblies pueden coexistir sin ningún problema en la misma computadora. Existen dos formas de que una aplicación pueda encontrar en tiempo de ejecución los assemblies de los que depende: Ubicarlos en el mismo directorio. Esta es la opción preferida si esos assemblies sólo serán utilizados por esa única aplicación. Ubicarlos en un repositorio centralizado de assemblies denominado Global Assembly Cache, en el cual se instalan todos los assemblies que serán utilizados por múltiples aplicaciones en la misma computadora. Para registrar un assembly en el GAC es necesario utilizar otra herramienta incluida en el SDK llamada gacutil.exe.
Un Assembly es la menor unidad de ejecución y distribución de una aplicación .NET. Los assemblies son reutilizables, versionables y autodescriptivos, ya que no sólo contienen el código MSIL que representa la lógica de la aplicación, sino que también incluyen información sobre si mismos y sobre todos los recursos externos de los que dependen para funcionar correctamente. A esta información se la denomina “MetaData” , y forma una parte integral de un assembly junto con el código MSIL ya que ambos no pueden estar separados. La MetaData se ubica en una sección especial del Assembly denominada “Manifest”, o “Manifiesto”, y es utilizada por el CLR a la hora de cargar y ejecutar el Assembly. La herramienta ildasm.exe (Intermediate Languaje Dissasembler, incluida en el .NET Framework SDK) puede utilizarse para inspeccionar la metadata de un assembly.
El .NET Framework debe estar instalado en cualquier dispositivo de hardware para que la ejecución de una aplicación .NET sea posible. En el caso de las aplicaciones de escritorio (también llamadas “De Formularios Windows”) y las aplicaciones de consola (aplicaciones cuya interfaz de usuario es una consola de comandos), el Framework debe estar presente del lado del cliente (computadora donde se ejecuta la parte de la aplicación que interactúa con el usuario), y en el servidor sólo en caso de que la aplicación sea distribuída y tenga parte de su funcionalidad centralizada en una única computadora. En el caso de las aplicaciones Web, el único requisito del lado del cliente es tener un navegador y una conexión de red al servidor, el cual debe tener instalado el .NET Framework. Veremos más sobre aplicaciones Web a lo largo del curso. Para las aplicaciones móviles, que se ejecutan sobre Windows Mobile en algún dispositivo tipo Pocket PC o SmartPhone, es necesario tener instalado el .NET Compact Framework en el dispositivo.