Site é o que você implanta em um servidor ASP.NET, como o IIS. Apenas um monte de arquivos e pastas. Não há nada em um site que o vincule ao Visual Studio (não há arquivo de projeto). A geração de código e compilação de páginas da Web (como .aspx, .ascx, .master) é feita dinamicamente no tempo de execução , e as alterações nesses arquivos são detectadas pela estrutura e recompiladas automaticamente. Você pode colocar o código que deseja compartilhar entre as páginas na pasta App_Code especial ou pré-compilar e colocar o assembly na pasta Bin.
Aplicativo Web é um projeto especial do Visual Studio. A principal diferença dos sites é que, quando você cria o projeto, todos os arquivos de código são compilados em um único assembly, que é colocado no diretório bin. Você não implanta arquivos de código no servidor da web. Em vez de ter uma pasta especial para arquivos de código compartilhado, você pode colocá-los em qualquer lugar, como faria na biblioteca de classes. Como os Aplicativos da Web contêm arquivos que não devem ser implantados, como arquivos de projeto e código, há um comando Publicar no Visual Studio para gerar um site para um local especificado.
App_Code vs Bin
A implantação de arquivos de código compartilhado geralmente é uma má ideia, mas isso não significa que você precise escolher Aplicativo da Web. Você pode ter um site que faça referência a um projeto de biblioteca de classes que contém todo o código do site. Aplicativos da Web é apenas uma maneira conveniente de fazer isso.
Código por trás
Este tópico é específico para arquivos .aspx e .ascx. Este tópico é cada vez menos relevante em novas estruturas de aplicativos, como o ASP.NET MVC e o ASP.NET Web Pages, que não usam arquivos atrás do código.
Por ter todos os arquivos de código compilado em um único assembly, incluindo CodeBehind arquivos de páginas.ASPX e controles .ascx, em aplicações Web que você tem que re-build para cada pequena mudança, e você não pode fazer alterações ao vivo. Isso pode ser uma verdadeira dor de cabeça durante o desenvolvimento, já que você precisa continuar reconstruindo para ver as alterações, enquanto nos Sites as alterações são detectadas pelo tempo de execução e as páginas / controles são recompilados automaticamente.
Ter o tempo de execução gerenciando o código atrás dos assemblies é menos trabalhoso para você, pois você não precisa se preocupar em dar nomes / páginas únicos aos controles / ou organizá-los em diferentes espaços de nomes.
Não estou dizendo que implantar arquivos de código é sempre uma boa ideia (especialmente não no caso de arquivos de código compartilhados), mas os arquivos por trás do código devem conter apenas código que execute tarefas específicas da interface do usuário, manipuladores de eventos de conexão etc. Seu aplicativo deve ser em camadas para que o código importante sempre acabe na pasta Bin. Se for esse o caso, a implantação de arquivos por trás dos códigos não deve ser considerada prejudicial.
Outra limitação dos aplicativos da Web é que você só pode usar o idioma do projeto. Nos sites, você pode ter algumas páginas em C #, outras em VB, etc. Não há necessidade de suporte especial ao Visual Studio. Essa é a beleza da extensibilidade do provedor de compilação.
Além disso, em Aplicativos Web, você não obtém detecção de erros em páginas / controles, pois o compilador compila apenas o código atrás das classes e não o código de marcação (no MVC, você pode corrigir isso usando a opção MvcBuildViews), que é compilada em tempo de execução.
Estúdio visual
Como os Aplicativos da Web são projetos do Visual Studio, você obtém alguns recursos não disponíveis nos Sites. Por exemplo, você pode usar eventos de construção para executar uma variedade de tarefas, por exemplo, minificar e / ou combinar arquivos Javascript.
Outro recurso interessante introduzido no Visual Studio 2010 é a transformação Web.config .Isso também não está disponível em sites. Agora funciona com sites no VS 2013.
Criar um aplicativo da Web é mais rápido do que criar um site, especialmente para sites grandes. Isso ocorre principalmente porque os Aplicativos da Web não compilam o código de marcação. No MVC, se você definir MvcBuildViews como true, ele compila o código de marcação e você obtém a detecção de erros, o que é muito útil. O lado negativo é que, toda vez que você cria a solução, ele cria o site completo, o que pode ser lento e ineficiente, especialmente se você não estiver editando o site. Eu me pego ativando e desativando o MvcBuildViews (o que requer uma descarga do projeto). Por outro lado, com os sites, você pode escolher se deseja criar o site como parte da solução ou não. Se você optar por não fazê-lo, a criação da solução será muito rápida e você sempre poderá clicar no nó Site e selecionar Compilar, se tiver feito alterações.
Em um projeto de aplicativo da Web MVC, você possui comandos e caixas de diálogo extras para tarefas comuns, como 'Adicionar exibição', 'Ir para exibição', 'Adicionar controlador', etc. Eles não estão disponíveis em um site da MVC.
Se você usa o IIS Express como servidor de desenvolvimento, em Sites da Web, você pode adicionar diretórios virtuais. Esta opção não está disponível em Aplicativos da Web.
A Restauração de Pacotes do NuGet não funciona em sites, é necessário instalar manualmente os pacotes listados em packages.configA Restauração de Pacotes agora funciona com sites que iniciam o NuGet 2.7