Site ASP.NET ou Aplicativo ASP.NET?


848

Quando inicio um novo projeto do ASP.NET no Visual Studio, posso criar um Aplicativo Web do ASP.NET ou criar um Site ASP.NET.

Qual é a diferença entre o Aplicativo Web ASP.NET e o Site ASP.NET? Por que eu escolheria um sobre o outro?

A resposta é diferente com base na versão do Visual Studio que estou usando?


6
A comparação e explicação completa e mais recente (para 4,5) é encontrado aqui no MSDN: Web Application Projects versus projetos de sites da Web em Visual Studio
Gustav

Respostas:


556

Local na rede Internet:

O projeto do site é compilado em tempo real. Você acaba com muito mais arquivos DLL, o que pode ser um problema. Também apresenta problemas quando você tem páginas ou controles em um diretório que precisam fazer referência a páginas e controles em outro diretório, pois o outro diretório ainda não pode ser compilado no código. Outro problema pode estar na publicação.

Se não for solicitado ao Visual Studio que reutilize os mesmos nomes constantemente, ele criará novos nomes para os arquivos DLL gerados pelas páginas o tempo todo. Isso pode levar a várias cópias fechadas de arquivos DLL que contêm o mesmo nome de classe, o que gerará muitos erros. O projeto do site foi apresentado com o Visual Studio 2005, mas acabou não sendo popular.

Aplicação Web:

O Projeto de Aplicativo da Web foi criado como um suplemento e agora existe como parte do SP 1 para o Visual Studio 2005. As principais diferenças são que o Projeto de Aplicativo da Web foi projetado para funcionar de maneira semelhante aos projetos da Web fornecidos com o Visual Studio 2003. compile o aplicativo em um único arquivo DLL no momento da criação. Para atualizar o projeto, ele deve ser recompilado e o arquivo DLL publicado para que as alterações ocorram.

Outro recurso interessante do projeto de aplicativo da Web é que é muito mais fácil excluir arquivos da visualização do projeto. No projeto Site, cada arquivo excluído é renomeado com uma palavra-chave excluída no nome do arquivo. No Projeto de Aplicativo da Web, o projeto apenas monitora quais arquivos devem ser incluídos / excluídos da visualização do projeto sem renomeá-los, tornando as coisas muito mais organizadas.

Referência

O artigo ASP.NET 2.0 - Projeto Web Site x Aplicativo Web também fornece motivos para usar um e não o outro. Aqui está um trecho disso:

  • Você precisa migrar grandes aplicativos do Visual Studio .NET 2003 para o VS 2005? use o projeto de aplicativo da Web.
  • Deseja abrir e editar qualquer diretório como um projeto da Web sem criar um arquivo de projeto? use o projeto do site.
  • Você precisa adicionar etapas de pré-compilação e pós-compilação durante a compilação? use o projeto de aplicativo da Web.
  • Você precisa criar um aplicativo Web usando vários projetos da Web? use o projeto de aplicativo da Web.
  • Deseja gerar uma montagem para cada página? use o projeto do site.
  • Você prefere compilação dinâmica e trabalho em páginas sem criar um site inteiro em cada exibição de página? use o projeto do site.
  • Você prefere o modelo de código de página única ao modelo de code-behind? use o projeto do site.

Projetos de aplicativos da Web versus projetos de sites da Web (MSDN) explica as diferenças entre o site e os projetos de aplicativos da Web. Além disso, ele discute a configuração a ser feita no Visual Studio.


5
Você ainda pode compilar todo o site em uma DLL com o site baseado em arquivo.
dtc 31/12/08

31
Do jeito que eu penso nisso. Se você estiver programando um aplicativo que usa HTML como interface do usuário, use o Aplicativo da Web. Se você tem um site que precisa de um pouco de Asp.net em algumas páginas, use o Web Site Project.
Ian Ringrose

35
Na verdade, os projetos de aplicativos da Web eram precisamente o tipo de projeto original do ASP.NET. Eles não são "parecidos" com os projetos que tivemos no Visual Studio 2003. Eles não foram criados como um suplemento. O Visual Studio 2005 SP1 simplesmente restaurou o Visual Studio 2005 RTM removido por engano.
John Saunders

1
Você pode usar a saída WebApplication em um projeto WebDeployment. Você não pode usar a saída do Site em um projeto do WebDeployment. Se você deseja criar um projeto de implantação, siga o WebApplication. Mas, para o desenvolvimento, o WebSite é mais conveniente. No entanto, nem sempre a conversão é sem problemas; portanto, comece com o WebApplication imediatamente.
27510 Stefan Steiger #

8
@xarzu: Os "projetos" do site não têm arquivo .csproj ou .vbproj. Eles não são realmente projetos - são apenas pastas cheias de arquivos.
John Saunders

171

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


43
Como os programadores escrevem o aplicativo, ele é criado. A equipe de teste testa o aplicativo no sistema de teste. Em seguida, o cliente instala os aplicativos. Que ÚLTIMO acho que você quer é alguém fazendo mudanças ao vivo!
31810 Ian Ringrose

12
Para mim, a melhor opção é escolher, em sites que você sempre pode herdar de uma classe base pré-compilada, se quiser. Existem muitas linguagens / estruturas (por exemplo, PHP) em que as pessoas estão acostumadas à idéia de implantar o código-fonte. Isso não significa que essas não sejam aplicações 'sérias'.
Max Toro

6
"Na verdade, você não gerencia essas DLLs, [...] nem precisa saber que elas existem. Não é um problema." - Até que a estrutura fique confusa, não limpe as versões antigas corretamente e comece a lançar exceções de compilação com nomes conflitantes em todo o site ... Você pode adicionar a detecção de erros da marcação através do uso de um projeto WebDeployment. Também não tenho certeza do seu último argumento "com sites que você pode usar o IIS como servidor", você também pode fazer isso com um aplicativo da Web - e eu tenho projetos como esse em que o projeto faz parte de um aplicativo da Web maior.
Zhaph - Ben Duguid 24/10/09

3
A implantação de um site nem sempre precisa ser em um servidor ativo. As iterações de desenvolvimento devem, em um mundo perfeito, ser testadas em um espelho do ambiente ao vivo. Com a incapacidade dos Aplicativos Web de fazer alterações rápidas no código de um site em execução no servidor IIS de Desenvolvimento (ou seja, não em execução na instância local do VS), é muito difícil testar pequenas soluções rápidas. Isso acontece o tempo todo em sistemas em que você não pode replicar as mesmas condições em sua máquina local.
NikoRoberts

4
"Isso pode ser uma dor real durante o desenvolvimento, já que você precisa continuar se reconstruindo para ver as mudanças" ... lembre-se de que seria um projeto MASSIVO ou um computador MUITO VELHO para que fosse uma tarefa difícil. uma reconstrução nos dias de hoje.
Darren

75

Site = use quando o site é criado por designers gráficos e os programadores editam apenas uma ou duas páginas

Aplicativo da Web = use quando o aplicativo for criado por programadores e os designers gráficos editam apenas uma ou duas imagens / paginadas.

Os sites podem ser trabalhados com o uso de qualquer ferramenta HTML sem a necessidade de ter o studio do desenvolvedor, pois os arquivos do projeto não precisam ser atualizados etc. Os aplicativos da web são melhores quando a equipe está usando o studio do desenvolvedor e há um alto conteúdo de código.

(Alguns erros de codificação são encontrados nos Aplicativos da Web em tempo de compilação e não são encontrados nos Sites da Web até o tempo de execução.)

Aviso: escrevi esta resposta há muitos anos e não utilizo o Asp.net desde então. Espero que as coisas tenham mudado.


40

A menos que você tenha uma necessidade específica de um projeto compilado dinamicamente, não use um projeto de site .

Por quê? Como o projeto do site o levará a uma parede ao tentar mudar ou entender seu projeto. Os recursos de localização de digitação estática (por exemplo, encontrar usos, refatorar) no Visual Studio levarão uma eternidade em qualquer projeto de tamanho razoável. Para obter mais informações, consulte a pergunta Estouro de pilha lenta "Localizar todas as referências" no Visual Studio .

Realmente não consigo entender por que eles lançaram aplicativos da Web no Visual Studio 2005 para o tipo de projeto de site de carbúnculo que causa dor, sanidade e produtividade.


30

Há um artigo no MSDN que descreve as diferenças:

Comparando projetos de sites e projetos de aplicativos da Web

BTW: existem algumas perguntas semelhantes sobre esse tópico, por exemplo:


Eu acho que a resposta sobre Devo usar CodeFile ou codebehind na marcação é ido com a resposta que foi excluído por SO ...
frenchone

Portanto, para aqueles que querem saber: aplicação web = solução bem estruturada = codebehind na marcação website VS = monte de arquivos = CodeFile na marcação
frenchone

22

Isso pode parecer um pouco óbvio, mas acho que é algo que é mal interpretado porque o Visual Studio 2005 é enviado apenas com o site originalmente. Se o seu projeto trata de um site que é bastante limitado e não possui muita separação lógica ou física, o site está correto. No entanto, se for realmente um aplicativo da Web com módulos diferentes, onde muitos usuários adicionam e atualizam dados, você estará melhor com o aplicativo da Web.

O maior profissional do modelo de site é que tudo na app_codeseção é compilado dinamicamente. Você pode fazer atualizações de arquivos C # sem reimplementar completamente. No entanto, isso ocorre em um grande sacrifício. Muitas coisas acontecem debaixo das cobertas que são difíceis de controlar. Os espaços para nome são difíceis de controlar e o uso específico da DLL sai da janela por padrão para qualquer item abaixo, app_codepois tudo é compilado dinamicamente.

O modelo de aplicativo da web não possui compilação dinâmica, mas você obtém controle sobre as coisas que mencionei.

Se você estiver desenvolvendo n camadas, recomendo o modelo de aplicativo da web. Se você estiver criando um site limitado ou uma implementação rápida e suja, o modelo do site pode ter vantagens.

Uma análise mais detalhada pode ser encontrada em:


3
> O maior profissional do modelo de site é que qualquer coisa na seção app_code é compilada dinamicamente. Isso também tem uma grande desvantagem. Meu site está hospedado no webhost4life, que é barato, mas rico em recursos. A desvantagem é que eles reciclam o processo de trabalho com muita frequência (15 minutos?), O que significa que o próximo usuário tem uma saída de primeira página muito lenta à medida que o aplicativo é recompilado.
22630 Rob Nicholson

19

No livro do exame 70-515 do kit de treinamento individual do MCTS:

Com aplicativo da web (projeto),

  1. Você pode criar um aplicativo MVC.
  2. O Visual Studio armazena a lista de arquivos em um arquivo de projeto (.csproj ou .vbproj), em vez de depender da estrutura da pasta.
  3. Você não pode misturar Visual Basic e C #.
  4. Você não pode editar o código sem interromper uma sessão de depuração.
  5. Você pode estabelecer dependências entre vários projetos da web.
  6. Você deve compilar o aplicativo antes da implantação, o que impede que você teste uma página se outra página não for compilada.
  7. Você não precisa armazenar o código fonte no servidor.
  8. Você pode controlar o nome e a versão da montagem.
  9. Você não pode editar arquivos individuais após a implantação sem recompilar.

# 4 está errado. "Editar e continuar" pode ser ativado, com algumas restrições. Talvez isso fosse verdade em 2011. O nº 9 deve dizer "você não pode editar arquivos de código fonte individuais sem recompilar". Você pode editar .aspx, .js, .css, etc. sem recompilar.
John Saunders

# 4 tem outro ângulo. Se você abrir um site usando Arquivo> Abrir> Site e navegue até a pasta do sistema de arquivos do site, em vez de abrir o site selecionando a solução na janela inicial, poderá editar os módulos de classe e os códigos de código (pelo menos em vb.net ) sem parar a depuração. Você não verá as alterações até a reconstrução; no entanto, geralmente é útil poder observar o comportamento da página enquanto você modifica o código. A desvantagem é que você perde tudo o que entra na solução: pontos de interrupção, arquivos abertos, favoritos etc. E às vezes é necessário excluir os arquivos sln / sou.
wayfarer

16

Depende do que você está desenvolvendo.

Um site orientado a conteúdo terá seu conteúdo alterado frequentemente e um site é melhor para isso.

Um aplicativo tende a ter seus dados armazenados em um banco de dados e suas páginas e códigos raramente mudam. Nesse caso, é melhor ter um aplicativo da Web em que a implantação de montagens seja muito mais controlada e tenha melhor suporte para testes de unidade.


16

Compilation Em primeiro lugar, há uma diferença na compilação. O site não é pré-compilado no servidor, é compilado em arquivo. Pode ser uma vantagem, porque quando você deseja alterar algo em seu site, basta baixar um arquivo específico do servidor, alterá-lo e fazer upload desse arquivo de volta ao servidor e tudo funcionaria bem. No aplicativo da Web, você não pode fazer isso porque tudo é pré-compilado e você acaba com apenas uma dll. Quando você altera algo em um arquivo do seu projeto, precisa recompilar tudo novamente. Portanto, se você gostaria de ter a possibilidade de alterar alguns arquivos no servidor, o site é a melhor solução para você. Também permite que muitos desenvolvedores trabalhem em um site. Por outro lado, se você não deseja que seu código esteja disponível no servidor, você deve escolher Aplicativo da Web.

Project structure Há também uma diferença na estrutura do projeto. No aplicativo da Web, você tem um arquivo de projeto como o aplicativo normal. No site, não há arquivo de projeto tradicional, tudo o que você tem é arquivo de solução. Todas as referências e configurações são armazenadas no arquivo web.config. @Page directive Há um atributo diferente na diretiva @Page para o arquivo que contém a classe associada a esta página. No Aplicativo da Web, é padrão "CodeBehind", no Site você usa "CodeFile". Você pode ver isso nos exemplos abaixo:

Aplicação Web:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Local na rede Internet:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Namespaces - No exemplo acima, você também pode ver outra diferença - como os namespaces são criados. No aplicativo Web, o espaço para nome é simplesmente um nome do projeto. No site, existe o ASP de namespace padrão para páginas compiladas dinamicamente.

Editar e continuar - No aplicativo Web, a opção Editar e continuar está disponível (para ativá-lo, você precisa ir ao Menu Ferramentas, clique em Opções e, em seguida, encontre Editar e continuar na depuração). Esse recurso não está funcionando no Web Site.ASP.NET MVCISe você deseja desenvolver aplicativos da Web usando

ASP.NET MVC (Model View Controller) a opção melhor e padrão é Aplicativo da Web. Embora seja possível usar o MVC no site, isso não é recomendado.

Resumo - A diferença mais importante entre o aplicativo ASP.NET e o site é a compilação. Portanto, se você trabalha em um projeto maior, no qual algumas pessoas podem modificá-lo, é melhor usar o site. Mas se você estiver fazendo um projeto menor, também poderá usar o Aplicativo Web.


Em um projeto grande em que mais de uma pessoa o está alterando, você usa o controle de origem, portanto, este não é um motivo para usar os "projetos" do site.
John Saunders

+1 para distinção entre codebehind (webapp) x codefile (website) na diretiva de página. Essa é uma precisão que falta na resposta selecionada.
frenchone

11

Sim, o aplicativo da Web é muito melhor do que os sites, porque os aplicativos da Web nos dão liberdade:

  1. Ter vários projetos sob um guarda-chuva e estabelecer dependências entre eles. Por exemplo, para PCS, podemos seguir dentro de aplicativos da Web -

    • Portais da Web
    • Controlador de notificação (para enviar email)
    • Camada de negócios
    • Camada de acesso a dados
    • Gerenciador de exceção
    • Utilitário do servidor
    • Serviços WCF (comum para todas as plataformas)
    • Item da lista
  2. Para executar testes de unidade no código que está nos arquivos de classe associados às páginas do ASP.NET

  3. Para se referir às classes associadas a páginas e controles de usuário de classes independentes
  4. Para criar uma única montagem para o site inteiro
  5. Controle sobre o nome do assembly e o número da versão que são gerados para o site
  6. Para evitar colocar o código-fonte em um servidor de produção. (Você pode evitar a implantação do código fonte no servidor IIS. Em alguns cenários, como ambientes de hospedagem compartilhada, você pode estar preocupado com o acesso não autorizado ao código fonte no servidor IIS. (Para um projeto de site, você pode evitar esse risco: pré-compilando em um computador de desenvolvimento e implantando os assemblies gerados em vez do código-fonte. No entanto, nesse caso, você perde alguns dos benefícios de atualizações fáceis do site.)
  7. Problema de desempenho com o site (A primeira solicitação ao site pode exigir a compilação do site, o que pode resultar em um atraso. E se o site estiver em execução em um servidor IIS com pouca memória, incluindo todo o site em um uma montagem única pode usar mais memória do que seria necessário para várias montagens.)

11

Uma das principais diferenças é que os sites compilam dinamicamente e criam assemblies dinâmicos. Os aplicativos da Web são compilados em um assembly grande.

A distinção entre os dois foi eliminada no Visual Studio 2008.


4
"A distinção entre os 2 foi eliminada no vs2008" - não sei o que você quer dizer com isso - eles ainda são tipos de projetos distintos no VS2008, se comportam de maneira diferente e são criados por meio de diferentes opções de menu - no entanto, pelo menos, ambos estão disponíveis por padrão no VS2008.
Zhaph - Ben Duguid 24/01/09

9

Os aplicativos geralmente são compilados antes da implantação, onde o site faz uso do diretório app_code. Quando algo muda na pasta de código do aplicativo, o servidor recompila o código. Isso significa que você pode adicionar / alterar o código em um site em tempo real.

A vantagem de um aplicativo é que não há recompilação e, portanto, os tempos de inicialização iniciais serão mais rápidos.


Isso é parcialmente verdade, você pode pré-
compilar as

8

Eu recomendo que você assista ao vídeo Projetos de aplicativos da Web e projetos de implantação da Web no site ASP.NET, que explica a diferença em grandes detalhes; foi bastante útil para mim.

A propósito, não se confunda com o título, grande parte do vídeo explica a diferença entre projetos de sites e aplicativos da Web e por que a Microsoft reintroduziu os projetos de aplicativos da Web no Visual studio 2005 (como você provavelmente já sabe, ele originalmente enviados apenas com projetos de sites, os projetos de aplicativos da web foram adicionados no SP1). Um ótimo vídeo que eu recomendo para quem quer saber a diferença.



7

Um "site" tem seu código em um diretório App_Code especial e é compilado em várias DLLs (assemblies) em tempo de execução. Um "aplicativo da web" é pré-compilado em uma única DLL.


5

Site e site do Project >> são dois métodos diferentes de criar aplicativos ASP.NET usando o visual studio. Um é sem projeto e o outro é o ambiente do projeto. As diferenças são tão

  1. O arquivo da solução é armazenado no mesmo diretório que o diretório raiz no ambiente do projeto.
  2. Precisa remover os arquivos de solução e projeto antes de implantar no ambiente do projeto.
  3. O diretório raiz completo é implantado no ambiente sem projeto.

não há muita diferença básica no uso de qualquer uma das abordagens. Mas se você estiver criando um site que levará mais tempo, opte pelo ambiente do projeto.


1
O arquivo de solução não precisa estar na mesma pasta. Além disso, o mecanismo de publicação padrão remove todos os artefatos que não deveriam estar no site de destino, por exemplo, os arquivos por trás de códigos não são implementados.
John Saunders

5

Modelo de projeto de Aplicativo da Web

  • Fornece a mesma semântica de projetos da Web que os projetos da Web do Visual Studio .NET. Possui um arquivo de projeto (estrutura baseada em arquivos de projeto). Modelo de compilação - todo o código do projeto é compilado em um único assembly. Oferece suporte ao IIS e ao ASP.NET Development Server interno. Oferece suporte a todos os recursos do Visual Studio 2005 (refatoração, genéricos, etc.) e do ASP.NET (páginas mestras, associação e login, navegação no site, temas etc.). O uso do FPSE (FrontPage Server Extensions) não é mais um requisito.

Modelo de projeto do site

  • Nenhum arquivo de projeto (com base no sistema de arquivos).
  • Novo modelo de compilação.
  • Compilação dinâmica e trabalho em páginas sem criar site inteiro em cada exibição de página.
  • Oferece suporte ao IIS e ao ASP.NET Development Server interno.
  • Cada página tem sua própria montagem.
  • Modelo de código diferente.

5

É sempre depende da exigência do seu cliente. O ASP.NET inclui apenas recursos flexíveis que o usuário precisa para segurança e manutenção fácil do seu aplicativo.

Você pode pensar em um aplicativo Web como um arquivo binário executado dentro da estrutura do ASP.NET. E sites como uma página estática na qual você pode revisar e implantar facilmente o código-fonte.

Mas as vantagens e desvantagens dessas duas tecnologias ASP.NET são boas.


4

Sites - Nenhum arquivo de solução será criado. Se queremos criar sites, não há necessidade de visual studio.

Aplicativo da Web - Um arquivo de solução será criado. Se queremos criar aplicativos da web deve precisar do visual studio. Ele criará um único .dllarquivo na pasta bin.


2
-1 Você realmente tem um arquivo de solução se criar um projeto de site via visual studio. Você não tem um arquivo de projeto.
Darren

+1 certeza, você pode criar um arquivo de solução, mas este arquivo é quase vazio por isso é apenas um aborrecimento (VS pergunta onde deseja salvar o arquivo na saída) e não algo útil
frenchone

3

Nos Projetos de aplicativos da Web, o Visual Studio precisa de arquivos .designer adicionais para páginas e controles do usuário. Os projetos de sites não exigem essa sobrecarga. A marcação em si é interpretada como o design.


3

Site: Ele gera a pasta app_code automaticamente e se você a publicar no servidor e depois disso, se você fizer algumas alterações em um arquivo ou página em particular, não precisará compilar todos os arquivos.

Aplicativo Web Ele gera o arquivo de soluções automaticamente, que o site não gera e, se você mudar em um arquivo, precisará compilar o projeto completo para refletir suas alterações.


"Compilando projeto completo" não significa compilar todos os arquivos no projeto. Os arquivos de código-fonte que não foram alterados não serão recompilados.
John Saunders

3

Em um aplicativo da web, é possível criar as camadas da funcionalidade do seu projeto e criar interdependências entre elas, dividindo-a em vários projetos, mas você nunca pode fazer isso em um site.


3

Definitivamente aplicação web, único arquivo DLL e fácil de manter. Mas um site é mais flexível; você pode editar o arquivo aspx em qualquer lugar.


Você também pode editar o arquivo aspx em um projeto de aplicativo da web.
John Saunders

3

Os aplicativos da Web exigem mais memória, presumivelmente porque você não tem escolha a não ser compilar em um único assembly. Acabei de converter um site legado grande em um aplicativo Web e tenho problemas com a falta de memória, ambos em tempo de compilação com a mensagem de erro abaixo:

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

erro, e em tempo de execução com esta mensagem de erro como abaixo:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Minha recomendação para converter sites maiores em hardware legado com restrição de memória é escolher a opção de voltar ao modelo de site. Mesmo após um problema inicial de sucesso, pode surgir mais tarde.


Isso não parece ser uma exceção em tempo de compilação.
John Saunders

1

Aqui, o Aplicativo de suporte da Web é um exemplo de site.

Aqui, o Aplicativo de suporte da Web é um exemplo de site. O site e o aplicativo da Web podem ser dinâmicos / estáticos, depende de requisitos. Aqui está um exemplo para entender o funcionamento do site e do aplicativo da web.


Isso não se aplica no asp.net. A distinção entre site / aplicativo da web (na terminologia asp.net) é mais sobre como os arquivos são organizados (como uma solução bem organizada ou como um monte de arquivos) e compilados ("JIT" vs estático). Nos dois casos, o "programa" é principalmente do lado do servidor.
frenchone

0

Para resumir algumas das respostas acima:

Flexibilidade , você pode fazer alterações ao vivo em uma página da web?

Site : Possível. Pro: benefícios de curto prazo. Con: risco de longo prazo do caos do projeto.

Aplicativo Web : Con: não é possível. Edite uma página, arquive as alterações no controle de origem e crie e implante o site inteiro. Pro: manter um projeto de qualidade.

Questões de desenvolvimento

Site : Estrutura simples do projeto sem um arquivo .csproj. Duas páginas .aspx podem ter o mesmo nome de classe sem conflitos. Nome aleatório do diretório do projeto que leva à criação de erros como por que a estrutura .net entra em conflito com seu próprio arquivo gerado e por que a estrutura .net entra em conflito com seu próprio arquivo gerado . Pro: Simples (simplista). Con: errático.

Aplicativo Web : estrutura do projeto semelhante ao projeto WebForms, com um arquivo .csproj. Os nomes de classe das páginas asp devem ser exclusivos. Pro: Simples (inteligente). Con: nenhum, porque um aplicativo da web ainda é simples.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.