웹 응용 프로그램 프로젝트와 Visual Studio의 웹 사이트 프로젝트 비교

만들 수 있는 Visual Studio 웹 응용 프로그램 프로젝트 또는 웹 사이트 프로젝트. 만들거나 선택 하 여 웹 응용 프로그램 프로젝트를 열고 새 프로젝트 또는 프로젝트 열기 Visual Studio 파일 메뉴. 만들거나 웹 사이트 프로젝트를 선택 하 여 열 새 웹 사이트 또는 웹 사이트 열기 파일 메뉴에서.

각 프로젝트 형식에는 장점과 단점이 있으며 요구 사항에 따라 최적의 프로젝트 형식을 선택하려면 각 형식 간의 차이를 이해하는 것이 도움이 됩니다. 한 프로젝트 형식에서 다른 프로젝트 형식으로 변환하는 것은 쉬운 작업이 아니기 때문에 프로젝트를 만들기 전에 적절한 프로젝트 형식을 선택해야 합니다.

이 항목에는 다음과 같은 단원이 포함되어 있습니다.

• 시나리오

• 차이점 요약

• 프로젝트 파일 구조

• 컴파일

• 배포

시나리오

다음과 같은 시나리오에는 웹 응용 프로그램 프로젝트 선호 됩니다.

• 원하는 사용할 수 있는 편집하며 계속하기 Visual Studio 디버거의 기능.

• ASP.NET 페이지와 연결된 클래스 파일에 있는 코드에 대한 단위 테스트를 실행하려는 경우

• 독립 실행형 클래스의 사용자 정의 컨트롤 및 페이지와 연결된 클래스를 참조하려는 경우

• 여러 웹 프로젝트 간에 프로젝트 의존 관계를 설정 하려는 경우.

• 컴파일러에서 전체 사이트에 대해 단일 어셈블리를 만들고자 하는 경우.

• 사이트에 대해 생성되는 어셈블리 이름과 버전 번호를 제어하려는 경우.

• MSBuild 또는 팀 빌드를 사용하여 프로젝트를 컴파일하려는 경우. 예를 들어, 유틸리트 및 빌드 후 단계를 추가할 수 있습니다.

• 프로덕션 서버에 소스 코드를 저장하지 않으려는 경우

• Visual Studio에서 사용할 수 있는 자동 배포 도구를 사용하려는 경우

다음과 같은 시나리오에서는 웹 사이트 프로젝트를 선택하는 것이 좋습니다.

• C#와 Visual Basic 코드를 단일 웹 프로젝트에 포함 하려는 경우. (기본적으로 웹 응용 프로그램 프로젝트 파일에서 언어 설정을 기반으로 컴파일됩니다. 예외를 만들 수 있지만 예외를 만들기는 비교적 어렵습니다.

• Visual Studio에서 프로덕션 사이트를 열고 FTP를 사용하여 실시간으로 업데이트하려는 경우

• 프로젝트를 배포하기 위해 프로젝트를 명시적으로 컴파일할 필요가 없도록 하려는 경우

• 사이트를 미리 컴파일할 때 컴파일러에서 페이지 또는 사용자 정의 컨트롤당 하나의 어셈블리를 포함하거나 폴더당 하나 이상의 어셈블리를 포함할 수 있는 사이트에 대해 여러 어셈블리를 만들도록 하려는 경우

• 프로덕션 환경에서 프로덕션 서버에 새 버전을 복사하거나 프로덕션 서버에서 직접 파일을 편집하여 개별 파일을 업데이트할 수 있게 하려는 경우.

• 사이트를 미리 컴파일한 경우 개별 ASP.NET 웹 페이지 (.aspx 파일) 전체 사이트를 다시 컴파일하지 않고도 업데이트할 수 있게 합니다.

• 추가 백업 복사본으로 사용할 수 있도록 프로덕션 서버에 소스 코드를 저장하려는 경우

차이점 요약

다음 표에서는 주요 차이점을 요약하여 보여 줍니다.

프로젝트 파일 구조

웹 응용 프로그램 프로젝트는 Visual Studio 프로젝트 파일(.csproj 또는 .vbproj)을 사용하여 프로젝트에 대한 정보를 추적합니다. 이 파일에 포함 하거나 프로젝트에서 제외 하 고 파일을 빌드하는 동안 컴파일되므로 지정할 수 있습니다.

웹 사이트 프로젝트에 대 한 모든 파일과 폴더 구조에 웹 사이트에 자동으로 간주 됩니다. 뭔가 컴파일에서 제외 하려는 경우에 웹 사이트 프로젝트 폴더에서 파일을 제거 하거나 컴파일되지 않은 및 IIS에 의해 제공 되지 않습니다 확장 파일 확장명으로 변경 해야 합니다.

웹 응용 프로그램 프로젝트의 프로젝트 파일을 사용 하는 이점은 다음과 같습니다.

• 사이트에서 파일을 임시로 간편하게 제거할 수 있으며 제거하더라도 파일이 폴더 구조에 그대로 있기 때문에 파일을 계속 추적할 수 있습니다. 예를 들어 파일을 배포할 준비가 된 경우 폴더 구조에서 파일을 삭제하지 않고 빌드에서 파일을 임시로 제외할 수 있습니다. 컴파일된 어셈블리를 배포한 다음 파일을 프로젝트에 다시 포함시킬 수 있습니다. 이 기능은 소스 컨트롤 리포지토리에서 작업할 경우에 특히 중요합니다.

웹 사이트 프로젝트에서 프로젝트 파일 없이 폴더 구조를 사용할 경우의 장점은 다음과 같습니다.

• Visual Studio에서 프로젝트 구조를 단독으로 관리할 필요가 없습니다. 예를 들어, 파일을 프로젝트에 복사 하거나 파일 탐색기를 사용 하 여 프로젝트에서 삭제할 수 있습니다.

컴파일

일반적으로 웹 응용 프로그램 프로젝트의 경우 Visual Studio 또는 프로덕션 IIS 서버가 아닌 컴퓨터에서 ASP.NET 배치 컴파일러를 사용 하 여 프로젝트 빌드. 모든 코드 숨김 클래스 파일 및 독립 실행형 클래스 파일이 프로젝트에는 다음 웹 응용 프로그램 프로젝트의 Bin 폴더에 배치 되는 단일 어셈블리에 컴파일됩니다. (.Aspx 및.ascx 파일 동적으로 웹 사이트 프로젝트를 수행 하는 비슷한 방식으로 컴파일됩니다.)

웹 사이트 프로젝트에 직접 프로젝트를 컴파일할 필요가 없습니다. 웹 사이트 프로젝트 일반적으로 동적으로 ASP.NET (개발 컴퓨터와 프로덕션 IIS 서버에서) 컴파일됩니다. 폴더당 하나의 어셈블리를 생성하는 일괄 컴파일 모드와 각 페이지 또는 사용자 정의 컨트롤당 하나의 어셈블리를 생성하는 고정 컴파일 모드 간에 선택할 수 있습니다.

웹 응용 프로그램 프로젝트 컴파일 모델의 장점은 다음과 같습니다.

• MSBuild를 사용하여 사용자 지정 일괄 컴파일 프로세스를 만들 수 있습니다.

• 이름 및 버전과 같은 어셈블리 특성을 쉽게 지정할 수 있습니다.

• 사전에 컴파일하면 프로덕션 서버에서 사이트가 컴파일되는 동안 사용자가 기다릴 필요가 없습니다. (매우 큰 사이트인 경우 웹 사이트 프로젝트의 동적 컴파일 상당한 시간이 걸릴 수 있습니다. 동적 컴파일은 사이트 업데이트 후 사이트 리소스에 대한 요청을 받을 때 수행되며, 필수 리소스가 컴파일되는 동안 컴파일을 트리거하는 요청이 지연될 수 있습니다. 지연되지 말아야 할 경우 사이트를 미리 컴파일할 수 있습니다. 하지만 그렇게 하면 동적 컴파일의 일부 장점을 활용할 수 없게 됩니다.

• 지금까지 프로젝트 폴더 구조에 코드 파일을 배치하는 위치 및 프로젝트의 클래스가 서로 참조하는 방법을 제어해 보았습니다. 동적으로 컴파일하려면 사이트 전체에서 사용되는 클래스에 대한 소스 코드가 App_Code 폴더에 있어야 합니다. App_Code의 클래스에서는 페이지 또는 사용자 정의 컨트롤 클래스를 참조할 수 없습니다.

웹 사이트 프로젝트에 대한 컴파일 모델의 장점은 다음과 같습니다.

• 다른 페이지의 상태와 상관없이 특정 페이지를 테스트할 수 있습니다. 개별 페이지를 실행하기 위해 전체 사이트를 성공적으로 컴파일할 필요가 없으며 App_Code 폴더 또는 Global.asax 파일의 코드와 같이 페이지와 페이지에 종속되는 구성 요소만 성공적으로 컴파일하면 되기 때문입니다. (웹 응용 프로그램 프로젝트에서는 컴파일 오류가 있으면 어느 사이트에 하면 어셈블리를 만들 수 없습니다 및 따라서 컴파일도 부분은 사이트를 테스트할 수 없습니다.)

• 프로덕션에서 웹 사이트를 쉽게 업데이트할 수 있습니다. 사이트를 명시적으로 다시 컴파일할 필요 없이 프로덕션 서버에서 개별 소스 코드 파일을 업데이트할 수 있습니다. 컴파일 오류 때문에 다른 파일이 준비되지 않았더라도 배포할 준비가 된 파일만 개별적으로 업데이트할 수 있습니다. Visual Studio에서 직접 프로덕션 IIS 서버에 웹 사이트를 열고 웹 사이트를 실시간으로 업데이트할 수도 있습니다.

• 일부 시나리오에서는 여러 어셈블리를 미리 컴파일하여 성능상의 이점을 얻을 수 있습니다. 많은 코드가 작성된 여러 페이지가 있는 사이트를 일반적인 예로 들어 보겠습니다. 이 사이트에서 대부분의 페이지는 거의 요청되지 않지만 일부 페이지만 자주 사용됩니다. 이와 같은 사이트를 여러 어셈블리로 컴파일하면 프로덕션 서버가 현재 요청에 필요한 어셈블리만 로드할 수 있습니다. 페이지가 필요하지 않으면 해당 어셈블리는 로드되지 않습니다.

배포

웹 응용 프로그램 프로젝트를 배포 하는 프로젝트는 IIS 서버에 컴파일할 때 생성 된 어셈블리를 복사 합니다. 반면, 웹 사이트 프로젝트를 배포 하려면 일반적으로 프로젝트 소스 파일 IIS 서버에 복사 합니다.

웹 응용 프로그램 프로젝트에 대 한 배포 전략의 장점은 다음과 같습니다.

• 소스 코드를 IIS 서버에 배포하지 않을 수 있습니다. 공유 호스팅 환경과 같은 일부 시나리오에서는 IIS 서버에서 권한 없는 사용자가 소스 코드에 액세스하는 문제가 발생할 수 있습니다. (웹 사이트 프로젝트에서는이 위험 개발 컴퓨터에서 컴파일하여 생성 된 소스 코드 대신 어셈블리를 배포 하 여 피할 수 있습니다. 하지만 이 경우 간편한 사이트 업데이트와 같은 몇 가지 장점을 활용할 수 없습니다.

• 배포에는 어셈블리 또는 코드를 서버에 복사하는 것 외에 다른 작업이 수반되는 경우가 많습니다. 예를 들어 프로덕션에서 데이터베이스 스크립트를 실행해야 할 수 있으며 Web.config 파일의 연결 문자열을 프로덕션 서버에 맞게 변경해야 할 수 있습니다. Visual Studio 원클릭 같은 도구와 함께 이러한 작업의 대부분을 자동화 하는 웹 응용 프로그램 프로젝트 게시를 제공 합니다. 이러한 도구는 웹 사이트 프로젝트에 사용할 수 없습니다.

웹 사이트 프로젝트에 대 한 배포 전략의 장점은 다음과 같습니다.

• 웹 사이트에 있는 작은 변경 하면 전체 사이트를 다시 배포할 필요가 없습니다. 그 대신에 변경된 파일만 프로덕션 IIS 서버에 복사하면 됩니다. 프로덕션 서버에서 직접 파일을 편집할 수도 있습니다. (웹 응용 프로그램 프로젝트의 코드 파일을 단일 어셈블리 파일로 컴파일되므로.aspx 또는.ascx 파일로 변경 된 경우를 제외 하면 전체 사이트 사소한 변경의 경우에 배포 해야 합니다.)

참고 항목

개념

Visual Studio 및 ASP.NET에 대한 웹 배포 콘텐츠 맵

기타 리소스

Web Application Projects vs Web Site Projects