El sitio web es lo que implementa en un servidor web ASP.NET como IIS. Solo un montón de archivos y carpetas. No hay nada en un sitio web que lo vincule a Visual Studio (no hay archivo de proyecto). La generación de código y la compilación de páginas web (como .aspx, .ascx, .master) se realizan dinámicamente en tiempo de ejecución , y el marco detecta los cambios en estos archivos y los vuelve a compilar automáticamente. Puede poner el código que desea compartir entre páginas en la carpeta especial App_Code, o puede precompilarlo y colocar el ensamblaje en la carpeta Bin.
Aplicación web es un proyecto especial de Visual Studio. La principal diferencia con los sitios web es que cuando construye el proyecto, todos los archivos de código se compilan en un solo ensamblaje, que se coloca en el directorio bin. No despliega archivos de código en el servidor web. En lugar de tener una carpeta especial para archivos de código compartido, puede colocarlos en cualquier lugar, tal como lo haría en la biblioteca de la clase. Debido a que las aplicaciones web contienen archivos que no están destinados a ser implementados, como archivos de proyecto y código, hay un comando Publicar en Visual Studio para enviar un sitio web a una ubicación específica.
App_Code vs Bin
La implementación de archivos de código compartido generalmente es una mala idea, pero eso no significa que tenga que elegir la aplicación web. Puede tener un sitio web que haga referencia a un proyecto de biblioteca de clases que contenga todo el código del sitio web. Las aplicaciones web son solo una forma conveniente de hacerlo.
Código detrás
Este tema es específico de los archivos .aspx y .ascx. Este tema es cada vez menos relevante en los nuevos marcos de aplicaciones, como ASP.NET MVC y páginas web ASP.NET que no utilizan archivos de código subyacente.
Al compilar todos los archivos de código en un solo ensamblaje, incluidos los archivos de código subyacente de las páginas .aspx y los controles .ascx, en las aplicaciones web debe volver a compilar para cada pequeño cambio, y no puede realizar cambios en vivo. Esto puede ser un verdadero dolor durante el desarrollo, ya que debe seguir reconstruyéndolo para ver los cambios, mientras que con los sitios web los cambios son detectados por el tiempo de ejecución y las páginas / controles se vuelven a compilar automáticamente.
Hacer que el tiempo de ejecución administre el código detrás de los ensamblados es menos trabajo para usted, ya que no necesita preocuparse por dar nombres únicos a las páginas / controles u organizarlos en diferentes espacios de nombres.
No digo que la implementación de archivos de código sea siempre una buena idea (especialmente no en el caso de archivos de código compartido), pero los archivos de código subyacente solo deben contener código que realice tareas específicas de la interfaz de usuario, controladores de eventos de conexión, etc. Su aplicación debe ser en capas para que el código importante siempre termine en la carpeta Bin. Si ese es el caso, la implementación de archivos de código subyacente no debe considerarse dañina.
Otra limitación de las aplicaciones web es que solo puede usar el idioma del proyecto. En los sitios web puede tener algunas páginas en C #, algunas en VB, etc. No es necesario un soporte especial de Visual Studio. Esa es la belleza de la extensibilidad del proveedor de compilación.
Además, en las aplicaciones web no obtiene detección de errores en las páginas / controles, ya que el compilador solo compila su código detrás de las clases y no el código de marcado (en MVC puede solucionar esto usando la opción MvcBuildViews), que se compila en tiempo de ejecución.
Estudio visual
Debido a que las aplicaciones web son proyectos de Visual Studio, obtiene algunas características que no están disponibles en los sitios web. Por ejemplo, puede usar eventos de compilación para realizar una variedad de tareas, por ejemplo, minificar y / o combinar archivos Javascript.
Otra buena característica introducida en Visual Studio 2010 es la transformación Web.config .Esto tampoco está disponible en los sitios web. Ahora funciona con sitios web en VS 2013.
Crear una aplicación web es más rápido que crear un sitio web, especialmente para sitios grandes. Esto se debe principalmente a que las aplicaciones web no compilan el código de marcado. En MVC, si configura MvcBuildViews en verdadero, compila el código de marcado y obtiene detección de errores, lo cual es muy útil. El inconveniente es que cada vez que crea la solución, construye el sitio completo, lo que puede ser lento e ineficiente, especialmente si no está editando el sitio. Me encuentro activando y desactivando MvcBuildViews (que requiere la descarga de un proyecto). Por otro lado, con los Sitios web puede elegir si desea construir el sitio como parte de la solución o no. Si elige no hacerlo, la construcción de la solución es muy rápida, y siempre puede hacer clic en el nodo Sitio web y seleccionar Construir, si ha realizado cambios.
En un proyecto de aplicación web MVC, tiene comandos y cuadros de diálogo adicionales para tareas comunes, como 'Agregar vista', 'Ir a vista', 'Agregar controlador', etc. Estos no están disponibles en un sitio web MVC.
Si usa IIS Express como servidor de desarrollo, en los sitios web puede agregar directorios virtuales. Esta opción no está disponible en aplicaciones web.
NuGet Package Restore no funciona en sitios web, debe instalar manualmente los paquetes enumerados en packages.configRestaurar paquete ahora funciona con sitios web que comienzan NuGet 2.7