Hernaski Labs–

Me han preguntado varias veces cuál es la diferencia entre el WebSite y WebApplication en Visual Studio (en WebSite sólo está presente en las versiones 2005, 2008 y 2010). Si no está familiarizado con Visual Studio 2005/2008/2010 puede determinar que un WebApplication y WebSite son los mismos. Me gustaría contar una historia para explicar con más detalle.

En Visual 2002 y 2003 sólo había WebApplication y nunca habló en WebSite. Con la llegada de Visual Studio 2005 junto con el framework .net 2.0, vino la idea de que Microsoft no será la salvación del mundo de la colaboración de codificación: el WebSite.

¿Adivina lo que sucedió en el lanzamiento de Visual Studio 2005? El VS 2005 para proyectos web, sólo tenía la opción de WebSite y luego comenzaron las quejas de la comunidad asp.net. Las quejas se fortaleció, y Microsoft ha publicado el Service Pack 1 para Visual Studio 2005, la opción de WebApplication versiones muy similares de los años 2002 y 2003 (Recuerde: antes de Service Pack 1 fue lanzado una actualización específica para apoyar WebApplication, pero para los que siguem utilizando el VS 2005 sugiero la actualización a SP1 y demás actualizaciones de Microsoft Update).

WebSite en Visual Studio

Un WebSite es sólo un montón de archivos y subcarpetas de una carpeta en la que las clases son en el mismo namespace (namespace es similar al package en Java).

Algo interesante es que en el WebSite para depurar una aplicación, puede cambiar el código fuente de una clase (.cs o .vb) y continuar con la depuración obedeciendo a los cambios, algo no posible en el WebApplication.

Usted puede crear un WebSite utilizando el menú "File > New > Web Site...". Hay tres opciones sobre la ubicación de los archivos:

• File System: Le permite elegir una carpeta física.
• HTTP: Le permite elegir una carpeta virtual.
• FTP: Le permite elegir una dirección de FTP.

En cualquier caso por encima de ningún archivo de proyecto (.csproj o .vbproj) se crea automáticamente. No tienes una carpeta "bin" (excepto en Publish - la explicación abajo) y no un archivo único ensamblado (DLL).

La mayor diferencia entre WebSite y WebAplication está en "Publish" (Publicación/Deployment). El despliegue realizado el WebApplication es simplemente un archivo DLL para cada proyecto en una solución (.sln). El WebSite tiene 3 opciones de publicación que se describen a continuación:

1. Codigo fuente abierto: Este tipo de publicación que dejar todo el código fuente en el servidor de alojamiento web, incluyendo clases.
   Para hacer este tipo de publicación, sólo tienes que copiar todos los archivos de el WebSite en el servidor Web o utilizar la opción "Copy WebSite" de la siguiente manera en el icono:
   
    
2. El código fuente de las clases precompilados y las páginas (.aspx) con el código abierto
   Para publicar su sitio en el que sólo las clases deben ser precompilados, se debe dejar a su "Publish WebSite" como:
   
    
3. Todo website precompilado, incluidas las páginas (.aspx).
   Con esta opción, las páginas (ASPX) será con una sola línea de código: "This is a marker file generated by the precompilation tool, and should not be deleted!", es decir, el archivo es sólo para el servidor web sabe que la página existe, ya que todo el contenido será precompilados en la carpeta "bin".
   

Un consejo para los que utilizan los tipos de publicación 2 y 3: Utilice "Used fixed naming and single page assemblies". Esta opción establece que los nombres fijos para los archivos DLL. Si no utiliza esta opción, cada publicación va a cambiar los nombres de los archivos DLL y tiene archivos inútiles en la carpeta BIN (si usted elimina todo el sitio antes de publicarlo, no hay diferencia con esta opción).

Web Application en Visual Studio

Para crear un WebApplication: File > New > Project. Seleccionar Web y luego elegir el tipo de aplicación ASP.NET Web Application.

Un "Web Application Project" organiza los archivos de proyecto en un archivo llamado .csproj (para C#) o .vbproj (para VB.net). Estos archivos pueden ser de utilidad para aquellos que hacen la publicación automática junto con el Source Safe y la creación de "labels", por ejemplo.

Su único tipo de Build / Publicación genera un único archivo DLL (precompilación) que se encuentra en la carpeta bin del proyecto. Todo lo que se agrega a la WebSite participa en la publicación, en la Web Application puede insertar archivos de documentos, por ejemplo, y al establecer esto de no participar en la publicación. Para ello haga clic en el botón derecho del ratón sobre el archivo deseado en el proyecto y luego en "Properties", cambia la opción "Build Action" para "None".

WebApplication tiene sus clases organizadas por namespaces, puede crear clases en cualquier carpeta del proyecto, a diferencia de lo que sucede en WebSite donde usted puede entrar en las clases sólo en la carpeta App_Code.

Rendimiento

Sabemos que .NET tiene dos fases de la compilación: El primero al hacer el build que llamamos precompilación donde están los archivos precompilados DLL en un lenguaje común (lntermediate Language) para .NET Framework. La segunda es cuando se ejecuta la aplicación, está compilando binarios.

Debido a que la compilación de la aplicación se produce dos veces la velocidad en el WebSite está siendo cuestionado y dependerá del tipo de publicación (como se ve arriba) utilizado. La opción 3 de la publicación en el WebSite se considera el más rápida, pero las pruebas realizadas en el cliente (navegador) el resultado es insignificante en comparación con el WebApplication.

Comparación WebSite X Web Application

*debe crear manualmente con la opción "New Folder" y, si es necesario, cambie la propiedad "Build Action" clases dentro de App_Code a "Compile".

Conclusión

Uso de WebSite o Web Application puede aparecer, según los casos, indiferente, por lo que es necesario analizar su entorno, su manera de gestionar el código fuente, versiones y la generación de Build y publicaciones.

En mi experiencia con ASP.NET, me di cuenta de que el WebSite ya ha causado algunos problemas en la empresa donde trabajo para las referencias, versiones e implementaciones con Source Safe (a veces incluso la falta de conocimiento).

En un Web Application usted tiene mayor control sobre la configuración, sobre todo porque tenemos las propiedades del proyecto y las propiedades de cada archivo en Visual Studio. Debido a estas propiedades es mejor que se puede trabajar con objetos COM+ (por ejemplo, el establecimiento de Copy Local = true en la referencia). También puede generar build en el modo Debug o Release y su código fuente está organizado en namespaces.

Probablemente, si usted utiliza Visual Studio sólo en casa para proyectos personales pueden acabar gustando el WebSite, pero utilizando en proyectos de gran empresa en la generación de Build y publicación son parte clave del proceso, el Web Application termina siendo la mejor opción.

El navegador Internet Explorer 6 se está utilizando cada vez menos, pero aún así es la kriptonita de los promotores web debido a la falta de compatibilidad con los estándares de la Internet y el W3C.

IE6 es tan querido por los promotores web que hay varias campañas por la muerte de IE6, ya que el http://deathtoie6.com/ sitio, esto significa que muchos sitios insertar secuencias de comandos para no apoyar IE6 y recomendamos actualizar su navegador.

He trabajado mucho con IE6 y es difícil construir sitios con el estándar del W3C y también es compatible con Internet Explorer 6, pero tengo que admitir que hay formas (magia y sin sentido) para corregir los problemas con Internet Explorer 6 utilizando los estándares del W3C, pero también Admito que la paciencia tiene límites y, a menudo recurre a la famosa hacks / fija (algo así como "_padding" o incluso secuencias de comandos). Vea como un desarrollador puede obtener después de hacer la compatibilidad con IE6:

IE6: La Kryptonita de los Promotores Web
 

Promotor Web

IE6: La Cryptonita

Promotor Web Después de la compatibilidad con ie6

El sueño de todos los promotores web es que el cliente solicita un sitio y decir: "No quiero que los navegadores antiguos como ie6". Si esto ocurre, oigo una voz: "Oohhh". Por supuesto también tenemos que verificar el entorno del cliente, porque a veces no hay manera. Véase un ejemplo ficticio y no se puede confundir con la realidad :-)

Cliente: Queremos apoyar a ie6 a través del sitio. El sitio tiene un montón de JavaScript, elementos dinámicos, imágenes transparentes PNG, etc. ok?

Usted: [Enviar mensajes de odio al equipo de Microsoft ie6] Bueno, Internet Explorer 6 es realmente un navegador anticuado que tiene agujeros de seguridad, un motor de renderizado muy pobres y muy pocos usuarios por ahí con ella. Recomiendo no apoyar ie6, podemos poner un bar al usuario para que actualice su navegador, ¿qué te parece?

Cliente: ¿He mencionado que tenemos una industria de servicio de restaurante y una gran mayoría de sus terminales se sigue ejecutando ie6?

Usted: [Crear un virus para acabar con todos los equipos que tienen ie6] Ok, voy a tener que aumentar el tiempo de entrega.

Cliente: Desafortunadamente, no podemos posponer la fecha límite.

Usted: [Comprar cerveza o refrescos y aperitivos para el turno de la medianoche]

Es bueno mencionar que los gestores del proyecto en la venta de los sitios que recordar los problemas de estos y varios otros (no sólo en relación con IE6, pero el entorno Web como un todo), por lo que debe saber acerca de la tecnología web, o personas que puedan dar lugar ayudarle con el cliente.

No estoy tratando de no hacer lo que el cliente pide, pero hay que ver lo que realmente necesita y ofrecer mejores productos y las prácticas de mercado bien. La buena comunicación con el cliente sin duda ayudará mucho, pero se está moviendo a otros temas que vemos en otros artículos.

Abrazos! :-)

Hola a todos, pronto voy a publicar artículos y tutoriales sobre diversos temas relacionados con la creación de sitios web y, ocasionalmente, algún tema diferente.
Estoy trabajando para terminar el blog y comenzar a publicar.

¡Nos Vemos!