Visual Studio에서 새 ASP.NET 프로젝트를 시작할 때 ASP.NET 웹 응용 프로그램을 만들거나 ASP.NET 웹 사이트를 만들 수 있습니다.
ASP.NET 웹 응용 프로그램과 ASP.NET 웹 사이트의 차이점은 무엇입니까? 왜 다른 것을 선택해야합니까?
사용중인 Visual Studio 버전에 따라 답변이 달라 집니까?
답변
웹 사이트 :
웹 사이트 프로젝트는 즉시 컴파일됩니다. 더 많은 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 #을 혼합 할 수 없습니다.
- 디버깅 세션을 중지하지 않으면 코드를 편집 할 수 없습니다.
- 여러 웹 프로젝트간에 종속성을 설정할 수 있습니다.
- 배포하기 전에 응용 프로그램을 컴파일해야합니다. 이렇게하면 다른 페이지가 컴파일되지 않는 경우 페이지를 테스트 할 수 없습니다.
- 서버에 소스 코드를 저장할 필요가 없습니다.
- 어셈블리 이름과 버전을 제어 할 수 있습니다.
- 재 컴파일하지 않고 배포 한 후 개별 파일을 편집 할 수 없습니다.
