웹 사이트 미리 컴파일(VB)

  • 아티클

작성자 : Scott Mitchell

Visual Studio는 ASP.NET 개발자에게 WAP(웹 애플리케이션 프로젝트) 및 WSP(웹 사이트 프로젝트)의 두 가지 유형의 프로젝트를 제공합니다. 두 프로젝트 형식 간의 주요 차이점 중 하나는 WAP가 배포 전에 코드를 명시적으로 컴파일해야 하는 반면 WSP의 코드는 웹 서버에서 자동으로 컴파일될 수 있다는 것입니다. 그러나 배포 전에 WSP를 미리 컴파일할 수 있습니다. 이 자습서에서는 미리 컴파일의 이점을 살펴보고 Visual Studio 내에서 및 명령줄에서 웹 사이트를 미리 컴파일하는 방법을 보여 줍니다.

소개

Visual Studio는 ASP.NET 개발자에게 WAP(웹 애플리케이션 프로젝트) 및 WSP(웹 사이트 프로젝트)의 두 가지 프로젝트 유형을 제공합니다. 이러한 프로젝트 형식 간의 주요 차이점 중 하나는 WAP에 명시적 컴파일 이 필요한 반면 WSP는 기본적으로 자동 컴파일을 사용한다는 것입니다. WAP를 사용하면 웹 애플리케이션의 코드를 웹 Bin 사이트의 폴더에 만들어지는 단일 어셈블리로 컴파일합니다. 배포에는 폴더의 어셈블리 Bin 와 함께 프로젝트의 태그 콘텐츠(.aspx.ascx, 및 .master 파일)를 복사해야 합니다. 코드 숨김 클래스 파일 자체는 배포할 필요가 없습니다. 반면에 태그 페이지와 해당 코드 숨김 클래스를 모두 프로덕션 환경에 복사하여 WSP를 배포합니다. 코드 숨김 클래스는 웹 서버에서 요청 시 컴파일됩니다.

참고

프로젝트 모델 간의 차이점, 명시적 컴파일 및 자동 컴파일, 컴파일 모델이 배포에 미치는 영향에 대한 자세한 배경은 배포해야 할 파일 결정 자습서 의 "명시적 컴파일 대 자동 컴파일" 섹션을 참조하세요.

자동 컴파일 옵션은 사용하기 간단합니다. 명시적 컴파일 단계는 없으며 수정된 파일만 배포해야 하는 반면 명시적 컴파일에서는 변경된 태그 페이지와 방금 컴파일된 어셈블리를 배포해야 합니다. 그러나 자동 배포에는 다음과 같은 두 가지 잠재적인 단점이 있습니다.

  • 페이지를 처음 방문할 때 자동으로 컴파일해야 하므로 배포 후 처음으로 ASP.NET 페이지가 요청될 때 짧지만 눈에 띄는 지연이 있을 수 있습니다.
  • 자동 컴파일을 사용하려면 선언적 태그와 소스 코드가 모두 웹 서버에 있어야 합니다. 웹 서버에 설치할 고객에게 웹 애플리케이션을 판매하려는 경우 이는 매력적이지 않은 옵션일 수 있습니다.

위의 두 가지 단점 중 하나가 거래 차단기인 경우 WAP 모델로 전환하거나 배포 전에 WSP를 미리 컴파일 할 수 있습니다. 이 자습서에서는 호스트된 웹 사이트에 가장 적합한 미리 컴파일 옵션을 살펴보고 미리 컴파일된 웹 사이트의 사전 컴파일 프로세스 및 배포를 안내합니다.

ASP.NET 코드 생성 및 컴파일 개요

사용 가능한 미리 컴파일 옵션을 살펴보기 전에 먼저 ASP.NET 페이지가 만들어지거나 마지막으로 업데이트된 후 처음으로 요청되었을 때 발생하는 코드 생성 및 컴파일에 대해 살펴보겠습니다. 아시다시피 ASP.NET 페이지는 파일의 선언적 태그 .aspx 와 일반적으로 별도의 코드 숨김 클래스 파일(.aspx.vb)에 있는 소스 코드 부분의 두 부분으로 구성됩니다. ASP.NET 페이지가 요청될 때 런타임에서 수행하는 단계는 애플리케이션의 컴파일 모델에 따라 달라집니다.

WAP를 사용하면 배포하기 전에 페이지의 소스 코드를 단일 어셈블리로 명시적으로 컴파일해야 합니다. 배포하는 동안 이 어셈블리와 다양한 태그 페이지가 프로덕션 환경에 복사됩니다. 요청이 ASP.NET 페이지에 대한 웹 서버에 도착하면 런타임은 페이지의 코드 숨김 클래스의 instance 만들고 해당 메서드를 ProcessRequest 호출하여 페이지 수명 주기를 시작하고 궁극적으로 요청자에게 반환되는 페이지의 콘텐츠를 생성합니다. 코드 숨김 클래스가 배포 전에 어셈블리로 이미 컴파일되었으므로 런타임은 ASP.NET 페이지의 코드 숨김 클래스에서 작동할 수 있습니다.

WSP 및 자동 컴파일을 사용하면 배포 전에 명시적 컴파일 단계가 없습니다. 대신 배포에는 선언적 콘텐츠와 소스 코드 콘텐츠를 모두 프로덕션 환경에 복사하는 작업이 포함됩니다. 페이지가 만들어지거나 마지막으로 업데이트된 이후 처음으로 ASP.NET 페이지에 대한 요청이 웹 서버에 도착하면 런타임은 먼저 코드 숨김 클래스를 어셈블리로 컴파일해야 합니다. 이 컴파일된 어셈블리는 폴더 %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files에 저장되지만 이 폴더의 위치는 의 Web.config요소를 통해 <pages> 사용자 지정할 수 있습니다. 어셈블리는 디스크에 저장되므로 이후 요청에서 동일한 페이지로 다시 컴파일할 필요가 없습니다.

참고

예상대로 서버가 페이지의 코드를 컴파일하고 결과 어셈블리를 디스크에 저장하는 데 시간이 걸리므로 자동 컴파일을 사용하는 사이트에서 페이지를 처음 요청할 때(또는 변경된 이후 처음으로) 약간의 지연이 발생합니다.

즉, 명시적 컴파일을 사용하면 배포 전에 웹 사이트의 소스 코드를 컴파일해야 하므로 런타임에서 해당 단계를 수행할 필요가 없습니다. 자동 컴파일을 사용하면 런타임은 페이지의 소스 코드 컴파일을 처리하지만, 페이지가 만들어지거나 마지막으로 업데이트된 이후 처음으로 페이지를 방문하는 데 약간의 초기화 비용이 듭니다.

그러나 ASP.NET 페이지( .aspx 파일)의 선언적 부분은 어떨까요? 선언적 태그에 정의된 웹 컨트롤이 코드에서 액세스할 수 있으므로 파일과 코드 숨김 클래스의 코드 간에 .aspx 는 관계가 있음이 분명합니다. 또한 파일의 콘텐츠 .aspx 가 페이지에서 생성된 렌더링된 태그에 큰 영향을 미친다는 것도 분명합니다. 그렇다면 런타임은 파일에 정의된 .aspx 텍스트, HTML 및 웹 컨트롤 구문을 사용하여 요청된 페이지의 렌더링된 콘텐츠를 생성하려면 어떻게 해야 할까요?

WAP와 WSP에 따라 달라지는 하위 수준 구현 세부 정보에 대해 너무 사이드트랙하지는 않지만, 간단히 말해서 런타임은 다양한 웹 컨트롤을 보호된 멤버 및 메서드로 포함하는 클래스 파일을 자동으로 생성합니다. 이 생성된 파일은 해당 코드 숨김 클래스에 대한 부분 클래스 로 구현됩니다. 부분 클래스를 사용하면 단일 클래스의 내용을 여러 파일에 분산할 수 있습니다. 따라서 코드 숨김 클래스는 사용자가 만든 파일과 런타임에서 .aspx.vb 만든 이 자동 생성된 클래스의 두 위치에 정의됩니다. 이 자동 생성된 클래스는 폴더에 %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files 저장됩니다.

여기서 중요한 점은 런타임에서 ASP.NET 페이지를 렌더링하려면 선언적 및 소스 코드 부분을 모두 어셈블리로 컴파일해야 한다는 것입니다. WAP를 사용하면 소스 코드가 배포 전에 어셈블리로 명시적으로 컴파일되지만 선언적 태그는 여전히 코드로 변환되고 웹 서버의 런타임에 의해 컴파일되어야 합니다. 자동 컴파일을 사용하는 WSP에서는 소스 코드와 선언적 태그를 모두 웹 서버에서 컴파일해야 합니다.

WSP 모델에서 명시적 컴파일을 사용할 수 있습니다. WAP 모델과 같이 소스 코드 부분을 명시적으로 컴파일할 수 있습니다. 또한 선언적 태그를 컴파일할 수도 있습니다.

미리 컴파일 옵션

.NET Framework WSP 모델을 사용하여 빌드된 ASP.NET 애플리케이션의 소스 코드(및 콘텐츠)를 컴파일할 수 있는 ASP.NET 컴파일 도구(aspnet_compiler.exe)와 함께 제공됩니다. 이 도구는 .NET Framework 버전 2.0과 함께 릴리스되었으며 폴더에 %WINDIR%\Microsoft.NET\Framework\v2.0.50727 있습니다. 명령줄에서 사용하거나 빌드 메뉴의 웹 사이트 게시 옵션을 통해 Visual Studio 내에서 시작할 수 있습니다.

컴파일 도구는 두 가지 일반적인 형태의 컴파일을 제공합니다. 즉, 현재 위치 미리 컴파일 및 배포를 위한 미리 컴파일입니다. 현재 위치 미리 컴파일을 사용하면 명령줄에서 도구를 실행하고 aspnet_compiler.exe 컴퓨터에 있는 웹 사이트의 가상 디렉터리 또는 실제 경로에 대한 경로를 지정합니다. 그런 다음 컴파일 도구는 프로젝트의 각 ASP.NET 페이지를 컴파일하여 브라우저에서 페이지를 처음으로 방문한 것처럼 컴파일된 버전을 %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files 폴더에 저장합니다. 현재 위치 사전 컴파일은 런타임이 이 단계를 수행할 필요가 없도록 하기 때문에 사이트의 새로 배포된 ASP.NET 페이지에 대한 첫 번째 요청을 가속화할 수 있습니다. 그러나 현재 위치 미리 컴파일은 웹 서버의 명령줄에서 프로그램을 실행할 수 있어야 하므로 대부분의 호스팅된 웹 사이트에는 유용하지 않습니다. 공유 호스팅 환경에서는 이 수준의 액세스가 허용되지 않습니다.

참고

현재 위치 사전 컴파일에 대한 자세한 내용은 방법: ASP.NET 2.0에서 웹 사이트 ASP.NET 사전 컴파일 및 사전 컴파일을 검사.

웹 사이트의 페이지를 폴더로 Temporary ASP.NET Files 컴파일하는 대신 배포를 위한 미리 컴파일은 페이지를 선택한 디렉터리와 프로덕션 환경에 배포할 수 있는 형식으로 컴파일합니다.

이 자습서에서는 업데이트 가능한 사용자 인터페이스를 사용하여 미리 컴파일하고 업데이트할 수 없는 사용자 인터페이스를 사용하여 미리 컴파일하는 두 가지 배포 미리 컴파일 버전이 있습니다. 업데이트 가능한 사용자 인터페이스를 사용하여 미리 컴파일하면 , .ascx및 .master 파일에 선언적 태그.aspx가 남게 되므로 개발자가 원하는 경우 프로덕션 서버에서 선언적 태그를 보고 수정할 수 있습니다. 업데이트할 수 없는 사용자 인터페이스와의 사전 컴파일은 콘텐츠가 없는 페이지를 생성 .aspx 하고 및 .master 파일을 제거 .ascx 하므로 선언적 태그를 숨기고 개발자가 프로덕션 환경에서 변경하지 못하도록 합니다.

업데이트를 가능한 사용자 인터페이스를 사용하여 배포를 위한 미리 컴파일

배포에 대한 사전 컴파일을 이해하는 가장 좋은 방법은 실행 중인 예제를 확인하는 것입니다. 업데이트를 가능한 사용자 인터페이스를 사용하여 배포를 위해 책 검토 WSP를 미리 컴파일해 보겠습니다. ASP.NET 컴파일 도구는 Visual Studio의 빌드 메뉴 또는 명령줄에서 호출할 수 있습니다. 이 섹션에서는 Visual Studio 내에서 도구를 사용하는 방법에 대해 살펴봅니다. "명령줄에서 미리 컴파일" 섹션에서 명령줄에서 컴파일러 도구를 실행하는 것을 살펴봅니다.

Visual Studio에서 책 검토 WSP를 열고 빌드 메뉴로 이동한 다음 웹 사이트 게시 메뉴 옵션을 선택합니다. 그러면 웹 사이트 게시 대화 상자( 그림 1 참조)가 시작됩니다. 여기서는 미리 컴파일된 사이트의 사용자 인터페이스를 업데이트할 수 있는지 여부 및 기타 컴파일러 도구 옵션과 같은 대상 위치를 지정할 수 있습니다. 대상 위치는 원격 웹 서버 또는 FTP 서버일 수 있지만 지금은 컴퓨터의 하드 드라이브에서 폴더를 선택합니다. 업데이트 가능한 사용자 인터페이스를 사용하여 사이트를 미리 컴파일하려면 "미리 컴파일된 이 사이트를 업데이트할 수 있도록 허용" 확인란을 선택한 상태로 두고 확인을 클릭합니다.

s p dot NET 컴파일 도구가 웹 사이트를 미리 컴파일하는 방법을 강조 표시하는 스크린샷

그림 1: ASP.NET 컴파일 도구는 웹 사이트를 지정된 대상 위치로 미리 컴파일합니다.
(전체 크기 이미지를 보려면 클릭)

참고

빌드 메뉴의 웹 사이트 게시 옵션은 Visual Web Developer에서 사용할 수 없습니다. Visual Web Developer를 사용하는 경우 "명령줄에서 미리 컴파일" 섹션에 설명된 ASP.NET 컴파일 도구의 명령줄 버전을 사용해야 합니다.

웹 사이트를 미리 컴파일한 후 웹 사이트 게시 대화 상자에 입력한 대상 위치로 이동합니다. 잠시 시간을 내어 이 폴더의 내용을 웹 사이트의 콘텐츠와 비교해 보세요. 그림 2 는 책 리뷰 웹 사이트 폴더를 보여줍니다. 및 .aspx.cs 파일이 모두 .aspx 포함되어 있습니다. Bin 또한 디렉터리에는 이전 자습서에서 추가한 파일 Elmah.dll을 하나만 포함합니다.

프로젝트 디렉터리에 있는 s p x 및 dot a s p x dot c s 파일을 보여 주는 스크린샷.

그림 2: 프로젝트 디렉터리에 및 파일이 포함되어 .aspx 있습니다 .aspx.cs . 폴더에 Just가 Bin 포함되어 있습니다. Elmah.dll
(전체 크기 이미지를 보려면 클릭)

그림 3 에서는 ASP.NET 컴파일 도구에서 콘텐츠를 만든 대상 위치 폴더를 보여 줍니다. 이 폴더에는 코드 숨김 파일이 없습니다. 또한 이 폴더의 Bin 디렉터리에는 어셈블리 외에도 Elmah.dll 여러 어셈블리와 두 개의 .compiled 파일이 포함됩니다.

대상 위치 폴더의 배포 파일을 보여 주는 스크린샷

그림 3: 대상 위치 폴더에 배포용 파일이 포함되어 있습니다.
(전체 크기 이미지를 보려면 클릭)

WAP의 명시적 컴파일과 달리 배포 프로세스에 대한 사전 컴파일은 전체 사이트에 대해 하나의 어셈블리를 만들지 않습니다. 대신 여러 페이지를 각 어셈블리에 일괄 처리합니다. 또한 파일(있는 경우)을 자체 어셈블리뿐만 아니라 폴더의 App_Code 모든 클래스로 컴파일 Global.asax 합니다. ASP.NET 웹 페이지, 사용자 컨트롤 및 master 페이지(.aspx각각, .ascx및 .master 파일)에 대한 선언적 태그를 포함하는 파일은 대상 위치 디렉터리에 있는 그대로 복사됩니다. 마찬가지로 파일은 이미지, Web.config CSS 클래스 및 PDF 파일과 같은 정적 파일과 함께 바로 복사됩니다. 컴파일 도구가 다양한 파일 형식을 처리하는 방법에 대한 보다 공식적인 설명은 ASP.NET 사전 컴파일 중 파일 처리를 참조하세요.

참고

웹 사이트 게시 대화 상자에서 "사용된 고정 명명 및 단일 페이지 어셈블리" 확인란을 선택하여 ASP.NET 페이지, 사용자 컨트롤 또는 master 페이지당 하나의 어셈블리를 만들도록 컴파일 도구에 지시할 수 있습니다. 각 ASP.NET 페이지를 자체 어셈블리로 컴파일하면 배포를 보다 세밀하게 제어할 수 있습니다. 예를 들어 단일 ASP.NET 웹 페이지를 업데이트하고 해당 변경 사항을 배포해야 하는 경우 해당 페이지의 .aspx 파일 및 연결된 어셈블리만 프로덕션 환경에 배포하면 됩니다. 자세한 내용은 방법: ASP.NET 컴파일 도구를 사용하여 고정 이름 생성 을 참조하세요.

대상 위치 디렉터리에는 미리 컴파일된 웹 프로젝트의 일부가 아닌 파일(즉 PrecompiledApp.config, )도 포함됩니다. 이 파일은 ASP.NET 런타임에 애플리케이션이 미리 컴파일되었으며 업데이트 가능한 UI 또는 정오 업데이트 가능 UI로 미리 컴파일되었는지 여부를 알려줍니다.

마지막으로 Visual Studio 또는 선택한 텍스트 편집기를 사용하여 대상 위치에 있는 파일 중 .aspx 하나를 여세요. 업데이트 가능한 사용자 인터페이스를 사용하여 배포를 미리 컴파일할 때 대상 위치 디렉터리의 ASP.NET 페이지에는 웹 사이트의 해당 파일과 정확히 동일한 태그가 포함됩니다.

업데이트를 할 수 없는 사용자 인터페이스를 사용하여 배포를 위한 미리 컴파일

ASP.NET 컴파일러 도구를 사용하여 업데이트를 수행할 수 없는 UI를 사용하여 배포할 사이트를 미리 컴파일할 수도 있습니다. 업데이트할 수 없는 UI로 사이트를 미리 컴파일하는 것은 업데이트 가능한 UI를 미리 컴파일하는 것과 매우 유사합니다. 주요 차이점은 대상 디렉터리의 ASP.NET 페이지, 사용자 컨트롤 및 master 페이지가 태그를 제거한다는 점입니다. 업데이트할 수 없는 UI를 사용하여 배포할 웹 사이트를 미리 컴파일하려면 빌드 메뉴에서 웹 사이트 게시 옵션을 선택하지만 "미리 컴파일된 사이트를 업데이트할 수 있도록 허용" 옵션을 선택 취소합니다( 그림 4 참조).

미리 컴파일된 이 사이트를 업데이트할 수 있도록 허용 옵션을 보여 주는 스크린샷.

그림 4: 업데이트할 수 없는 UI로 미리 컴파일하려면 "미리 컴파일된 사이트를 업데이트할 수 있도록 허용" 옵션 선택 취소
(전체 크기 이미지를 보려면 클릭)

그림 5 는 호환되지 않는 사용자 인터페이스로 미리 컴파일한 후의 대상 위치 폴더를 보여줍니다.

업데이트를 할 수 없는 U I가 있는 배포의 대상 위치 폴더를 보여 주는 스크린샷

그림 5: 업데이트를 수행할 수 없는 UI를 사용하여 배포할 대상 위치 폴더
(전체 크기 이미지를 보려면 클릭)

그림 3과 그림 5를 비교합니다. 두 폴더는 동일하게 보일 수 있지만, 호환할 수 없는 UI 폴더에는 master 페이지 Site.master가 없습니다. 그림 5에는 다양한 ASP.NET 페이지가 포함되어 있지만 이러한 파일의 내용을 보면 선언적 태그가 제거되고 자리 표시자 텍스트로 대체된 것을 볼 수 있습니다. "이 파일은 미리 컴파일 도구에서 생성된 표식 파일이며 삭제해서는 안 됩니다!"

선언적 태그가 p 점 NET 페이지에서 제거되었음을 보여 주는 스크린샷.

그림 5: 선언적 태그가 ASP.NET 페이지에서 제거되었습니다.

그림 3과 5의 폴더는 Bin 더 크게 다릅니다. 그림 5의 폴더에는 어셈블리 Bin 외에도 각 ASP.NET 페이지, 사용자 정의 컨트롤 및 master 페이지에 대한 파일이 포함되어 .compiled 있습니다.

업데이트할 수 없는 UI로 사이트를 미리 컴파일하는 것은 프로덕션 환경에서 웹 사이트를 설치하거나 관리하는 사람이나 회사에서 ASP.NET 페이지의 콘텐츠를 수정하지 않으려는 경우에 유용합니다. 고객에게 판매하는 ASP.NET 웹 애플리케이션을 빌드하여 자체 웹 서버에 설치하는 경우 배송하는 페이지를 직접 편집 .aspx 하여 사이트의 모양과 느낌을 수정하지 않도록 할 수 있습니다. 업데이트할 수 없는 UI로 웹 사이트를 미리 컴파일하면 설치의 일부로 자리 표시자 .aspx 페이지를 제공하므로 고객이 콘텐츠를 검사하거나 수정할 수 없습니다.

명령줄에서 미리 컴파일

백그라운드에서 Visual Studio의 웹 사이트 게시 대화 상자는 ASP.NET 컴파일 도구(aspnet_compiler.exe)를 호출하여 웹 사이트를 미리 컴파일합니다. 또는 명령줄에서 이 도구를 호출할 수 있습니다. 실제로 Visual Web Developer를 사용하는 경우 Visual Web Developer의 빌드 메뉴에 웹 사이트 게시 옵션이 포함되지 않으므로 명령줄에서 컴파일러 도구를 실행해야 합니다.

명령줄에서 컴파일러 도구를 사용하려면 먼저 명령줄로 삭제하고 프레임워크 디렉터리 로 %WINDIR%\Microsoft.NET\Framework\v2.0.50727이동하세요. 다음으로 명령줄에 다음 문을 입력합니다.

aspnet_compiler -p "physical_path_to_app" -v / -f -u "target_location_folder"

위의 명령은 ASP.NET 컴파일러 도구(aspnet_compiler.exe)를 시작하고 스위치를 통해 -pphysical_path_to_app 루트 웹 사이트를 미리 컴파일하도록 지시합니다. 이 값은 와 같 C:\MySites\BookReviews으며 따옴표로 구분되어야 합니다.

스위치는 -v 사이트의 가상 디렉터리를 지정합니다. 사이트가 IIS 메타베이스에서 기본 웹 사이트로 등록된 경우 스위치를 -p 생략하고 애플리케이션의 가상 디렉터리를 지정할 수 있습니다. 스위치를 -p 사용하는 경우 스위치를 진행하는 -v 값은 웹 사이트의 루트를 나타내며 애플리케이션 루트 참조를 resolve 데 사용됩니다. instance 경우 값을 -v /MySite 지정하면 에 대한 애플리케이션 ~/path/file 의 참조가 로 ~/MySite/path/file확인됩니다. 책 검토 사이트는 웹 호스팅 회사의 루트 디렉터리에 있으므로 스위치 -v /를 사용했습니다.

스위치가 -f 있는 경우 컴파일 도구에 이미 있는 경우 target_location_folder 디렉터리를 덮어쓰도록 지시합니다. 스위치를 -f 생략하고 대상 위치 폴더가 이미 있는 경우 컴파일 도구는 "오류 ASPRUNTIME: 대상 디렉터리가 비어 있지 않습니다. 수동으로 삭제하거나 다른 대상을 선택하세요."

스위치가 -u 있는 경우 도구에 최신 사용자 인터페이스를 만들도록 알릴 수 있습니다. 업데이트할 수 없는 사용자 인터페이스를 사용하여 사이트를 미리 컴파일하려면 이 스위치를 생략합니다.

마지막으로 target_location_folder 대상 위치 디렉터리의 실제 경로입니다. 이 값은 과 같 C:\MySites\Output\BookReviews으며 따옴표로 구분되어야 합니다.

미리 컴파일된 웹 사이트 배포

이 시점에서 ASP.NET 컴파일 도구를 사용하여 업데이트할 수 있는 사용자 인터페이스 옵션과 업데이트할 수 없는 사용자 인터페이스 옵션을 모두 사용하여 웹 사이트를 미리 컴파일하는 방법을 알아보았습니다. 그러나 지금까지 예제에서는 웹 사이트를 프로덕션 환경이 아닌 로컬 폴더로 미리 컴파일했습니다. 좋은 소식은 미리 컴파일된 웹 사이트를 배포하는 것은 산들바람이며 Visual Studio 또는 독립 실행형 FTP 클라이언트와 같은 다른 파일 복사 메커니즘을 통해 수행할 수 있다는 것입니다.

웹 사이트 게시 대화 상자( 그림 1에 처음 표시됨)에는 미리 컴파일된 웹 사이트 파일이 복사되는 위치를 나타내는 대상 위치 옵션이 있습니다. 이 위치는 원격 웹 서버 또는 FTP 서버일 수 있습니다. 이 텍스트 상자에 원격 서버를 입력하면 한 단계에서 웹 사이트가 미리 컴파일되고 지정된 서버에 배포됩니다. 또는 웹 사이트를 로컬 폴더로 미리 컴파일한 다음 FTP 또는 다른 방법을 통해 해당 폴더의 내용을 프로덕션 환경에 수동으로 복사할 수 있습니다.

미리 컴파일된 웹 사이트가 Visual Studio의 웹 사이트 게시 대화 상자를 통해 자동으로 배포되도록 하는 것은 개발 환경과 프로덕션 환경 간에 구성 차이가 없는 간단한 사이트에 유용합니다. 그러나 개발과 프로덕션 간의 일반적인 구성 차이점 자습서 에서 설명한 것처럼 이러한 차이점이 존재하는 것은 드문 일이 아닙니다. 예를 들어 Book Reviews 웹 애플리케이션은 개발 환경과 프로덕션 환경에서 다른 데이터베이스를 사용합니다. Visual Studio에서 웹 사이트를 원격 서버에 게시하면 개발 환경에서 구성 파일 정보를 맹목적으로 복사합니다.

개발 환경과 프로덕션 환경 간에 구성 차이가 있는 사이트의 경우 사이트를 로컬 디렉터리에 미리 컴파일하고 프로덕션 관련 구성 파일을 복사한 다음 미리 컴파일된 출력의 내용을 프로덕션에 복사하는 것이 가장 좋습니다.

개발 환경에서 프로덕션 환경으로 파일을 복사하는 방법에 대한 자세한 내용은 FTP 클라이언트를 사용하여 웹 사이트 배포 및 Visual Studio를 사용하여 웹 사이트 배포 자습서를 참조하세요.

요약

ASP.NET 자동 및 명시적 두 가지 컴파일 모드를 지원합니다. 이전 자습서에서 설명한 대로 WAP(웹 애플리케이션 프로젝트)는 명시적 컴파일을 사용하는 반면 WSP(웹 사이트 프로젝트)는 기본적으로 자동 컴파일을 사용합니다. 그러나 ASP.NET 컴파일 도구를 사용하여 배포 전에 WSP를 명시적으로 컴파일할 수 있습니다.

이 자습서에서는 배포 지원을 위한 컴파일 도구의 미리 컴파일에 중점을 두어 진행했습니다. 배포를 위해 미리 컴파일할 때 컴파일 도구는 대상 위치 폴더를 만들고, 지정된 웹 애플리케이션의 소스 코드를 컴파일하고, 이러한 컴파일된 어셈블리와 콘텐츠 파일을 대상 위치 폴더에 복사합니다. 컴파일 도구는 업다이트 가능하거나 변경할 수 없는 사용자 인터페이스를 만들도록 구성할 수 있습니다. 업데이트할 수 없는 사용자 인터페이스 옵션으로 미리 컴파일하면 콘텐츠 파일의 선언적 태그가 제거됩니다. 간단히 말해서 사전 컴파일을 사용하면 소스 코드 파일을 포함하지 않고 원하는 경우 선언적 태그를 제거하여 웹 사이트 프로젝트 기반 애플리케이션을 배포할 수 있습니다.

행복한 프로그래밍!

추가 정보

이 자습서에서 설명하는 topics 대한 자세한 내용은 다음 리소스를 참조하세요.

이전다음 /previous-versions/aspnet/bb398860(v=vs.100)