ASP.NET 웹 사이트 또는 ASP.NET 웹 응용 프로그램?


Answers

웹 사이트 는 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 지원은 필요 없습니다. 이것이 빌드 제공 업체의 확장 성의 아름다움입니다.

또한 웹 응용 프로그램에서는 컴파일러가 런타임에 컴파일되는 코드 비하인드 클래스 (MvcBuildViews 옵션을 사용하여 수정할 수있는 MVC에서는)가 아닌 코드 비헤이비어 클래스 만 컴파일하므로 페이지 / 컨트롤에서 오류를 감지하지 않습니다.

비주얼 스튜디오

웹 응용 프로그램은 Visual Studio 프로젝트이므로 웹 사이트에서 사용할 수없는 몇 가지 기능을 사용할 수 있습니다. 예를 들어 빌드 이벤트를 사용하여 Javascript 파일 축소 및 / 또는 결합과 같은 다양한 작업을 수행 할 수 있습니다.

Visual Studio 2010에 도입 된 또 다른 멋진 기능은 Web.config 변환 입니다. 웹 사이트에서도 사용할 수 없습니다. 이제 VS 2013의 웹 사이트에서 작동합니다.

웹 응용 프로그램을 구축하는 것이 특히 대규모 사이트의 경우 웹 사이트를 만드는 것보다 빠릅니다. 이는 주로 웹 응용 프로그램이 마크 업 코드를 컴파일하지 않기 때문입니다. MVC에서 MvcBuildViews를 true로 설정하면 마크 업 코드가 컴파일되고 오류 감지가 발생하므로 매우 유용합니다. 단점은 솔루션을 구축 할 때마다 사이트 전체를 구성하기 때문에 사이트를 편집하지 않는 경우 느리고 비효율적 일 수 있습니다. 나는 MvcBuildViews를 켜고 끄는 (프로젝트 언로드가 필요함) 것을 알았다. 반면에 웹 사이트에서는 솔루션의 일부로 사이트를 구축할지 여부를 선택할 수 있습니다. 그렇지 않으면 솔루션을 구축하는 것이 매우 빠르며, 변경 한 경우 항상 웹 사이트 노드를 클릭하고 빌드를 선택할 수 있습니다.

MVC 웹 응용 프로그램 프로젝트에는 'Add View', 'Go To View', 'Add Controller'등과 같은 일반적인 작업을위한 추가 명령과 대화 상자가 있습니다. MVC 웹 사이트에서는 사용할 수 없습니다.

IIS Express를 개발 서버로 사용하는 경우 웹 사이트에서 가상 디렉터리를 추가 할 수 있습니다. 이 옵션은 웹 응용 프로그램에서 사용할 수 없습니다.

NuGet 패키지 복원은 웹 사이트에서 작동하지 않으므로 packages.config에 나열된 패키지를 수동으로 설치해야합니다. 패키지 복원은 이제 NuGet 2.7을 시작 하는 웹 사이트에서 작동합니다

Question

Visual Studio에서 새 ASP.NET 프로젝트를 시작하면 ASP.NET 웹 응용 프로그램을 만들거나 ASP.NET 웹 사이트를 만들 수 있습니다.

ASP.NET 웹 응용 프로그램과 ASP.NET 웹 사이트의 차이점은 무엇입니까? 내가 왜 다른 것을 택할 것인가?

사용하고있는 Visual Studio의 버전에 따라 대답이 달라졌습니까?




동적으로 컴파일 된 프로젝트를 특별히 필요로 하지 않는 한 웹 사이트 프로젝트를 사용하지 마십시오 .

왜? 웹 사이트 프로젝트는 프로젝트를 변경하거나 이해하려고 할 때 벽을 부추 기 때문입니다. Visual Studio에서 정적 유형 찾기 기능 (예 : 사용법, 리팩토링 도구)은 합리적인 규모의 프로젝트에서 모두 오래 걸릴 것입니다. 자세한 내용 은 Visual Studio에서 스택 오버플로 질문 느리게 "모든 참조 찾기"를 참조하십시오 .

Visual Studio 2005의 웹 응용 프로그램을 통증 유발, 온전한 배수, 생산성 카툰 웹 사이트 프로젝트 유형으로 분류 한 이유를 알 수 없습니다.




확실히 웹 응용 프로그램, 단일 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()

메모리가 제한된 레거시 하드웨어에서 더 큰 사이트를 변환하는 것이 좋습니다. 웹 사이트 모델로 돌아갈 수있는 옵션을 제공하는 것입니다. 초기 성공 후에도 문제가 나중에 일어날 수 있습니다.




이것은 약간 분명한 것처럼 들릴지 모르겠지만 Visual Studio 2005는 원래 웹 사이트에서만 제공 되었기 때문에 오해의 여지가 있습니다. 프로젝트가 상당히 제한적이고 논리적 또는 물리적 분리가 많이없는 웹 사이트를 다루는 경우 웹 사이트는 괜찮습니다. 그러나 많은 사용자가 데이터를 추가하고 업데이트하는 모듈이 다른 웹 응용 프로그램이라면 웹 응용 프로그램을 사용하는 것이 좋습니다.

웹 사이트 모델의 가장 큰 프로는 app_code 섹션의 app_code 항목이 동적으로 컴파일된다는 것입니다. 전체 재배치없이 C # 파일을 업데이트 할 수 있습니다. 그러나 이것은 커다란 희생을 가져옵니다. 제어하기 어려운 덮개 아래에서 많은 일이 발생합니다. 네임 스페이스는 제어하기 어렵고 모든 DLL이 동적으로 컴파일되기 때문에 특정 DLL 사용이 app_code 아래의 모든 항목에 대해 기본적으로 창 밖으로 나옵니다.

웹 응용 프로그램 모델에는 동적 컴파일이 없지만 언급 한 내용을 제어 할 수 있습니다.

n 계층 개발을 수행하는 경우 웹 응용 프로그램 모델을 사용하는 것이 좋습니다. 제한된 웹 사이트 또는 빠르고 더러운 구현을 수행하는 경우 웹 사이트 모델에 이점이있을 수 있습니다.

보다 자세한 분석은 다음에서 찾을 수 있습니다.




응용 프로그램은 일반적으로 웹 사이트에서 app_code 디렉토리를 사용하는 배포 전에 컴파일됩니다. 앱 코드 폴더가 변경되면 서버는 코드를 다시 컴파일합니다. 즉, 즉시 웹 사이트 코드를 추가 / 변경할 수 있습니다.

앱의 장점은 다시 컴파일 할 필요가 없으므로 초기 시작 시간이 빨라진다는 것입니다.




웹 사이트 - 솔루션 파일이 생성되지 않습니다. 우리가 웹 사이트를 만들려면 비주얼 스튜디오가 필요 없습니다.

웹 응용 프로그램 - 솔루션 파일이 생성됩니다. 우리가 웹 애플리케이션을 만들고 싶다면 Visual Studio가 필요합니다. bin 폴더에 하나의 .dll 파일을 만듭니다.




주요 차이점 중 하나는 웹 사이트가 동적으로 컴파일되고 즉석 어셈블리를 작성한다는 것입니다. 웹 응용 프로그램은 하나의 큰 어셈블리로 컴파일됩니다.

이 둘의 차이점은 Visual Studio 2008에서 제거되었습니다.




웹 응용 프로그램 프로젝트 모델

  • Visual Studio .NET 웹 프로젝트와 동일한 웹 프로젝트 의미를 제공합니다. 프로젝트 파일 (프로젝트 파일을 기반으로 한 구조)이 있습니다. 빌드 모델 - 프로젝트의 모든 코드가 단일 어셈블리로 컴파일됩니다. IIS와 기본 제공 ASP.NET 개발 서버를 모두 지원합니다. Visual Studio 2005 (리팩토링, 제네릭 등) 및 ASP.NET (마스터 페이지, 멤버십 및 로그인, 사이트 탐색, 테마 등)의 모든 기능을 지원합니다. FrontPage Server Extensions (FPSE) 사용은 더 이상 필요하지 않습니다.

웹 사이트 프로젝트 모델

  • 프로젝트 파일 없음 (파일 시스템 기반).
  • 새 컴파일 모델.
  • 동적 컴파일 및 각 페이지 뷰에서 전체 사이트를 구축하지 않고 페이지에서 작업.
  • IIS와 기본 제공 ASP.NET 개발 서버를 모두 지원합니다.
  • 각 페이지마다 고유 한 어셈블리가 있습니다.
  • Defferent 코드 모델.



웹 응용 프로그램 프로젝트에서 Visual Studio는 페이지 및 사용자 컨트롤을위한 추가 .designer 파일이 필요합니다. 웹 사이트 프로젝트에는이 오버 헤드가 필요하지 않습니다. 마크 업 자체가 디자인으로 해석됩니다.




그것은 당신이 개발하고있는 것에 달려 있습니다.

콘텐츠 중심 웹 사이트는 콘텐츠가 자주 바뀌고 웹 사이트가 더 적합합니다.

응용 프로그램은 데이터를 데이터베이스에 저장하고 페이지 및 코드를 거의 변경하지 않는 경향이 있습니다. 이 경우 어셈블리 배포가 훨씬 제어되고 단위 테스트를 더 잘 지원할 수있는 웹 응용 프로그램을 만드는 것이 좋습니다.




"웹 사이트"는 특수 App_Code 디렉토리에 코드가 있으며 런타임에 여러 DLL (어셈블리)로 컴파일됩니다. "웹 응용 프로그램"은 하나의 단일 DLL로 사전 컴파일됩니다.