ASP.NET 웹 사이트 또는 ASP.NET 웹 응용 프로그램?
답변:
웹 사이트 :
웹 사이트 프로젝트는 즉시 컴파일됩니다. 더 많은 DLL 파일이 생겨 고통을 겪을 수 있습니다. 또한 다른 디렉토리가 코드로 아직 컴파일되지 않았기 때문에 한 디렉토리에 다른 디렉토리의 페이지 및 제어를 참조해야하는 페이지 또는 제어가있는 경우 문제점이 발생합니다. 다른 문제는 게시에있을 수 있습니다.
Visual Studio에 동일한 이름을 지속적으로 재사용하라는 메시지가 표시되지 않으면 페이지에서 항상 생성되는 DLL 파일의 새 이름이 나타납니다. 이로 인해 동일한 클래스 이름을 포함하는 DLL 파일의 여러 사본이 닫히고 많은 오류가 발생합니다. 웹 사이트 프로젝트는 Visual Studio 2005와 함께 도입되었지만 인기가없는 것으로 판명되었습니다.
웹 애플리케이션 :
웹 응용 프로그램 프로젝트는 추가로 만들어 지금 2005 년의 주요 차이점은 웹 응용 프로그램 프로젝트는 비주얼 스튜디오 2003 그것은 의지와 함께 제공하는 웹 프로젝트와 유사한 작동하도록 설계되었다 있습니다 Visual Studio를위한 SP 1의 한 부분으로 존재했다 빌드시 응용 프로그램을 단일 DLL 파일로 컴파일하십시오. 프로젝트를 업데이트하려면 변경 사항이 발생하도록 프로젝트를 다시 컴파일하고 DLL 파일을 공개해야합니다.
웹 응용 프로그램 프로젝트의 또 다른 멋진 기능은 프로젝트보기에서 파일을 제외하는 것이 훨씬 쉽다는 것입니다. 웹 사이트 프로젝트에서 제외하는 각 파일의 이름은 파일 이름에서 제외 된 키워드로 바뀝니다. 웹 응용 프로그램 프로젝트에서 프로젝트는 이름을 바꾸지 않고 프로젝트보기에서 포함 / 제외 할 파일을 추적하여 훨씬 더 깔끔합니다.
ASP.NET 2.0-웹 사이트 대 웹 응용 프로그램 프로젝트 기사 에서도 하나를 사용하고 다른 것을 사용하지 않는 이유를 설명합니다. 다음은 그 발췌문입니다.
- 큰 Visual Studio .NET 2003 응용 프로그램을 VS 2005로 마이그레이션해야합니까? 웹 애플리케이션 프로젝트를 사용하십시오.
- 프로젝트 파일을 만들지 않고 디렉토리를 웹 프로젝트로 열고 편집 하시겠습니까? 웹 사이트 프로젝트를 사용하십시오.
- 컴파일하는 동안 빌드 전 및 빌드 후 단계를 추가해야합니까? 웹 애플리케이션 프로젝트를 사용하십시오.
- 여러 웹 프로젝트를 사용하여 웹 응용 프로그램을 구축해야합니까? 웹 애플리케이션 프로젝트를 사용하십시오.
- 각 페이지마다 하나의 어셈블리를 생성 하시겠습니까? 웹 사이트 프로젝트를 사용하십시오.
- 각 페이지보기에서 전체 사이트를 작성하지 않고 동적 컴파일 및 페이지 작업을 선호하십니까? 웹 사이트 프로젝트를 사용하십시오.
- 단일 페이지 코드 모델을 코드 숨김 모델보다 선호하십니까? 웹 사이트 프로젝트를 사용하십시오.
웹 응용 프로그램 프로젝트와 웹 사이트 프로젝트 (MSDN)는 웹 사이트와 웹 응용 프로그램 프로젝트의 차이점을 설명합니다. 또한 Visual Studio에서 구성을 설명합니다.
웹 사이트 는 IIS와 같은 ASP.NET 웹 서버에 배포하는 것입니다. 파일과 폴더 만 있으면됩니다. 웹 사이트에는 Visual Studio와 연결되는 프로젝트 파일이 없습니다. 웹 페이지의 코드 생성 및 컴파일 (예 : .aspx, .ascx, .master)은 런타임에 동적으로 수행 되며 이러한 파일에 대한 변경 사항은 프레임 워크에서 감지되어 자동으로 다시 컴파일됩니다. 특별한 App_Code 폴더에 페이지간에 공유 하려는 코드를 넣거나 미리 컴파일하여 Bin 폴더에 어셈블리를 넣을 수 있습니다.
웹 응용 프로그램 은 특별한 Visual Studio 프로젝트입니다. 웹 사이트와의 주요 차이점은 프로젝트를 빌드 할 때 모든 코드 파일이 bin 디렉토리에있는 단일 어셈블리로 컴파일된다는 것입니다. 웹 서버에는 코드 파일을 배포하지 않습니다. 공유 코드 파일을위한 특수 폴더를 사용하는 대신 클래스 라이브러리에서와 같이 어디서나 파일을 저장할 수 있습니다. 웹 응용 프로그램에는 프로젝트 및 코드 파일과 같이 배포되지 않는 파일이 포함되어 있으므로 Visual Studio에는 웹 사이트를 지정된 위치로 출력하는 게시 명령이 있습니다.
App_Code와 Bin
공유 코드 파일을 배포하는 것은 일반적으로 나쁜 생각이지만 웹 응용 프로그램을 선택해야한다는 의미는 아닙니다. 웹 사이트에 대한 모든 코드를 보유하는 클래스 라이브러리 프로젝트를 참조하는 웹 사이트를 가질 수 있습니다. 웹 응용 프로그램은 편리한 방법입니다.
코드 비하인드
이 항목은 .aspx 및 .ascx 파일에만 해당됩니다. 이 항목은 코드 숨김 파일을 사용하지 않는 ASP.NET MVC 및 ASP.NET 웹 페이지와 같은 새로운 응용 프로그램 프레임 워크에서 점차적으로 관련이 있습니다.
웹 응용 프로그램에서 .aspx 페이지 및 .ascx 컨트롤의 코드 숨김 파일을 포함하여 모든 코드 파일을 단일 어셈블리로 컴파일 하면 모든 작은 변경에 대해 다시 빌드해야하며 실시간으로 변경할 수 없습니다. 웹 사이트에서는 변경 사항이 런타임에 의해 감지되고 페이지 / 컨트롤이 자동으로 다시 컴파일되는 동안 변경 사항을 확인하려면 다시 빌드를 유지해야하기 때문에 개발 과정에서 큰 어려움이 될 수 있습니다.
런타임에서 코드 숨김 어셈블리를 관리하면 페이지 / 컨트롤에 고유 한 이름을 지정하거나 다른 네임 스페이스로 구성 할 필요가 없으므로 걱정하지 않아도됩니다.
코드 파일을 배포하는 것이 항상 좋은 생각이라고 말하지는 않지만 (특히 공유 코드 파일의 경우는 아닙니다) 코드 숨김 파일에는 UI 특정 작업, 와이어 이벤트 핸들러 등을 수행하는 코드 만 포함되어야합니다. 중요한 코드는 항상 Bin 폴더에있게됩니다. 이 경우 코드 숨김 파일을 배포하는 것이 유해한 것으로 간주되어서는 안됩니다.
웹 응용 프로그램의 다른 제한 사항은 프로젝트 언어 만 사용할 수 있다는 것입니다. 웹 사이트에서는 C #의 일부 페이지와 VB의 일부 페이지를 가질 수 있습니다. 특별한 Visual Studio 지원이 필요하지 않습니다. 이것이 빌드 제공자 확장 성의 아름다움입니다.
또한 웹 응용 프로그램에서는 컴파일러가 런타임에 컴파일되는 마크 업 코드 (MVC에서는 MvcBuildViews 옵션을 사용하여이 문제를 해결할 수 있음)가 아닌 코드 숨김 클래스 만 컴파일하므로 페이지 / 컨트롤에서 오류를 감지하지 못합니다.
비주얼 스튜디오
웹 응용 프로그램은 Visual Studio 프로젝트이므로 웹 사이트에서 사용할 수없는 일부 기능이 있습니다. 예를 들어, 빌드 이벤트를 사용하여 Javascript 파일을 축소 및 / 또는 결합하는 등 다양한 작업을 수행 할 수 있습니다.
Visual Studio 2010에 도입 된 또 다른 멋진 기능은 Web.config 변환 입니다.웹 사이트에서도 사용할 수 없습니다. 이제 VS 2013에서 웹 사이트와 작동합니다.
웹 응용 프로그램을 구축하는 것은 특히 대규모 사이트를 위해 웹 사이트를 구축하는 것보다 빠릅니다. 주로 웹 응용 프로그램이 마크 업 코드를 컴파일하지 않기 때문입니다. MVC에서 MvcBuildViews를 true로 설정하면 마크 업 코드가 컴파일되고 오류 감지가 발생하므로 매우 유용합니다. 단점은 솔루션을 빌드 할 때마다 전체 사이트를 빌드하며, 특히 사이트를 편집하지 않는 경우 속도가 느리고 비효율적 일 수 있습니다. 나는 MvcBuildViews를 켜고 끄는 것을 발견했다 (프로젝트 언로드가 필요하다). 반면에 웹 사이트를 사용하면 솔루션의 일부로 사이트를 구축할지 여부를 선택할 수 있습니다. 그렇지 않으면 솔루션 빌드가 매우 빠르며 웹 사이트 노드를 클릭하고 변경 한 경우 빌드를 선택할 수 있습니다.
MVC 웹 응용 프로그램 프로젝트에는 '보기 추가', '보기로 이동', '컨트롤러 추가'등과 같은 일반적인 작업에 대한 추가 명령 및 대화 상자가 있습니다. MVC 웹 사이트에서는 사용할 수 없습니다.
IIS Express를 개발 서버로 사용하는 경우 웹 사이트에서 가상 디렉토리를 추가 할 수 있습니다. 웹 응용 프로그램에서는이 옵션을 사용할 수 없습니다.
웹 사이트에서 NuGet 패키지 복원이 작동하지 않으므로 packages.config에 나열된 패키지를 수동으로 설치해야합니다.패키지 복원은 이제 NuGet 2.7을 시작 하는 웹 사이트에서 작동합니다
웹 사이트 = 그래픽 디자이너가 웹 사이트를 작성하고 프로그래머가 한두 페이지 만 편집 할 때 사용
웹 응용 프로그램 = 프로그래머가 응용 프로그램을 만들 때 사용하고 그래픽 디자이너는 한두 페이지 / 이미지 만 편집합니다.
웹 사이트는 프로젝트 파일을 업데이트 할 필요가 없기 때문에 개발자 스튜디오가 없어도 HTML 도구를 사용하여 작업 할 수 있습니다. 웹 응용 프로그램은 팀에서 개발자 스튜디오를 주로 사용하고 높은 코드 내용이있을 때 가장 좋습니다.
(컴파일시 웹 응용 프로그램에서 런타임까지 웹 사이트에서 찾을 수없는 일부 코딩 오류가 있습니다.)
경고 : 나는 몇 년 전에이 답변을 썼으며 그 이후로 Asp.net을 사용하지 않았습니다. 이제 상황이 바뀌었을 것으로 예상됩니다.
동적으로 컴파일 된 프로젝트가 필요한 경우 가 아니라면 웹 사이트 프로젝트를 사용하지 마십시오 .
왜? 웹 사이트 프로젝트는 프로젝트를 변경하거나 이해하려고 할 때 당신을 벽으로 이끌 것입니다. Visual Studio의 정적 타이핑 찾기 기능 (예 : 찾기 사용법, 리 팩터)은 합리적인 크기의 프로젝트에서 모두 영원히 사용할 수 있습니다. 자세한 내용 은 Visual Studio 의 스택 오버플로 질문 느린 "모든 참조 찾기"를 참조하십시오 .
Visual Studio 2005에서 왜 고통을 유발하고 정신을 잃고 생산성을 높이는 웹 사이트 프로젝트 유형으로 인해 웹 응용 프로그램을 삭제했는지 알 수 없습니다.
MSDN에는 차이점을 설명하는 기사가 있습니다.
BTW : 해당 주제에 대해 비슷한 질문이 있습니다. 예 :
- Visual Studio의 웹 사이트와 ASP.Net 웹 응용 프로그램 참고 : 더 이상 제거되지 않았습니다.
- ASP.NET의 웹 사이트 또는 웹 응용 프로그램
이것은 약간 명백한 것처럼 들릴 수 있지만 Visual Studio 2005는 원래 웹 사이트와 함께 제공되기 때문에 오해 된 것 같습니다. 프로젝트가 상당히 제한적이고 논리적 또는 물리적 분리가 많지 않은 웹 사이트를 다루는 경우 웹 사이트가 좋습니다. 그러나 많은 사용자가 데이터를 추가하고 업데이트하는 다른 모듈을 가진 웹 응용 프로그램 인 경우 웹 응용 프로그램을 사용하는 것이 좋습니다.
웹 사이트 모델의 가장 큰 장점은 app_code섹션의 모든 내용이 동적으로 컴파일 된다는 것입니다 . 전체 재배포없이 C # 파일을 업데이트 할 수 있습니다. 그러나 이것은 큰 희생이됩니다. 제어하기 어려운 덮개 아래에서 많은 일이 발생합니다. 네임 스페이스는 제어하기가 어렵고 app_code모든 것이 동적으로 컴파일되기 때문에 특정 DLL 사용은 기본적으로 창 밖으로 나갑니다 .
웹 응용 프로그램 모델에는 동적 컴파일이 없지만 언급 한 내용을 제어 할 수 있습니다.
n 계층 개발을 수행하는 경우 웹 응용 프로그램 모델을 사용하는 것이 좋습니다. 제한된 웹 사이트 나 빠르고 더러운 구현을 수행하는 경우 웹 사이트 모델에 이점이있을 수 있습니다.
보다 자세한 분석은 다음에서 찾을 수 있습니다.
MCTS 자기 진도 훈련 키트 시험 70-515 책에서 :
웹 애플리케이션 (프로젝트)으로
- MVC 응용 프로그램을 만들 수 있습니다.
- Visual Studio는 파일 구조를 폴더 구조에 의존하지 않고 프로젝트 파일 (.csproj 또는 .vbproj)에 저장합니다.
- Visual Basic과 C #을 혼합 할 수 없습니다.
- 디버깅 세션을 중지하지 않으면 코드를 편집 할 수 없습니다.
- 여러 웹 프로젝트간에 종속성을 설정할 수 있습니다.
- 배포하기 전에 응용 프로그램을 컴파일해야합니다. 이렇게하면 다른 페이지가 컴파일되지 않는 경우 페이지를 테스트 할 수 없습니다.
- 서버에 소스 코드를 저장할 필요가 없습니다.
- 어셈블리 이름과 버전을 제어 할 수 있습니다.
- 재 컴파일하지 않고 배포 한 후 개별 파일을 편집 할 수 없습니다.
그것은 당신이 개발하고있는 것에 달려 있습니다.
컨텐츠 지향 웹 사이트는 컨텐츠가 자주 변경되므로 웹 사이트가 더 좋습니다.
응용 프로그램은 데이터를 데이터베이스에 저장하는 경향이 있으며 페이지와 코드는 거의 변경되지 않습니다. 이 경우 어셈블리 배포가 훨씬 제어되고 단위 테스트를 더 잘 지원하는 웹 응용 프로그램을 사용하는 것이 좋습니다.
Compilation먼저 컴파일에 차이가 있습니다. 웹 사이트는 서버에서 사전 컴파일되지 않고 파일에서 컴파일됩니다. 웹 사이트에서 무언가를 변경하려면 서버에서 특정 파일을 다운로드하고 변경 한 다음이 파일을 서버에 다시 업로드하면 모든 것이 잘 작동하기 때문에 이점이 있습니다. 웹 응용 프로그램에서는 모든 것이 사전 컴파일되어 하나의 dll로 끝나기 때문에이를 수행 할 수 없습니다. 프로젝트의 한 파일에서 무언가를 변경하면 모든 것을 다시 컴파일해야합니다. 따라서 서버 웹 사이트에서 일부 파일을 변경하려는 경우 더 나은 솔루션입니다. 또한 많은 개발자가 하나의 웹 사이트에서 작업 할 수 있습니다. 반면 서버에서 코드를 사용할 수 없게하려면 웹 응용 프로그램을 선택해야합니다.
Project structure
프로젝트 구조에도 차이가 있습니다. 웹 응용 프로그램에는 일반 응용 프로그램에서와 마찬가지로 프로젝트 파일이 있습니다. 웹 사이트에는 전통적인 프로젝트 파일이 없으며 솔루션 파일 만 있으면됩니다. 모든 참조 및 설정은 web.config 파일에 저장됩니다.
@Page directive
@Page 지시문에는이 페이지와 연관된 클래스를 포함하는 파일에 대해 다른 속성이 있습니다. 웹 응용 프로그램에서는 표준 "CodeBehind"이고 웹 사이트에서는 "CodeFile"을 사용합니다. 아래 예제에서이를 확인할 수 있습니다.
웹 애플리케이션 :
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="WebApplication._Default" %> 웹 사이트 :
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 네임 스페이스-위의 예에서 네임 스페이스 생성 방법과 다른 차이점도 볼 수 있습니다. 웹 응용 프로그램에서 네임 스페이스는 단순히 프로젝트의 이름입니다. 웹 사이트에는 동적으로 컴파일 된 페이지에 대한 기본 네임 스페이스 ASP가 있습니다.
편집 및 계속-웹 응용 프로그램에서 편집 및 계속 옵션을 사용할 수 있습니다 (설정하려면 도구 메뉴로 이동하여 옵션을 클릭 한 다음 디버깅에서 편집 및 계속을 찾으십시오). 이 기능은 웹 사이트에서 작동하지 않습니다. ASP.NET MVC
ASP.NET MVC (Model View Controller)의 최상의 기본 옵션은 웹 응용 프로그램입니다. 웹 사이트에서 MVC를 사용할 수는 있지만 권장하지는 않습니다.
요약-ASP.NET 웹 응용 프로그램과 웹 사이트의 가장 중요한 차이점은 컴파일입니다. 따라서 소수의 사람들이 수정할 수있는 더 큰 프로젝트에서 작업하는 경우 웹 사이트를 사용하는 것이 좋습니다. 그러나 작은 프로젝트를 수행하는 경우 웹 응용 프로그램도 사용할 수 있습니다.
웹 응용 프로그램은 우리에게 자유를주기 때문에 웹 응용 프로그램은 웹 사이트보다 훨씬 낫습니다.
하나의 우산 아래에 여러 프로젝트가 있고 프로젝트 종속성을 설정합니다. 예를 들어 PCS의 경우 웹 응용 프로그램 내에서 다음을 수행 할 수 있습니다.
- 웹 포털
- 알림 컨트롤러 (이메일 전송 용)
- 비즈니스 계층
- 데이터 액세스 계층
- 예외 관리자
- 서버 유틸리티
- WCF 서비스 (모든 플랫폼에 공통)
- 아이템 목록
ASP.NET 페이지와 관련된 클래스 파일에있는 코드에서 단위 테스트를 실행하려면
- 독립형 클래스의 페이지 및 사용자 정의 컨트롤과 연관된 클래스를 참조하려면
- 전체 사이트에 대한 단일 어셈블리를 만들려면
- 사이트에 대해 생성 된 어셈블리 이름 및 버전 번호 제어
- 프로덕션 서버에 소스 코드를 넣지 않기 위해. IIS 서버에 소스 코드를 배포하는 것을 피할 수 있습니다. 공유 호스팅 환경과 같은 일부 시나리오에서는 IIS 서버의 소스 코드에 대한 무단 액세스가 우려 될 수 있습니다 (웹 사이트 프로젝트의 경우 이러한 위험을 피할 수 있습니다) 개발 컴퓨터에서 사전 컴파일하고 소스 코드 대신 생성 된 어셈블리를 배포하는 경우 쉬운 사이트 업데이트의 이점 중 일부를 잃게됩니다.)
- 웹 사이트의 성능 문제 (웹 사이트에 대한 첫 번째 요청은 사이트를 컴파일해야하므로 지연 될 수 있으며 웹 사이트가 전체 사이트를 포함하여 메모리가 부족한 IIS 서버에서 실행중인 경우 단일 어셈블리는 여러 어셈블리에 필요한 것보다 더 많은 메모리를 사용할 수 있습니다.)
주요 차이점 중 하나는 웹 사이트가 동적으로 컴파일되고 즉석에서 어셈블리를 생성한다는 것입니다. 웹 응용 프로그램은 하나의 큰 어셈블리로 컴파일됩니다.
이 둘의 차이점은 Visual Studio 2008에서 사라졌습니다.
응용 프로그램은 일반적으로 웹 사이트에서 app_code 디렉토리를 사용하는 배포 전에 컴파일됩니다. 앱 코드 폴더에서 변경된 사항이 있으면 서버는 코드를 다시 컴파일합니다. 즉, 웹 사이트에서 코드를 즉시 추가 / 변경할 수 있습니다.
앱의 장점은 재 컴파일이 없기 때문에 초기 시작 시간이 더 빠릅니다.
차이점을 자세히 설명하는 ASP.NET 웹 사이트 에서 비디오 웹 응용 프로그램 프로젝트 및 웹 배포 프로젝트 를 시청하는 것이 좋습니다 .
그건 그렇고, 제목에 혼동하지 마십시오. 비디오의 상당 부분은 웹 사이트 프로젝트와 웹 응용 프로그램 프로젝트의 차이점과 Microsoft가 Visual Studio 2005에서 웹 응용 프로그램 프로젝트를 다시 도입 한 이유를 설명합니다 (아마도 이미 알고 있듯이) 원래 웹 사이트 프로젝트 만 제공 한 다음 웹 응용 프로그램 프로젝트가 SP1에 추가되었습니다. 차이점을 알고 싶은 사람에게 추천하는 훌륭한 동영상입니다.
"웹 사이트"는 특별한 App_Code 디렉토리에 코드를 가지고 있으며 런타임에 여러 DLL (어셈블리)로 컴파일됩니다. "웹 애플리케이션"은 하나의 단일 DLL로 사전 컴파일됩니다.
웹 사이트와 프로젝트 >> 웹 사이트는 Visual Studio를 사용하여 ASP.NET 응용 프로그램을 만드는 두 가지 방법입니다. 하나는 프로젝트가없고 다른 하나는 프로젝트 환경입니다. 차이점은
- 솔루션 파일은 프로젝트 환경에서 루트 디렉토리와 동일한 디렉토리에 저장됩니다.
- 프로젝트 환경에 배포하기 전에 솔루션 및 프로젝트 파일을 제거해야합니다.
- 완전한 루트 디렉토리는 프로젝트가없는 환경에 배포됩니다.
두 가지 접근 방식을 사용하는 데 기본적인 차이점은 없습니다. 그러나 시간이 오래 걸리는 웹 사이트를 만드는 경우 프로젝트 환경을 선택하십시오.
웹 애플리케이션 프로젝트 모델
- Visual Studio .NET 웹 프로젝트와 동일한 웹 프로젝트 시맨틱을 제공합니다. 프로젝트 파일 (프로젝트 파일을 기반으로 한 구조)이 있습니다. 빌드 모델-프로젝트의 모든 코드가 단일 어셈블리로 컴파일됩니다. IIS와 기본 제공 ASP.NET 개발 서버를 모두 지원합니다. Visual Studio 2005 (리팩토링, 제네릭 등) 및 ASP.NET (마스터 페이지, 멤버 자격 및 로그인, 사이트 탐색, 테마 등)의 모든 기능을 지원합니다. 더 이상 FPSE (FrontPage Server Extensions)를 사용할 필요가 없습니다.
웹 사이트 프로젝트 모델
- 프로젝트 파일이 없습니다 (파일 시스템 기반).
- 새로운 컴파일 모델.
- 각 페이지보기에서 전체 사이트를 작성하지 않고 페이지에서 동적 컴파일 및 작업
- IIS와 기본 제공 ASP.NET 개발 서버를 모두 지원합니다.
- 각 페이지에는 자체 어셈블리가 있습니다.
- 다른 코드 모델.
웹 사이트-솔루션 파일이 생성되지 않습니다. 웹 사이트를 만들려면 Visual Studio가 필요하지 않습니다.
웹 애플리케이션-솔루션 파일이 작성됩니다. 웹 응용 프로그램을 만들려면 Visual Studio가 필요합니다. .dllbin 폴더에 단일 파일 이 생성됩니다 .
WebSite : app_code 폴더를 자동으로 생성하고 서버에 게시 한 후 특정 파일이나 페이지에서 일부 변경을 수행하면 모든 파일을 컴파일 할 필요가 없습니다.
웹 응용 프로그램 웹 사이트가 생성하지 않는 솔루션 파일을 자동으로 생성하며 하나의 파일로 변경하면 변경 사항을 반영하기 위해 전체 프로젝트를 컴파일해야합니다.
확실히 웹 응용 프로그램, 단일 DLL 파일 및 유지 관리가 용이합니다. 그러나 웹 사이트는 더 유연합니다. 이동 중에 aspx 파일을 편집 할 수 있습니다.
웹 응용 프로그램은 단일 어셈블리로 컴파일 할 수밖에 없기 때문에 더 많은 메모리가 필요합니다. 방금 큰 레거시 사이트를 웹 응용 프로그램으로 변환했으며 컴파일 시간에 아래와 같이 오류 메시지와 함께 메모리 부족 문제가 발생했습니다.
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation. 오류 및 런타임에이 오류 메시지가 아래와 같이 표시됩니다.
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()메모리 제약이있는 레거시 하드웨어에서 더 큰 사이트를 변환하기위한 권장 사항은 웹 사이트 모델로 되돌릴 수있는 옵션을 선택하는 것입니다. 초기 성공 후에도 나중에 문제가 발생할 수 있습니다.
여기 웹 지원 응용 프로그램은 웹 사이트의 예입니다. 웹 사이트 및 웹 응용 프로그램은 동적 / 정적 일 수 있으며 요구 사항에 따라 다릅니다. 여기에서는 웹 사이트 및 웹 응용 프로그램의 작동을 이해하는 예제가 있습니다.
위의 답변 중 일부를 요약하면 다음과 같습니다.
유연성 , 웹 페이지를 실시간으로 변경할 수 있습니까?
웹 사이트 : 가능. 장점 : 단기 혜택. 단점 : 프로젝트 혼란의 장기 위험.
웹앱 : 단점 : 불가능합니다. 페이지를 편집하고 변경 사항을 소스 제어에 아카이브 한 후 전체 사이트를 빌드하고 배치하십시오. 장점 : 양질의 프로젝트를 유지하십시오.
개발 문제
웹 사이트 : .csproj 파일이없는 간단한 프로젝트 구조 두 개의 .aspx 페이지는 충돌없이 동일한 클래스 이름을 가질 수 있습니다. .net 프레임 워크가 자체 생성 된 파일 과 충돌하는 이유 및 .net 프레임 워크 가 자체 생성 된 파일 과 충돌하는 이유 와 같은 오류를 발생시키는 임의의 프로젝트 디렉토리 이름 . 프로 : 단순 (단순). 단점 : 불규칙합니다.
Web App : .csproj 파일이있는 WebForms 프로젝트와 유사한 프로젝트 구조. ASP 페이지의 클래스 이름은 고유해야합니다. 프로 : 단순 (스마트). 단점 : 웹 앱은 여전히 단순하기 때문에 없습니다.