Nuevos proyectos Web en Visual Studio 2005 Service Pack 1

martes, 30 de enero de 2007

En este mes Microsoft ha publicado el Service Pack 1 de Visual Studio.

Además de una larga lista de correciones menores al producto (ver la lista completa aquí) en el mismo se incorpora una alternativa interesante para la construcción de sitios web. La misma, que inicialmente se había publicado como un un add-in opcional de Visual Studio 2005, ahora se incorpora en las características base de la herramienta.


Web Application Projects

Es la posibilidad de definir una aplicación web mediante un proyecto (.csproj o .vbproj), tal como era habitual en las versiones previas del framework .NET. Puede leerse aquí una introducción al tema.

Esto se agrega como alternativa al manejo ya conocido en ASP.NET 2.0, de crear el sitio directamente basado en el sistema de archivos, sin un proyecto que enumere explícitamente sus componentes. Naturalmente este mecanismo sigue estando disponible luego de aplicar el Service Pack.

Esta diferencia aparentemente "menor" entre los dos tipos de proyecto tiene importantes consecuencias sobre el modelo de compilación, el ciclo de desarrollo / modificación / prueba de la aplicación, y la forma en que el sitio se incorpora a Visual Source Safe u otros sistemas de control de código integrados con la IDE de Visual Studio.



Cúando usar cuál?

Hay ventajas y desventajas de uno y otro modelo en diferentes escenarios, un análisis comparativo puede consultarse en esta sección del documento citado previamente.

En mi opinión -y esto es un terreno abierto a la discusión-, el modelo ahora disponible, basado en proyectos (en el cual hay una muy rápida reconstrucción del proyecto antes de cada prueba), es más adecuado para sitios chicos y medianos, y lo utilizo como "modelo por defecto" a menos que se de alguna de las siguientes condiciones.


  • Que la magnitud del sitio (cantidad de páginas) haga prohibitivo el tiempo de build -aún cuando en los nuevos proyectos web este tiempo es asombrosamente menor que en los sitios sin proyecto.
  • Que las necesidades de distribución -por ej. el acceso remoto a un hosting externo- requieran sí o sí actualizar páginas individuales sin redistribuir el sitio completo.

Y definitivamente trato de usar los nuevos proyectos web cuando se cumple alguna de estas condiciones

  • Necesidad frecuente de rebuild y validación del sitio completo ante los cambios en otros proyectos (librerias de clases base, proyectos de "back end", etc)
  • Participación simultánea de varios desarrolladores en un mismo proyecto web, u otras condiciones que hagan complejo entender cuándo puede reejecutarse la página modificada sin reconstruir el sitio y cuando es preferible el "rebuild" antes de probar.

Conversion de Web sites existentes a Web Application Projects

Esta tarea no es trivial, ya que además de ser necesario reconstruir la información del proyecto y sus referencias, cada página aspx y su código deben ser migradas al modelo de clase parciales con "code behind" generado por la herramienta de diseño.

La parte más tediosa del proceso es facilitada por un wizard, y algunos ajustes deben realizarse manualmente. Una guía detallada del proceso de conversión puede leerse aquí.



Cómo crear y configurar un proyecto de aplicación web

Como punto de partida, recordar que para crear una aplicacion web basada en proyecto, no debe usarse la opción "agregar nuevo sitio web" sino "agregar nuevo proyecto" y allí seleccionar como tipo de proyecto "aplicacion web ASP.NET".

Tal como en los web sites de ASP.NET 2.0, los proyectos web pueden ejecutarse mediante el host propio de Visual Studio -basado en el sistema de archivos- o en Internet Information Server. Esa configuración se define en una nueva solapa "Web" de las propiedades del proyecto.

Para terminar: en mi opinion, independientemente de la discusión de cuándo se justifica convertir un "web site" existente a un "web application project", definitivamente creo que vale la pena, a la hora de crear una nueva aplicación, conocer y poder optar entre ambos modelos.
Leer más...

Qué es .NET 3.0 y qué no es

viernes, 26 de enero de 2007

Con la reciente liberación de la versión final de .NET 3.0, son frecuentes las preguntas acerca de qué es, qué incluye, y otras dudas como "cuál es su compatibilidad con la versión 2.0".

Para clarificar el panorama, presento algunas de mis conclusiones sobre el tema agrupadas en dos afirmaciones:

.NET 3.0 es un avance importantísimo en la plataforma .NET

.NET 3.0 no es una nueva version del runtime .NET, no, no no

.NET 3.0 es un avance importantísimo en la plataforma .NET

Después de mucha investigación, feedback de los desarrolladores, y participación de la comunidad, Microsoft completó e hizo público el paquete de nuevas tecnologías que, luego de pasar por diversos alias durante su gestación (WinFx, Indigo, Avalon, Workflow Foundation, etc) finalmente salió a la luz con el nombre .NET 3.0.

Este conjunto de tecnologías lleva a una nueva dimensión las aplicaciones en código manejado (.NET) al abrir posibilidades inéditas en la experiencia de usuario, comunicación entre aplicaciones, automatización de procesos de negocios, y otros avances. Estas nuevas funcionalidades se distribuyen entre los componentes centrales de .NET 3.0:

  • Windows Presentation Foundation (ex "Avalon")
  • Windows Communication Foundation (ex "Indigo")
  • Windows Workflow Foundation
  • Windows CardSpace

Físicamente (en términos binarios) estas funcionalidades están contenidas en varios assemblies (.dll) que se adicionan a los de .NET 2.0 luego de un proceso de instalación del runtime 3.0.

Para una una idea más completa del alcance de estas tecnologías visite el portal de .NET 3.0 para desarrolladores en http://www.netfx3.com/.

.NET 3.0 no es una nueva version del runtime .NET, no, no, no


Algunos elementos de la presentación comercial de .NET 3.0 llevan a entenderlo como "la versión del runtime .NET que sucede a la versión 2.0". Esta confusión en parte se origina por:

  • el nombre del producto. En la sucesión lógica de .NET 1.0, .NET 1.1, .NET 2.0 que eran versiones sucesivas del entorno de ejecución de .NET con su propia version de bibliotecas de clases, etc., es fácil caer en el error de pensar que .NET 3.0 es una nueva versión del tipo de las anteriores.
  • la carpeta de instalación. Dentro de la carpeta Windows\Microsoft.NET\Framework, la versión 3.0 aparece como una nueva subcarpeta a la par de la v2.0.50727

Sin embargo, un análisis más cuidadoso de la implementación de .NET 3.0 pone de manifiesto que este conjunto de nuevas funcionalidades se montan sobre el mismo runtime de .NET 2.0:

  • si en una aplicación nueva realizada con .NET 3.0 (por ejemplo un aplicación de Windows Presentation Foundation) se pregunta para cualquier clase del sistema el numero de version del runtime, se obtiene el valor "2.0.50727"
  • la carpeta v3.0 que se crea en Microsoft.NET\Microsoft sólo contiene los assemblies adicionados y requiere la carpeta v2.0.50727 para funcionar (de hecho la instalación del runtime "3.0" instala ambas) .

Este hecho despeja muchas de las dudas respecto a la coexistencia de aplicaciones 3.0 y 2.0: la compatibilidad es completa porque se trata de la misma versión del runtime.




Leer más...