Microsoft Corporation
2005년 11월
소개
ASP.NET 2.0에서는 aspnet_compiler.exe 명령줄 도구를 사용하여 웹 사이트를 미리 컴파일하고, 서버로 배포할 수 있는 웹 사이트 버전을 만들 수 있습니다. 이 도구는 페이지, 사용자 정의 컨트롤, 리소스, 유틸리티 클래스, 기타 파일 등의 소스 파일을 어셈블리로 컴파일합니다.
기본적으로 컴파일러는 여러 소스 파일의 출력이 파일 형식, 파일 종속성 및 기타 조건에 따라 단일 어셈블리로 컴파일되는 "일괄 처리 모드"로 작동합니다. 결과적으로 대상 사이트에는 원래 소스 파일용 실행 코드와 함께 어셈블리 집합이 포함됩니다.
일괄 컴파일로 만든 어셈블리가 프로덕션 서버로 웹 사이트를 배포하는 데 적합하지 않은 경우도 있습니다. 어셈블리 이름은 컴파일러에 의해 자동으로 생성되므로 어떤 어셈블리가 어떤 소스 파일에 매핑되는지 명확히 알 수는 없습니다. 컴파일러가 실행될 때마다 새 이름이 만들어지기 때문에 매 컴파일 후 어셈블리 이름이 다를 수 있습니다. 또한 소스 파일이 변경되면 컴파일러에서 소스 파일을 다른 방식으로 일괄 처리할 수 있습니다. 즉, 결과 어셈블리가 동일한 소스 파일을 나타내지 않을 수 있습니다. 배포된 웹 사이트를 유지 관리하면서 최신 변경 내용이 있을 때만 어셈블리를 업데이트하려는 경우에는 일괄 컴파일의 출력으로 인해 작업이 더 복잡해질 수 있습니다.
이러한 상황에서 편리하게 작업을 진행할 수 있도록 aspnet_compiler.exe에서는 패키지 및 릴리스 관리용으로 특수하게 고안된 -fixednames 옵션을 지원합니다. 이 옵션을 사용하면 두 가지 이점을 제공하는 컴파일러 출력을 만들 수 있습니다. 첫 번째 이점은 컴파일러로 생성된 어셈블리의 이름이 컴파일할 때마다 동일하다는 것이고, 두 번째는 어셈블리가 매번 동일한 입력 파일을 기반으로 한다는 것입니다.
그러나 -fixednames 옵션을 사용해도 결과 어셈블리 이름이 여전히 복잡한 경우가 있을 수 있습니다. 더욱이 fixednames 옵션을 사용할 때 컴파일러는 컴파일된 각 소스 파일에 대해 하나씩, 많은 수의 어셈블리를 만들 수 있습니다.
대규모 웹 사이트에서 작업하는 개발자가 배포 가능한 웹 응용 프로그램을 만들 경우에는 다음과 같은 기능이 필요합니다.
- 출력 어셈블리 및 파일을 관리하는 기능. Visual Studio .NET 2003에서 빌드 작업을 수행하면 단일 어셈블리가 생성되므로 어셈블리를 비교적 간단히 배포할 수 있습니다. 그러나 웹 UI 콘텐츠 파일(ASP.NET 페이지 및 사용자 정의 컨트롤)은 서버에서 여전히 동적으로 컴파일되며 배포가 필요합니다. Visual Studio .NET 2003에서 빌드 출력을 "단일 어셈블리"라는 용어로 지칭하는 것은 완전히 정확하다고는 할 수 없습니다. 코드 숨김 파일은 단일 어셈블리로 컴파일되지만 페이지 어셈블리는 여전히 동적으로 생성되며 일괄 컴파일되거나 개별적으로 컴파일되기 때문입니다.
- 자동으로 생성되는 어셈블리 이름을 그대로 사용하지 않고 결과 출력 어셈블리의 이름을 명시적으로 지정하는 기능
- 릴리스 관리 및 배포 프로세스를 능률화하기 위해 빌드를 보다 쉽게 비교("diff")하는 기능
ASP.NET 2.0 컴파일러에서 -fixednames 옵션을 사용하면 이러한 기능 중 일부가 지원되기는 하나 사용자는 결과 어셈블리의 이름을 지정할 수 없으며 하나 또는 소수의 어셈블리만 만들 수도 없습니다.
이러한 문제를 해결하기 위해 aspnet_merge.exe라는 새로운 병합 유틸리티가 개발되었습니다. 이 유틸리티를 사용하면 컴파일러에서 생성한 어셈블리를 결합하여 관리할 수 있습니다. 병합 도구와 사용 방법은 이 기사에 설명되어 있습니다.
웹 사이트 예제
컴파일러와 병합 도구가 어떻게 함께 작동하는지 설명하기 위해 Visual Studio 2005에서 Personal Web Starter Kit를 사용하여 웹 사이트를 만들었다고 가정해 봅시다. 이 사이트의 파일 구조는 그림 1에 나와 있습니다.
그림 1. Visual Studio 2005를 사용하여 만든 개인 웹 사이트 예제
사이트 콘텐츠 및 레이아웃에 대한 다음 내용을 참고하십시오.
- 웹 UI 콘텐츠 파일(.aspx 파일, .master 파일 및 .ascx 컨트롤)은 응용 프로그램의 여러 폴더에 있습니다.
- 사이트에는 .jpg 및 .css 파일과 같은 정적 콘텐츠가 있습니다.
- 유틸리티 클래스는 App_Code 폴더에 정의되어 있습니다.
이와 같은 웹 사이트의 일반적인 개발 주기는 다음 단계에 따라 진행됩니다.
- 디자인 및 개발 디자이너와 개발자가 Visual Studio 2005를 사용하여 웹 사이트를 만들고 반복해서 테스트 및 수정 작업을 수행합니다. 이 단계에서 Visual Studio 2005 및 ASP.NET 2.0에서 사용되는 동적 컴파일은 Visual Studio 2003 및 ASP.NET 1.1과 비교할 때 개발 프로세스의 속도를 한층 향상시킵니다.
- 빌드 응용 프로그램을 소스 제어로 체크 인하고 빌드 서버를 통해 동기화할 수 있습니다. 개발자는 사용자 지정 빌드 스크립트를 만들어서 aspnet_compiler.exe 및 aspnet_merge.exe와 기타 도구를 실행할 수 있습니다. 또한 배포 업무를 담당하는 개발자는 이 기사의 뒷부분에 나오는 "Visual Studio 2005 웹 배포 프로젝트" 섹션에 설명된 것처럼 새 웹 배포 프로젝트를 사용하여 MSBuild 프로젝트를 만들 수 있습니다. 빌드 스크립트를 통해 배포 가능한 대상 또는 패키지된 대상을 만들 수 있습니다.
- 배포 스크립트 또는 MSBuild 프로젝트를 통해 준비 또는 프로덕션/릴리스 서버로 이동되는 배포 가능한 웹 사이트를 만들 수도 있습니다.
- 테스트 팀에서 준비 서버를 사용하여 응용 프로그램을 테스트합니다.
- 프로덕션/릴리스 준비된 빌드가 프로덕션/릴리스 서버로 이동됩니다.
- 유지 관리 팀 차원에서 준비 또는 프로덕션/릴리스 서버로 변경 내용을 전파하는 프로세스를 실행합니다.
- 이 프로세스가 가장 이상적이기는 하나 설치 파일(.msi 파일)을 만들거나 증분 업데이트를 관리하고, 매일 수행한 빌드를 저장하고, 릴리스 관리 프로세스를 구현하는 프로세스를 만드는 등 다양한 방식으로 이 작업을 수행할 수 있습니다. 이러한 모든 시나리오에서 aspnet_compiler.exe 및 aspnet_merge.exe 도구는 웹 사이트 개발 프로세스에서 핵심적인 역할을 합니다. Visual Studio 2005 웹 배포 프로젝트를 사용하면 빌드, 병합 및 배포 프로세스의 여러 측면을 좀 더 향상시킬 수 있습니다.
이 기사에서는 이러한 프로세스에 대해 자세히 설명하지는 않으며, 빌드 서버에서 또는 Visual Studio 2005 웹 배포 프로젝트를 통해 사용할 수 있는 aspnet_compiler.exe는 물론 특히 중요한 aspnet_merge.exe 도구를 중점적으로 다룹니다.
이 기사에 제공된 예제에 대한 참고 사항
이 기사에 제공된 예제에서는 해당 사이트가 IIS의 응용 프로그램으로 구성되어 있다고 가정하고 -v 옵션을 지정하여 aspnet_compiler.exe를 사용하는 방법을 보여 줍니다. 그러나 컴파일러는 -p 옵션으로 지정된 실제 경로를 사용할 수 있습니다. -p 옵션을 사용하면 aspnet_compiler.exe는 루트 아래의 모든 하위 폴더를 루트 웹 사이트에 속하는 폴더로 취급합니다. 이로 인해 해당 폴더가 독자적인 웹 사이트인 경우 컴파일 오류가 발생할 수 있습니다. -p 옵션을 지정하지 않고 -v 옵션을 사용하면 aspnet_compiler.exe는 어떤 하위 폴더가 루트 응용 프로그램에 속하는지 확인할 수 있습니다.
-p 옵션을 사용할 경우 -v 옵션은 ~ 연산자의 위치를 확인하거나 설치 디렉터리 아래의 Temporary ASP.NET Files 폴더에 폴더를 제공하는 등 다양한 용도로 사용됩니다.
모든 예제 명령은 예제 웹 사이트 루트 폴더에서 실행된다고 가정합니다.
미리 컴파일 개요
새 병합 도구를 살펴보기 전에 ASP.NET 2.0 컴파일러(aspnet_compiler.exe)의 기능을 검토하는 것이 도움이 될 수 있습니다. 이 컴파일러는 .NET Framework 버전 2.0과 함께 제공되며 .NET Framework 설치 폴더(일반적으로 %windir%\Microsoft.NET\Framwork\version) 또는 Visual Studio 2005 Professional Edition이나 Visual Studio 2005 Enterprise Edition에서 실행할 수 있습니다.
ASP.NET 컴파일러를 사용하면 웹 응용 프로그램을 여러 배포 형식으로 미리 컴파일할 수 있습니다. 이러한 각 배포 형식은 웹 응용 프로그램에서 소스 코드를 제거합니다. 또한 이 컴파일러는 필요에 따라 웹 UI 콘텐츠 페이지(.aspx, .master 및 .ascx 파일)를 제거할 수 있습니다.
aspnet_compiler.exe 및 aspnet_merge.exe 도구 설명에는 다음 두 어셈블리 그룹이 사용됩니다.
- 웹 UI 콘텐츠 어셈블리 웹 UI 콘텐츠 자체(.aspx, .master 및 .ascx 파일과 관련된 코드 파일)에 대해 생성되는 어셈블리입니다.
- 최상위 수준 어셈블리 App_Code, App_GlobalResources 및 App_WebReferences와 같은 특수 목적 폴더로부터 Global.asax 같은 특수 파일에 대해 컴파일러에서 생성되는 어셈블리입니다.
aspnet_compiler.exe 명령은 소스 사이트를 미러링하는 레이아웃 구조로 이루어진 출력을 생성합니다. 이 경우 컴파일된 개체 코드는 대상 응용 프로그램의 Bin 폴더에 배치됩니다.
이 컴파일러는 배포용 출력 및 현재 위치에서 출력이라는 두 가지 출력 유형을 제공하는 미리 컴파일을 지원합니다.
배포용 미리 컴파일
배포용으로 미리 컴파일을 수행하면 서버에 작업 웹 응용 프로그램으로 배포할 수 있는 파일 집합이 생성됩니다. 배포용으로 미리 컴파일할 경우 다음과 같은 두 가지 유형의 출력을 만들 수 있습니다.
- 업데이트가 불가능하도록 배포용으로 미리 컴파일은 대상에서 소스 코드뿐만 아니라 모든 태그를 제거합니다. 이 옵션을 사용할 경우 최상위 수준 어셈블리 및 웹 UI 콘텐츠 파일에 대한 모든 소스가 프로덕션 환경에서 제거됩니다. 이러한 특성은 웹 UI 콘텐츠 파일이 항상 동적으로 컴파일되는 ASP.NET 1.1과는 대조됩니다.
- 업데이트가 가능하도록 배포용으로 미리 컴파일은 웹 UI 콘텐츠 페이지의 태그를 유지하며 Visual Studio .NET 2003에서 생성된 사이트와 비슷한 대상 사이트를 만듭니다.
이 컴파일러의 -fixednames 옵션은 두 가지 형식의 배포용 미리 컴파일 모두에 영향을 줍니다. 이 옵션을 지정하면 컴파일 중에 특정(고정) 이름을 갖는 어셈블리가 생성되고 웹 UI 콘텐츠 파일마다 단일 어셈블리가 생성됩니다.
현재 위치에서 미리 컴파일
현재 위치에서 미리 컴파일할 경우 소스 사이트에 직접 어셈블리를 만들고 새 대상 레이아웃은 생성하지 않는 일괄 컴파일이 수행됩니다. 현재 위치에서 미리 컴파일하려면 웹 사이트 가상 디렉터리를 참조하는 -v 옵션을 사용하거나(컴퓨터에 IIS가 설치된 경우) 실제 소스 경로를 참조하는 -p 옵션을 사용하여 컴파일러를 실행합니다.
여기서는 모든 내용을 빠짐없이 설명하기 위해 현재 위치에서 미리 컴파일 기능을 언급했지만 이 기능을 사용할 경우 빌드 시스템에서 aspnet_merge.exe를 통해 결합할 수 있는 출력이 생성되지 않습니다. 현재 위치에서 미리 컴파일할 경우 모든 소스 코드가 유지되는 프로덕션 웹 사이트를 만들 수 있지만 웹 사이트에 대한 첫 번째 요청으로 인해 야기될 수 있는 "컴파일 패널티"는 나타나지 않습니다.
미리 컴파일 - 코드 및 태그 제거
웹 사이트 예제로 돌아가서 그림 2의 명령을 사용하여 배포용으로 웹 사이트를 미리 컴파일하여 업데이트가 불가능한 출력을 만든다고 가정해 봅시다. 이 명령은 웹 사이트에 대한 psw라는 가상 경로를 사용하고 pswcompile이라는 출력 폴더를 지정합니다.
그림 2. aspnet_compiler.exe 실행 시 -v 옵션 지정
컴파일러는 그림 3과 4처럼 대상 사이트(pswcompile)를 생성합니다. 그림 3에서는 소스 웹 사이트 구조가 유지되는 것을 확인할 수 있습니다. 예를 들어 Admin 폴더는 유지되고 Welcome.html과 같은 기타 정적 웹 UI 콘텐츠는 그대로 pswcompile 폴더에 복사됩니다. .aspx 파일은 복사된 것처럼 보이지만 자세히 살펴보면 이 파일이 실제로는 더미 태그 파일이며 해당 내용은 문자열 값에 불과하다는 것을 알 수 있습니다. 이 경우에는 모든 태그(HTML 및 웹 서버 컨트롤)가 제거되었습니다.
그림 4처럼 대상 웹 사이트에는 소스 파일이 전혀 포함되어 있지 않으며 웹 UI 콘텐츠 어셈블리가 Bin 폴더에 생성되었습니다. aspnet_compiler.exe 명령은 Bin 폴더에 .compiled 파일을 만듭니다. 이 파일은 특정 페이지나 특정 가상 경로에 대한 요청이 있을 때 인스턴스화할 클래스를 ASP.NET에 알려줍니다.
메모장과 같은 텍스트 편집기에서 .compiled 파일을 열면 컴파일된 페이지에 대한 참조가 포함되어 있음을 알 수 있습니다. 이 참조를 통해 ASP.NET에서 파일 구조의 원래 페이지 위치를 결정할 수 있습니다. 또한 .compiled 파일에서 페이지 결과로 컴파일된 출력을 포함하는 어셈블리 이름을 확인할 수 있습니다. 컴파일러는 고유한 어셈블리 이름을 자동으로 생성합니다.
참고 배포용으로 미리 컴파일할 경우 항상 새 빌드가 수행되며 aspnet_compiler.exe는 매번 다른 어셈블리 이름을 만듭니다. 또한 어셈블리의 소스로 사용되는 파일은 빌드마다 다를 수 있으므로 릴리스 관리 시 변경에 의해 어떤 어셈블리가 생성되었는지 일관적으로 파악하는 것이 어려울 수 있습니다. 이러한 이유 때문에 -fixednames 옵션을 사용합니다.
그림 3. pswcompile 폴더의 미리 컴파일된 출력
그림 4. pswcompile\Bin 폴더의 미리 컴파일된 출력
고정 이름을 사용한 미리 컴파일
그림 5처럼 -fixednames 옵션을 사용하여 웹 사이트를 컴파일한다고 가정해 봅시다.
그림 5. -fixednames 옵션을 사용한 컴파일
-fixednames 옵션을 사용하면 그림 6처럼 pswcompile\Bin 폴더에 더 많은 어셈블리가 생성됩니다. 각 어셈블리는 하나의 페이지, 사용자 정의 컨트롤 또는 마스터 페이지를 나타냅니다. 옵션 이름에서도 알 수 있듯이 어셈블리 이름은 빌드에 관계없이 동일합니다. 어셈블리 이름은 App_Web_filetype.nnnn.dll 형식으로 지정됩니다. 여기서 nnnn은 해시 값을 나타냅니다.
그림 6. -fixednames 옵션을 사용하여 컴파일한 후 pswcompile\Bin 폴더에 생성되는 미리 컴파일된 출력
미리 컴파일 - 코드만 제거
배포 가능한 대상 디렉터리(예제의 pswcompile)에 웹 UI 콘텐츠 페이지의 태그가 유지되도록 웹 사이트를 미리 컴파일할 수 있습니다. 그림 7에서는 배포용으로 미리 컴파일된 웹 사이트를 생성하는 aspnet_compiler.exe 명령 예제를 보여 줍니다. 그런 다음 사이트에서 사이트 페이지를 제한적으로 수정할 수 있습니다. 이 경우 레이아웃은 변경할 수 있지만 이벤트 핸들러처럼 코드가 필요한 새 컨트롤이나 컨트롤 ID는 변경할 수 없습니다.
그림 7. aspnet_compiler.exe 실행 시 ASP.NET 페이지 및 사용자 정의 컨트롤의 태그 유지
그림 8과 9에서는 pswcompile 폴더와 Bin 폴더의 결과를 보여 줍니다.
그림 8. pswcompile 폴더의 미리 컴파일된 출력
그림 9. pswcompile\Bin 폴더의 미리 컴파일된 출력
그림 8에서는 앞에 나온 컴파일처럼 웹 사이트 구조가 유지되고 Welcome.html과 같은 정적 웹 UI 콘텐츠가 pswcompile 폴더에 복사되었음을 보여 줍니다. 그림 9에서는 웹 UI 콘텐츠 어셈블리와 App_Code.dll 같은 최상위 수준 어셈블리가 pswcompile\Bin 폴더에 생성되었음을 보여 줍니다.
웹 UI 콘텐츠 페이지를 확인해 보면 이 미리 컴파일 형식의 차이점을 알 수 있습니다. 그림 9를 보면 pswcompile\Bin 폴더에 .compiled 파일이 더 포함되어 있지 않다는 것을 알 수 있습니다. 이것은 웹 UI 콘텐츠 페이지 자체가 유지되기 때문입니다. .aspx 페이지는 앞에 나온 컴파일과 같이 더미 파일로 작동하지 않으며 그림 10처럼 다른 어셈블리에서 상속하도록 수정됩니다. 미리 컴파일 후에 이 페이지는 Bin 폴더에 있는 어셈블리에서 상속하며 이전 codeFile 참조는 모두 제거됩니다.
그림 10. 미리 컴파일된 .aspx 파일의 수정된 inherits 특성
고정 이름을 사용한 미리 컴파일
그림 11의 구문을 사용하면 태그를 유지하고 고정 이름을 사용하도록 사이트를 미리 컴파일할 수 있습니다. 앞의 경우처럼 -fixednames 옵션을 사용하면 Bin 디렉터리에 더 많은 어셈블리가 생성됩니다.
그림 11. aspnet_compiler.exe 실행 시 웹 UI 콘텐츠 태그를 유지하고 고정 어셈블리 이름 사용
aspnet_merge.exe를 사용하여 어셈블리 병합
앞에서 살펴보았듯이 aspnet_compiler.exe는 기본적으로 일괄 처리 모드로 출력 어셈블리를 생성하거나 컴파일된 각 파일에 대해 고정 이름을 갖는 어셈블리를 만들어 출력 어셈블리를 생성합니다. 이러한 경우 배포 및 릴리스 관리 계획과 웹 사이트의 특징에 따라 엔터프라이즈 개발자에게 몇 가지 이점이 있습니다.
그러나 출력이 너무 많거나 어셈블리의 이름이 작업 용도에 맞게 지정되지 않는 경우도 있습니다. aspnet_merge.exe 명령을 사용하여 이러한 문제를 보다 쉽게 해결할 수 있습니다.
aspnet_merge.exe 도구는 컴파일러에서 생성된 어셈블리를 결합합니다. 병합 도구를 사용하면 다음과 같이 어셈블리를 결합할 수 있습니다.
- 사전 컴파일된 웹 사이트에서 ASP.NET에 의해 생성된 모든 어셈블리(사용자 지정 어셈블리 제외)를 단일 명명 어셈블리로 결합할 수 있습니다.
- 모든 웹 UI 콘텐츠 어셈블리를 단일 명명 어셈블리로 결합할 수 있습니다.
- 웹 UI 콘텐츠 어셈블리를 웹 사이트의 각 폴더에 대한 어셈블리로 결합할 수 있습니다.
참고 Visual Studio .NET 2003에서 프로젝트를 빌드하면 코드 숨김 파일과 기타 클래스 파일이 웹 사이트용 어셈블리로 빌드됩니다. 소스 코드를 배포하지 않고도 이 어셈블리를 프로덕션 서버로 배포할 수 있습니다. 프로덕션 서버로 모든 태그 페이지도 배포해야 합니다. 증분 업데이트를 사용하여 사이트를 업데이트하려면 코드 숨김 어셈블리 및 관련 태그 페이지를 다시 배포합니다. 그러나 단일 어셈블리에는 단점이 있습니다. 어셈블리를 빌드하는 데는 시간이 많이 걸리므로 배포 중에 F5 키나 Ctrl+F5를 누르면 시간이 많이 지연될 수 있습니다. 뿐만 아니라 코드 숨김 클래스 파일을 변경한 경우에는 전체 어셈블리를 다시 빌드해야 합니다. 테스트를 수행할 경우 새 어셈블리를 만들면 웹 사이트의 모든 페이지가 기술적으로 무효화되므로 모든 페이지를 다시 테스트해야 할 수 있습니다.
이제 ASP.NET 2.0에서는 동적 컴파일, aspnet_compiler.exe를 사용한 미리 컴파일 및 aspnet_merge.exe를 사용한 병합을 조합하여 개발 및 배포 요구를 최대한 충족시킬 수 있습니다. 다음 표에서는 각 컴파일 유형 및 병합 유틸리티를 사용해야 하는 경우를 보여 줍니다.
| 시나리오 | 참고 사항 |
|---|---|
| 개발 중: 동적 컴파일 사용 | Visual Studio 2005 및 ASP.NET 2.0의 동적 컴파일을 사용합니다. 이렇게 하면 F5 키나 Ctrl+F5를 누를 때 전체 빌드가 수행되지 않도록 프로젝트를 구성할 수 있으므로 개발 작업을 빠르게 진행할 수 있습니다. 실제로 빌드를 완전히 비활성화할 수도 있습니다. 이러한 경우 Visual Studio 2005에서 작업 중인 페이지를 실행할 때 페이지와 해당 종속성이 ASP.NET 2.0에 의해 동적으로 컴파일됩니다. 따라서 특정 페이지에 오류가 있어도 다른 페이지를 개발하고 디버깅할 수 있습니다. Visual Studio 2005에서는 ASP.NET 컴파일을 사용하므로 IDE의 모든 코드 오류와 구문 분석 시간 오류를 비롯하여 Visual Studio 컴파일과 ASP.NET 컴파일이 정확하게 일치합니다. 또한 ASP.NET 2.0 동적 컴파일은 편집기에서 사용자 지정 IntelliSense 기능을 제공합니다. |
| 배포: 각 웹 UI 콘텐츠 파일에 대한 단일 어셈블리 만들기 | -fixednames 옵션으로 미리 컴파일하여 각 파일에 대한 웹 UI 콘텐츠 어셈블리가 있는 대상을 생성합니다. 이 시나리오에서는 다른 페이지에 영향을 거의 주지 않고 웹 페이지 수준까지 증분 업데이트를 수행할 수 있으므로 보다 세분화된 릴리스 관리가 가능합니다. 이 옵션을 사용하면 업데이트 가능한 미리 컴파일된 웹 사이트와 업데이트 불가능한 미리 컴파일된 웹 사이트를 모두 만들 수 있습니다. 대규모 사이트의 경우 많은 어셈블리가 생성되므로 확장성 문제가 발생할 수 있습니다. 어셈블리는 암호화 방식으로 명명되지만 페이지와 .compiled 파일을 함께 사용하면 어떤 파일이 어떤 어셈블리를 생성하는지 파악할 수 있습니다. 정적 웹 콘텐츠 및 사용자 지정 어셈블리는 영향을 받지 않습니다. |
| 배포: 각 웹 UI 콘텐츠 폴더에 대한 어셈블리 만들기 | 미리 컴파일을 하고 aspnet_merge.exe를 사용하여 웹 UI 콘텐츠가 들어 있는 각 폴더에 대해 별도의 어셈블리를 만듭니다.
웹 UI 콘텐츠 폴더별로 어셈블리를 따로 만들면 어셈블리 수가 많아집니다. 컴파일할 때 -u 옵션을 생략하면 어셈블리와 더미 페이지만 배포하는 웹 사이트를 만들어 배포된 웹 사이트에서 태그가 제거되도록 할 수 있습니다. |
| 배포: 모든 웹 UI 콘텐츠 파일에 대한 단일 어셈블리 만들기 | 사이트를 미리 컴파일한 후 aspnet_merge.exe를 사용하여 전체 웹 사이트에 대한 단일 웹 UI 콘텐츠 어셈블리를 생성합니다. 웹 UI 콘텐츠에 대한 단일 어셈블리가 있으면 Visual Studio .NET 2003에서 생성된 출력과 비슷한 배포 가능한 웹 사이트를 만들 수 있습니다. 컴파일할 때 -u 옵션을 생략하면 옵션을 생략하면 어셈블리와 더미 페이지만 배포하는 웹 사이트를 만들어 배포된 웹 사이트에서 태그가 제거되도록 할 수 있습니다. 배포된 웹 사이트를 업데이트하려는 경우 다시 컴파일한 어셈블리와 수정된 웹 UI 콘텐츠 파일을 배포할 수 있습니다. 웹 UI 콘텐츠 파일을 변경할 경우 관련 .compiled 페이지 및 .aspx 페이지와 함께 전체 어셈블리를 다시 배포해야 합니다. 프로덕션 서버에 태그 페이지는 유지되지만 동적으로 다시 컴파일되므로 해당 페이지에 대한 테스트 프로세스 결과가 무효화될 수 있습니다. 병합 프로세스 중에 어셈블리에 사용자 지정 이름을 할당할 수 있습니다. 최상위 수준 어셈블리는 이 옵션을 사용해도 영향을 받지 않으며 정적 웹 UI 콘텐츠 및 사용자 지정 어셈블리에도 영향이 없습니다. |
| 배포: 전체 웹 사이트에 대한 어셈블리 만들기 | 미리 컴파일을 하고 aspnet_merge.exe를 사용하여 웹 UI 콘텐츠 어셈블리와 최상위 수준 어셈블리를 결합하는 단일 어셈블리를 생성합니다. 전체 웹 사이트에 대한 단일 어셈블리를 만들어 릴리스 프로세스를 쉽게 관리할 수 있습니다. 단일 어셈블리와 업데이트된 웹 UI 콘텐츠 파일을 배포할 수 있습니다. 컴파일할 때 -u 옵션을 생략하면 어셈블리와 더미 페이지만 포함하는 웹 사이트를 만들고 배포된 웹 사이트에서 태그가 제거되도록 할 수 있습니다. 웹 사이트의 파일을 변경한 경우 어셈블리 및 더미 페이지까지 다시 배포해야 하므로 전체 웹 사이트에 대한 테스트 프로세스 결과가 무효화될 수 있습니다. 어셈블리에 사용자 지정 이름을 할당할 수 있습니다. 정적 웹 UI 콘텐츠 및 사용자 지정 어셈블리는 영향을 받지 않습니다. |
Aspnet_merge.exe는 미리 컴파일된 웹 사이트의 어셈블리만 병합하며 미리 컴파일된 알려진 어셈블리에만 사용할 수 있습니다. 이 도구는 사용자 지정 어셈블리나 Bin 폴더에 있는 App_licenses.dll 어셈블리는 수정하지 않습니다.
참고 Aspnet_merge.exe는 현재 위치에서 병합을 수행합니다. 미리 컴파일된 웹 사이트는 수정되고 결합된 어셈블리는 제거됩니다. 소스 파일에 대해 aspnet_compiler.exe를 다시 실행하는 것이 여의치 않으면 병합 전에 미리 컴파일된 사이트를 백업하십시오.
각 폴더에 대한 콘텐츠 어셈블리 병합
대상 폴더 이름만 지정하고 다른 옵션 없이 aspnet_merge.exe를 실행하면 각 웹 UI 콘텐츠 폴더에 대한 출력 어셈블리가 생성됩니다. 이 병합 유형의 구문은 그림 12에 나와 있습니다.
그림 12. 옵션 없이 aspnet_merge.exe 실행
이 기본 병합 작업을 수행하면 컴파일러 -fixednames 옵션에 의해 생성된 어셈블리 수보다 적은 어셈블리가 생성됩니다. 이러한 형식의 병합은 프로덕션 서버에 증분 업데이트를 배포하려는 경우에 유용할 수 있습니다.
업데이트 불가능한 미리 컴파일된 웹 사이트에서 병합
그림 13에서는 업데이트 불가능한 미리 컴파일된 사이트에 대해 옵션을 지정하지 않고 aspnet_merge.exe를 실행할 경우의 결과를 보여 줍니다. 이 그림에서는 그림 2의 미리 컴파일된 출력을 병합한 결과를 보여 줍니다. 어셈블리 이름은 폴더 이름(App_Web_filetype.nnnn.dll)을 포함하도록 다시 지정됩니다. 또한 웹 사이트의 폴더를 병합하면 Root.dll 및 Admin.dll(빨간색 원으로 표시)이라는 어셈블리 두 개가 생성됩니다. 이 두 어셈블리는 각각 루트 폴더의 웹 UI 콘텐츠와 psw\Admin 하위 폴더의 웹 UI 콘텐츠에서 생성된 것입니다. Bin 폴더에는 App_Code.dll과 같은 최상위 수준 어셈블리가 계속 포함되어 있는 상태이며 테마도 컴파일된 후 단일 Themes.dll 어셈블리(파란색 원으로 표시)에 병합되었습니다.
aspnet_compiler.exe 명령의 -fixednames 옵션 지정 여부와는 관계없이 생성된 어셈블리에 Aspnet_merge.exe를 사용할 수 있습니다. 이 도구는 특정 폴더에 대한 어셈블리 병합을 자동으로 처리합니다.
그림 13. 업데이트 불가능한 미리 컴파일된 웹 사이트의 웹 UI 콘텐츠 폴더를 병합한 결과
업데이트 불가능한 미리 컴파일된 웹 사이트의 경우 컴파일러는 .aspx 파일에 대해 .compiled 파일을 만듭니다. ASP.NET은 .compiled 파일을 사용하여 웹 요청에 맞는 유형을 인스턴스화합니다. 병합 도구는 새로 병합된 어셈블리가 대신 참조되도록 이러한 파일을 업데이트합니다. 그림 14에서는 병합 후 .compiled 파일이 어떻게 달라졌는지 보여 줍니다.
그림 14. 병합 작업 이후 수정된 .compiled 파일
병합된 어셈블리를 식별하는 데는 폴더 이름이 사용되므로 웹 사이트의 웹 UI 콘텐츠 파일 집합에 대한 어셈블리를 비교적 쉽게 확인할 수 있습니다. 그러나 사용자가 원하는 명명 규칙을 사용하려는 경우도 있을 수 있으므로 aspnet_merge.exe로 그림 15처럼 -prefix 옵션을 사용하여 이러한 어셈블리에 대해 접두사를 지정할 수 있습니다.
그림 15. aspnet_merge.exe 실행 시 -prefix 옵션 지정
그림 16 에서는 -prefix 옵션으로 병합을 수행하여 생성된 어셈블리를 보여 줍니다. Root.dll은 Contoso.dll로, Admin.dll은 Contoso.Admin.dll로 이름이 바뀌었음을 알 수 있습니다.
그림 16. -prefix 옵션을 지정하여 업데이트 불가능한 미리 컴파일된 웹 사이트를 병합한 결과
참고 로컬 리소스가 있는 웹 사이트에서 로컬 리소스는 일반적으로 웹 UI 콘텐츠로 취급됩니다. 그러나 병합 도구는 로컬 리소스를 처리하지 않습니다. 로컬 리소스는 이미 폴더가 지정되어 있기 때문입니다.
업데이트 가능한 미리 컴파일된 웹 사이트에서 병합
업데이트 가능한 미리 컴파일된 웹 사이트의 어셈블리를 병합할 경우 업데이트 불가능한 웹 사이트에서 병합했을 때와 동일한 병합된 출력이 생성됩니다. 단, aspnet_merge.exe는 병합된 어셈블리를 가리키도록 .aspx 페이지 같은 태그 페이지를 수정한다는 점이 다릅니다. 업데이트 불가능한 사이트와 마찬가지로 각 폴더에 대해 어셈블리가 생성되며 병합 도구는 동일한 명명 규칙을 적용합니다. 그림 17에서는 병합 후 예제 사이트의 Bin 폴더를 보여 줍니다. 이 폴더에는 웹 UI 콘텐츠에 대한 어셈블리인 Root.dll(루트 psw 폴더의 웹 UI 콘텐츠에서 생성)과 Admin.dll(psw\Admin 하위 폴더의 웹 UI 콘텐츠에서 생성)이 있습니다.
그림 17. 업데이트 가능한 미리 컴파일된 웹 사이트의 웹 UI 콘텐츠 폴더를 병합한 결과
그러나 업데이트 가능한 미리 컴파일된 웹 사이트에서 병합 기능을 사용할 경우에는 약간의 차이가 있습니다. 업데이트 가능한 미리 컴파일된 웹 사이트에서는 테마가 컴파일되지 않으므로 테마는 원래 상태로 유지됩니다. 마찬가지로 로컬 리소스도 웹 UI 콘텐츠로 간주되어 수정될 수 있으므로 원래 상태로 유지됩니다. 컴파일러는 .aspx, .master 및 .ascx 파일에 대해서는 .compiled 파일을 생성하지 않습니다. 이러한 파일은 응용 프로그램에 그대로 남아 있지만 그림 18처럼 병합 과정에서 새로 병합된 어셈블리를 가리키도록 수정됩니다.
그림 18. 병합 작업 이후 수정된 .aspx 파일
미리 컴파일된 웹 UI 콘텐츠를 단일 어셈블리로 병합
각 웹 UI 콘텐츠 폴더에 대해 개별적으로 어셈블리를 배포하지 않고 aspnet_merge.exe를 사용하여 모든 웹 UI 콘텐츠에 대한 단일 어셈블리를 만들 수 있습니다. 이 경우 웹 UI 콘텐츠에 대한 어셈블리를 하나의 단위로 관리할 수 있고 병합된 어셈블리의 이름을 지정할 수도 있습니다. 그림 19에서는 모든 웹 UI 콘텐츠에 대한 단일 어셈블리를 만드는 구문을 보여 줍니다.
그림 19. aspnet_merge.exe 실행 시 모든 웹 UI 콘텐츠에 대한 단일 어셈블리 만들기
그림 19의 명령은 모든 웹 UI 콘텐츠에 대해 Contoso.dll이라는 단일 어셈블리를 생성하여 Bin 폴더에 넣습니다. 최상위 수준 어셈블리는 그대로 유지됩니다. 모든 .compiled 파일 또는 모든 .aspx, .master 및 .ascx 파일은 이 단일 어셈블리를 참조하도록 수정됩니다.
그림 20에서는 업데이트 불가능한 미리 컴파일된 웹 사이트에서 웹 UI 콘텐츠를 단일 어셈블리로 병합할 경우 pswcompile\Bin 폴더의 변경된 내용을 보여 줍니다.
그림 20. 업데이트 불가능한 미리 컴파일된 웹 사이트의 웹 UI 콘텐츠 폴더를 병합할 경우 pswcompile\Bin 폴더의 변경된 내용
미리 컴파일된 웹 UI 콘텐츠 및 최상위 수준 어셈블리 결합
지금까지 웹 UI 콘텐츠 어셈블리의 병합 결과를 살펴보았습니다. 그러나 aspnet_compiler.exe는 웹 사이트의 일부로 여러 다른 어셈블리를 생성합니다. 이 중에는 App_Code 폴더 및 기타 특수 폴더의 내용을 컴파일할 때 생성되는 최상위 수준 어셈블리가 있습니다.
미리 컴파일된 웹 사이트에서 이러한 어셈블리의 이름에는 소스 폴더의 이름이 사용됩니다. 즉, 어셈블리가 이미 폴더 수준으로 컴파일되었음을 의미합니다. 파일이 변경되면 이러한 어셈블리에도 영향이 있으므로 웹 UI 콘텐츠 파일이 변경되지 않았어도 다시 컴파일해야 합니다. 릴리스 관리 프로세스에서는 이 점을 주의해야 합니다.
Aspnet_merge.exe를 사용하면 최상위 수준 어셈블리와 웹 UI 콘텐츠 어셈블리를 결합하는 단일 어셈블리로 최상위 수준 어셈블리를 병합할 수 있습니다. 웹 사이트에 대해 병합된 단일 어셈블리를 만들려면 병합 명령에 -o 옵션을 추가하고 어셈블리 이름을 지정하십시오. 그림 21에서는 구문의 예를 보여 줍니다.
그림 21. aspnet_merge.exe 실행 시 최상위 수준 및 웹 UI 콘텐츠 어셈블리에서 단일 어셈블리 만들기
그림 22에서는 그림 2의 파일 작업 시 -o 옵션을 지정하여 병합할 경우의 결과를 보여 줍니다. 이러한 유형의 병합에서 aspnet_merge.exe를 실행할 때는 단일 파일의 이름을 지정하는 데 사용되는 출력 어셈블리 이름(Contoso.dll)을 지정해야 합니다. 이 병합 작업에서 다른 어셈블리는 생성되지 않습니다.
그림 22. -o 옵션을 사용하여 모든 어셈블리를 병합한 결과
원본 사이트에 로컬 리소스가 포함되어 있을 경우 큰 리소스 어셈블리로 로컬 리소스를 병합할 수 없으므로 병합이 진행되어도 로컬 리소스는 그대로 남아 있습니다. 마찬가지로 전역 리소스도 병합되지 않습니다.
병합된 어셈블리의 어셈블리 특성
aspnet_merge.exe를 사용하여 어셈블리를 결합할 때 기본적으로 이 도구는 병합된 집합의 초기 소스 어셈블리의 어셈블리 특성을 병합된 최종 어셈블리로 전달합니다. 소스 어셈블리에 다른 특성을 지정할 수도 있으므로 병합된 어셈블리에 어떤 특성이 적용되었는지 확인하는 것은 쉽지 않습니다.
병합된 어셈블리에 지정된 특성을 명확히 알 수 있도록 App_Code 어셈블리에 대해 정의된 어셈블리 특성을 소스 특성 집합으로 사용하거나 지정된 어셈블리를 특성 정의 어셈블리로 사용하도록 aspnet_merge.exe에 설정할 수 있습니다.
예를 들어 그림 23에서는 그림 1에 나와 있는 웹 사이트의 App_Code 디렉터리에 추가할 수 있는 Assemblyinfo.cs 파일을 보여 줍니다.
그림 23. App_Code 폴더에 추가된 Assemblyinfo.cs 파일
어셈블리를 병합하지 않으면 App_Code 어셈블리에만 이러한 특성이 지정됩니다. Ildasm.exe와 같은 도구를 사용하여 어셈블리의 특성을 확인할 수 있습니다. App_Code 어셈블리에 대해 정의된 특성을 병합된 어셈블리에 지정하려면 그림 24처럼 -copyattrs 옵션을 사용합니다.
그림 24. aspnet_merge.exe 실행 시 App_Code 어셈블리에 대해 정의된 특성을 병합된 최종 어셈블리에 사용
-copyattrs 옵션을 지정하면 최상위 수준 어셈블리인 App_Code.dll이 병합에 포함되지 않은 경우에도 App_Code 어셈블리에 대한 특성이 사용됩니다. 웹 UI 콘텐츠 어셈블리만 병합하는 경우가 이러한 경우에 해당됩니다. 다음 목록에서는 그림 23의 명령으로 생성된 Contoso.dll 어셈블리에 대한 IL의 매니페스트 조각을 보여 줍니다.
.assembly Contoso
{
.... AssemblyFileVersionAttribute:.. = // ...1.0.4567.0..
.... AssemblyDescriptionAttribute:.. = // ...Contoso 웹 사이트..
.... AssemblyProductAttribute:.. = // ...Contoso.Web..
.... AssemblyCompanyAttribute:.. = // ...Contoso..
..
.ver 1:4000:0:0
}
App_Code 어셈블리를 제외한 다른 어셈블리의 특성을 지정하려면 -copyattrs 옵션으로 어셈블리 이름을 제공합니다. 이 옵션으로 AssemblyInfo.cs 또는 AssemblyInfo.vb 파일에서 어셈블리를 만들어 병합된 어셈블리에 특성을 지정하는 데만 사용할 수 있습니다.
병합된 어셈블리에 서명
개발 팀의 경우 다음과 같은 이유로 미리 컴파일된 응용 프로그램에 서명하려고 할 수 있습니다.
- 특정 개발 팀에서 어셈블리가 제작되었음을 확인할 수 있게 하려는 경우. 서명이나 키는 해당 조직에서만 사용할 수 있으므로 이를 통해 어셈블리가 특정 회사에서 제작되었는지에 대해 어느 정도 신뢰성을 부여할 수 있습니다.
- 알려진 키로 서명된 어셈블리만 신뢰할 수 있도록 하고, 인식할 수 없는 키로 서명되었거나 키가 없는 어셈블리에 대한 실행 권한은 허용하지 않도록 프로덕션 컴퓨터를 잠그려는 경우
병합되고 서명된 웹 사이트 어셈블리를 응용 프로그램 간에 공유하도록 GAC에 추가할 수 있습니다. 그러나 이렇게 할 경우 이미지 같은 리소스 URL 기준 지정 시 문제가 발생할 수 있습니다. 일반적으로 GAC에 미리 컴파일되었거나 병합된 어셈블리를 추가하지 않는 것이 좋습니다. 외부 리소스를 참조하지 않는 사용자 정의 컨트롤에서 생성된 어셈블리와 같이 일부 제한된 상황에서만 병합 및 서명된 어셈블리를 GAC에 추가할 수 있습니다.
aspnet_compiler.exe를 사용하여 미리 컴파일된 사이트의 어셈블리에 서명할 수 있습니다. 그러나 어셈블리를 병합할 경우에는 병합 도구를 사용하여 어셈블리에 서명해야 합니다.
미리 컴파일된 웹 사이트를 병합할 경우 어셈블리의 서명이 연기되었거나 aspnet_compiler.exe를 사용하여 서명되었을 수 있습니다. 병합 중에 미리 서명된 비트 또는 서명되지 않은 비트를 사용하여 병합된 어셈블리에 서명할 수 있습니다. 병합된 결과 어셈블리에 서명하려는 경우 aspnet_merge.exe와 함께 옵션 -keyfile, -keyContainer 또는 -delaysign을 사용할 수 있습니다. aspnet_merge.exe를 실행하여 미리 서명된 어셈블리를 병합할 때 이러한 서명 옵션 중 어느 것도 지정하지 않으면 결과 어셈블리가 서명되지 않습니다.
다음 명령은 미리 컴파일된 어셈블리를 Contoso.dll이라는 단일 어셈블리로 병합한 후 Aspnet_merge.exe를 사용하여 어셈블리에 서명하는 방법을 보여 줍니다.
- 공개 키 및 개인 키를 사용하여 키 파일을 만듭니다.
sn -k contoso.snk
- 서명하지 않고 웹 사이트를 미리 컴파일합니다.
aspnet_compiler -v psw pswcompile
- 웹 응용 프로그램을 병합하고 서명합니다.
aspnet_merge pswcompile -keyfile contoso.snk -o Contoso
병합된 어셈블리 서명 연기
Aspnet_merge.exe를 사용하여 서명을 연기하는 방법은 다음과 같습니다.
- 공개 키와 개인 키를 사용하여 키 파일을 만듭니다. 일반적으로 공개 키와 개인 키는 제한된 사용자만 액세스할 수 있는 안전한 위치에 보관해야 합니다. 구문은 다음과 같습니다.
sn -k contoso.snk
- 해당 파일의 공개 키를 다른 키 파일로 추출합니다.
sn -p contoso.snk contosopublicKey.snk
- 서명하지 않고 웹 사이트를 미리 컴파일합니다.
aspnet_compiler -v psw pswcompile
- -delaysign 및 -keyfile 옵션을 지정하여 어셈블리를 병합한 후 서명을 연기합니다.
aspnet_merge pswcompile -delaysign -keyfile contosopublicKey.snk -o Contoso
병합된 어셈블리에 APTCA 적용
미리 컴파일한 웹 사이트가 완전 신뢰 이외의 보안 수준에서 작동하면 aspnet_compile.exe에 -aptca(Allow Partially Trusted Callers Attribute) 옵션을 지정하여 어셈블리를 미리 컴파일해야 합니다. 이렇게 하면 해당하는 어셈블리 수준의 특성이 컴파일된 어셈블리에 추가됩니다. 이 특성은 aspnet_merge.exe에 의해 병합된 어셈블리에 유지됩니다.
참고 소스 어셈블리의 일부에만 APTCA(AllowPartiallyTrustedCallersAttribute)가 지정된 경우 aspnet_merge.exe는 소스 어셈블리 특성을 전달하지 않고 대신 예외를 발생시킵니다. 따라서 병합된 어셈블리의 코드가 원래 의도된 것과 다른 신뢰 수준으로 제공되는 경우는 없습니다. 단순히 병합하거나 -a 옵션을 지정하여 병합하기 전에 모든 어셈블리에 APTCA를 지정하여 이 동작을 바꿀 수 있습니다. 그러나 병합할 때 -a 옵션을 사용하면 이전에는 APTCA가 지정되지 않았던 어셈블리에 이 특성이 지정될 수 있습니다. 따라서 이전에는 가능하지 않았지만 이제는 부분적으로 신뢰할 수 있는 코드에서 어셈블리를 호출하도록 할 수 있습니다.
APTCA를 적용하는 단계는 다음과 같습니다.
- -aptca 옵션을 지정하여 사이트를 미리 컴파일합니다.
aspnet_compiler -v psw pswcompile -aptca
- 어셈블리를 병합합니다.
aspnet_merge pswcompile -o Contoso
병합된 어셈블리 버전 관리
미리 컴파일된 웹 사이트에 대해 생성된 어셈블리에 버전 정보를 추가하려는 경우 다음을 수행할 수 있습니다.
- App_Code 폴더에 AssemblyInfo.cs 파일이나 AssemblyInfo.vb 파일을 추가합니다. 이렇게 하면 App_Code 폴더에 대해 생성된 어셈블리의 버전이 관리됩니다. 또한 페이지 및 사용자 정의 컨트롤에 대한 코드 숨김 파일에도 버전 특성을 추가할 수 있습니다. 그러나 개별 파일에 일일이 버전 특성을 추가하는 것은 지루한 작업이므로 업데이트 가능한 미리 컴파일 레이아웃의 코드 숨김 파일에만 버전 특성을 추가합니다.
- Web.config 파일에 포함된 <compiler> 요소의 compilerOptions 특성에 AssemblyInfo.cs 또는 AssemblyInfo.vb 파일에 대한 참조를 추가합니다. 이렇게 하면 웹 사이트에 대해 생성된 모든 어셈블리의 버전 관리 정보를 추가할 수 있습니다. 이 경우 ASP.NET에서 WSDL 같은 비코드 유형 파일에 대한 컴파일러를 선택할 수 있으므로 프록시를 컴파일할 때 C# 컴파일러와 Visual Basic 컴파일러를 모두 포함시켜야 합니다.
Aspnet_merge.exe는 App_Code 어셈블리에서 특성을 복사하거나 -copyattrs 옵션으로 지정한 특정 어셈블리에서 특성을 복사하여, 만드는 어셈블리의 버전을 관리할 수 있습니다. 따라서 이러한 특성은 다른 어셈블리 특성과 마찬가지로 취급됩니다. 병합된 어셈블리에 대한 특성을 지정하는 데 이러한 옵션을 사용할 경우 파일 버전, 어셈블리 버전 및 작업에 필요한 기타 어셈블리 특성을 비롯한 모든 버전 특성을 정의할 수 있습니다.
그림 25에서는 그림 1의 웹 사이트를 사용하여 App_Code 어셈블리의 특성을 적용하는 데 사용되는 병합 명령을 보여 줍니다. 그림 22의 AssemblyInfo.cs 파일은 웹 사이트의 App_Code 폴더에 추가되었습니다.
그림 25. aspnet_merge.exe 실행 시 App_Code 어셈블리에 대해 정의된 특성을 병합된 최종 어셈블리에 사용
다음 목록에서는 앞의 명령을 실행할 때 Contoso.dll에 적용되는 전체 메타데이터 중 일부를 보여 줍니다.
.assembly Contoso
{
.... AssemblyFileVersionAttribute:.. = // ...1.0.4567..
.... AssemblyDescriptionAttribute:.. = // ..!Contoso Personal Web
// 사이트 시작 키트..
.... AssemblyProductAttribute:.. = // ...Contoso.Web..
.... AssemblyCompanyAttribute:.. = // ...Contoso..
..
.ver 1:0:4000:0
.dll 파일에 대한 속성을 살펴보면 적용된 특성을 알 수 있습니다.
그림 26. Contoso.dll 어셈블리 특성 및 속성
병합된 어셈블리에 대한 디버그 출력 만들기
컴파일 중에 디버그 출력 파일(.pdb 파일)을 만들 수 있습니다. 기본적으로 aspnet_compiler.exe는 정식 버전 출력을 만들고 Web.config 파일이나 .aspx 페이지, master 페이지 또는 사용자 정의 컨트롤에 포함되어 있는 다른 디버그 옵션은 무시합니다. 디버그 출력을 만들려면 그림 27처럼 컴파일할 때 -d 옵션을 사용합니다.
그림 27. aspnet_compiler.exe 실행 시 -d 옵션을 지정하여 디버그 출력 만들기
디버그 출력 파일을 병합하려면 aspnet_merge.exe 실행 시 -debug 옵션을 지정합니다. -debug 옵션을 지정하지 않으면 병합 과정에서 웹 사이트의 모든 디버그 출력이 제거됩니다. 디버그 출력을 포함하는 사이트를 병합하고 -o 옵션을 사용하여 단일 어셈블리를 만들 경우 pswcompile\Bin 폴더에 병합된 단일 .pdb 파일이 포함됨을 알 수 있습니다. 그림 28에서는 디버그 출력을 만들기 위한 aspnet_merge.exe 명령을 보여 주고, 그림 29에서는 Bin 폴더에 포함되는 결과 출력을 보여 줍니다.
그림 28. aspnet_merge.exe 실행 시 전체 사이트에 대한 디버그 출력 병합
그림 29. 전체 웹 사이트에 대한 디버그 출력을 병합한 결과
빌드 환경에서 aspnet_compiler.exe 및 aspnet_merge.exe 사용
Visual Studio 2005 Professional Edition 및 Visual Studio 2005 Enterprise Edition에는 미리 컴파일을 수행하기 위한 메뉴 명령(빌드 > 웹 게시)이 포함되어 있습니다. Visual Studio 2005에서는 배포용으로 미리 컴파일할 수 있지만 기본적으로 웹 사이트 프로젝트에 직접 빌드 전 작업이나 빌드 후 작업을 추가할 수는 없습니다. 따라서 Visual Studio 2005에서 빌드에 병합 명령을 추가하는 것은 쉽지 않습니다.
이러한 요구를 해결하기 위해 다운로드하여 별도로 설치할 수 있는 새로운 웹 배포 프로젝트 기능을 사용할 수 있습니다. Visual Studio 2005 웹 배포 프로젝트 설치에는 aspnet_merge.exe 도구도 포함되어 있습니다. 웹 배포 프로젝트가 있으면 명령줄 도구를 실행하거나 빌드 관련 파일을 수동으로 편집해야만 사용할 수 있는 기능을 Visual Studio 2005 내에서 사용할 수 있습니다.
개발 팀은 빌드 시 다음 방법을 사용할 수 있습니다.
- 사용자 지정 빌드 작업에서 aspnet_compiler.exe와 aspnet_merge.exe를 순서대로 사용. 일반적으로 엔터프라이즈 개발 팀에서는 자체 빌드 서버 시나리오에 맞는 사용자 지정 빌드 스크립트를 작성합니다.
- 수동으로 만든 MSBuild 파일에 aspnet_compiler.exe 및 aspnet_mer叿䉍/᠀젇ࠁࠂ詀．�㷞ɀĀ�ÿ氀䀧洀작업을 수동으로 추가한 후 빌드 서버에서 실행할 수 있습니다.
- Visual Studio 2005에서 웹 사이트와 연결된 웹 배포 프로젝트를 통해 aspnet_compiler.exe 및 aspnet_merge.exe 도구 사용. 이 방법을 사용하면 많은 기능에 UI가 제공되며 MSBuild를 통해 이 작업을 실행할 수도 있습니다.
Visual Studio 2005 웹 배포 프로젝트
웹 배포 프로젝트를 사용하여 빌드용 어셈블리를 제어하고 배포 가능한 웹 사이트를 만드는 데 필요한 추가 작업을 관리할 수 있습니다. 웹 프로젝트가 포함된 솔루션에 새 웹 배포 프로젝트를 추가하여 해당 웹 배포 프로젝트를 사용자의 웹 사이트에 연결할 수 있습니다. 그림 30에서는 웹 사이트 C:\work\psw와 연결된 웹 배포 프로젝트 psw_deploy를 보여 줍니다.
그림 30. 솔루션 탐색기의 Visual Studio 2005 웹 배포 프로젝트 노드
Visual Studio 2005를 열고 웹 사이트를 만든 후에는 솔루션 탐색기에서 웹 사이트 노드를 마우스 오른쪽 단추로 클릭하고 Add Web Deployment Project(웹 배포 프로젝트 추가)를 선택하여 웹 배포 프로젝트를 솔루션에 추가할 수 있습니다. 솔루션 탐색기에서 웹 배포 프로젝트를 마우스 오른쪽 단추로 클릭한 다음 여러 배포 설정을 구성할 수 있는 속성 페이지를 표시할 수 있습니다. Visual Studio 2005 웹 배포 프로젝트를 사용하면 다음 작업을 수행할 수 있습니다.
- aspnet_compiler.exe 옵션을 사용하여 디버그, 릴리스 또는 준비 빌드 등의 여러 빌드 작업을 구성합니다.
- 해당 구성에서 병합 작업을 구성합니다.
- 버전 관리 및 서명을 처리합니다.
- 병합 중에 어셈블리 이름을 조작합니다.
- Web.config 파일을 수정하는 등의 추가 작업을 배포 프로세스의 일부로 정의합니다.
- 다양한 사용자 지정 시나리오에 적용할 수 있게 프로젝트 파일을 직접 수정합니다.
- 개발 타임에 프로젝트의 빌드를 비활성화하거나 배포 대상을 만들 때 웹 사이트 자체의 빌드를 비활성화합니다.
또한 프로젝트 파일을 수동으로 편집하고 사용자 지정 작업 또는 동작을 빌드 전 작업 및 빌드 후 작업으로 추가할 수 있습니다. 자세한 내용은 MSDN 웹 사이트의 Using Web Deployment Projects with Visual Studio 2005 (영문) 기사를 참조하십시오.
그림 31에서는 출력 어셈블리에 대한 옵션을 설정하기 위한 속성 페이지를 보여 줍니다.
이 페이지에서 aspnet_merge.exe 도구에 사용할 수 있는 몇 가지 옵션을 확인할 수 있습니다.
Aspnet_merge.exe 도움말
이 기사에서는 다양한 aspnet_merge.exe 옵션을 설명합니다. -? 옵션을 지정하여 aspnet_merge.exe를 실행하면 이러한 옵션은 물론 여기에 나와 있는 다른 옵션에 대한 추가 도움말을 볼 수 있습니다.
요약
Aspnet_merge.exe는 웹 사이트 프로덕션 환경을 관리하는 데 사용할 수 있는 새로운 유틸리티입니다. 이 병합 도구는 웹 사이트를 미리 컴파일할 때 ASP.NET 컴파일러 aspnet_compiler.exe에 의해 생성되는 많은 수의 어셈블리를 결합합니다. 이를 통해 ASP.NET 컴파일러에 의해 생성된 출력을 사용하는 게시 프로세스나 릴리스 관리 프로세스를 보다 쉽게 관리할 수 있습니다.
이 기사에서는 병합 도구와 함께 사용할 수 있는 다양한 옵션과 웹 사이트 미리 컴파일 시 이 병합 도구를 사용하는 방법에 대해 설명합니다. 이 기사의 예제에서는 사용자 지정 빌드 모델에 통합할 수 있는 명령을 보여 줍니다.
Aspnet_merge.exe는 새로운 Visual Studio 2005용 웹 배포 프로젝트 추가 기능과 함께 설치됩니다. 이 추가 기능은 aspnet_compiler.exe 및 aspnet_merge.exe 도구 옵션을 관리하기 위한 포괄적인 UI를 제공하며 Visual Studio 내에서 배포 가능한 웹 사이트를 만드는 작업을 관리할 수 있도록 합니다. 웹 배포 프로젝트에는 웹 사이트 배포 관리에 필요한 빌드 전 단계와 빌드 후 단계를 추가하기 위한 기능도 포함되어 있습니다.
'.net' 카테고리의 다른 글
| ASP.NET 2.0으로 웹 사이트를 구축하여 음악 라이브러리 탐색 (2) | 2007.05.03 |
|---|---|
| ADO.NET 2.0의 쿼리 알림 (0) | 2007.05.03 |
| Windows 2003의 서비스팩을 설치한 후에 디버깅이 안되는 현상이 나타날 때 (1) | 2007.05.03 |
| Asp.net 2.0 Smtp 메일 보내기 (3) | 2007.05.03 |
| 웹 사이트 레이아웃 (1) | 2007.05.03 |