aspnet_merge.exe 명령을 사용하여 배포에 대해 미리 컴파일된 출력 ASP.NET 관리

 

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에서 개인 웹 시작 키트를 사용하여 웹 사이트를 만들었다고 상상해 보세요. 사이트의 파일 구조는 그림 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_merge.exe 도구와 aspnet_compiler.exe 집중합니다.

이 문서의 예제에 대한 참고 사항

이 문서의 예제에서는 사이트가 IIS에서 애플리케이션으로 구성된 것으로 간주되므로 -v 옵션과 함께 aspnet_compiler.exe 사용하는 방법을 보여 줍니다. 그러나 컴파일러는 -p 옵션을 사용하여 지정된 실제 경로로 작업할 수 있습니다. -p 옵션을 사용하는 경우 aspnet_compiler.exe 루트 아래의 모든 하위 폴더를 루트 웹 사이트에 속한 폴더로 처리합니다. 이로 인해 해당 폴더가 자체 웹 사이트인 경우 컴파일 오류가 발생할 수 있습니다. -p 옵션 없이 -v 옵션을 사용하는 경우 aspnet_compiler.exe 루트 애플리케이션의 일부인 하위 폴더를 확인할 수 있습니다.

-p 옵션을 사용하는 경우 -v 옵션은 연산자의 위치를 해결하고 설치 디렉터리 아래의 ~ 임시 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 콘텐츠 파일당 단일 어셈블리를 생성하는 컴파일을 수행합니다.

미리 컴파일 위치

미리 컴파일은 원본 사이트에서 직접 어셈블리를 만들고 새 대상 레이아웃을 생성하지 않는 일괄 처리 컴파일을 수행합니다. 미리 컴파일하려면 웹 사이트 가상 디렉터리(IIS가 컴퓨터에 설치된 경우)를 참조하는 -v 옵션 또는 물리적 원본 경로를 참조하는 -p 옵션을 사용하여 컴파일러를 실행합니다.

완전성을 위해 여기에 미리 컴파일이 언급되어 있지만 빌드 시스템의 aspnet_merge.exe 결합되는 출력은 생성하지 않습니다. 미리 컴파일하면 모든 소스 코드를 유지하는 프로덕션 웹 사이트를 생성할 수 있지만 웹 사이트에 대한 첫 번째 요청이 발생할 수 있는 "컴파일 페널티"는 발생하지 않습니다.

미리 컴파일 - 코드 및 태그 제거

예제 웹 사이트로 돌아가서 그림 2에 표시된 명령을 사용하여 배포를 위해 웹 사이트를 미리 컴파일하여 호환되지 않는 출력을 만들 수 있다고 가정합니다. 이 명령은 웹 사이트의 가상 경로(psw)를 사용하고 pswcompile이라는 출력 폴더를 지정합니다.

그림 2. -v 옵션을 사용하여 aspnet_compiler.exe 실행

컴파일러는 그림 3과 4에 표시된 대상 사이트(pswcompile)를 생성합니다. 그림 3에서는 원본 웹 사이트 구조가 유지되는 것을 볼 수 있습니다. 예를 들어 관리 폴더는 그대로 유지되고 Welcome.html 같은 다른 정적 웹 UI 콘텐츠는 pswcompile 폴더에 있는 그대로 복사됩니다. .aspx 파일이 복사된 것으로 보이지만 자세히 살펴보면 이러한 파일이 실제로 더미 태그 파일이며 해당 콘텐츠가 단순히 문자열 값임을 알 수 있습니다. 이 경우 모든 태그(HTML 및 웹 서버 컨트롤)가 제거되었습니다.

대상 웹 사이트에는 원본 파일이 전혀 없으며 그림 4와 같이 Bin 폴더에 웹 UI 콘텐츠 어셈블리가 만들어졌습니다. aspnet_compiler.exe 명령은 Bin 폴더에 .compiled 파일을 생성합니다. 특정 페이지 또는 특정 가상 경로에 대한 요청을 인스턴스화할 클래스를 ASP.NET 나타냅니다.

메모장과 같은 텍스트 편집기에서 .compiled 파일을 열면 파일에 컴파일된 페이지에 대한 참조가 있음을 알 수 있습니다. 이렇게 하면 ASP.NET 파일 구조에서 페이지의 원래 위치를 확인할 수 있습니다. 페이지에서 생성된 컴파일된 출력이 포함된 어셈블리 이름을 볼 수도 있습니다. 어셈블리 이름은 컴파일러에서 자동으로 생성되며 고유성을 보장하는 방식으로 만들어집니다.

참고 배포에 대한 미리 컴파일은 매번 새 빌드를 수행하고 aspnet_compiler.exe 매번 다른 어셈블리 이름을 만듭니다. 또한 어셈블리의 원본으로 사용되는 파일은 빌드에서 빌드로 변경될 수 있습니다. 즉, 변경으로 인해 만들어진 어셈블리를 릴리스 관리에 대해 일관되게 알기 어려울 수 있습니다. – fixednames 옵션의 주된 이유입니다.

그림 3. pswcompile 폴더의 미리 컴파일된 출력

그림 4. pswcompile\Bin 폴더의 미리 컴파일된 출력

고정된 이름으로 미리 컴파일

그림 5와 같이 -fixednames 옵션을 사용하여 웹 사이트를 컴파일한다고 상상해 보세요.

그림 5. -fixednames 옵션을 사용하여 컴파일

-fixednames 옵션을 사용하면 그림 6과 같이 pswcompile\Bin 폴더에 더 많은 어셈블리가 생성됩니다. 각 어셈블리는 하나의 페이지, 사용자 컨트롤 또는 master 페이지를 나타냅니다. 옵션 이름에서 설명한 대로 어셈블리 이름은 빌드에서 빌드까지 동일합니다. App_Web_filetype 형식을 사용하여 어셈블리의 이름을 지정합니다. nnnn.dll 여기서 nnnn 은 해시 값입니다.

그림 6. -fixednames 옵션으로 컴파일한 후 pswcompile\Bin 폴더의 미리 컴파일된 출력

미리 컴파일 - 코드만 제거

배포 가능한 대상 디렉터리(예제의 pswcompile)가 웹 UI 콘텐츠 페이지에 태그를 유지하게 웹 사이트를 미리 컴파일할 수 있습니다. 그림 7은 배포를 위해 미리 컴파일된 웹 사이트를 생성하는 예제 aspnet_compiler.exe 명령을 보여줍니다. 그러면 사이트에서 사이트 페이지를 제한 수정할 수 있습니다. 레이아웃 변경일 수 있지만 이벤트 처리기와 같은 코드가 필요한 컨트롤 ID 변경 또는 새 컨트롤은 제어할 수 없습니다.

그림 7. ASP.NET 페이지 및 사용자 컨트롤에서 태그를 유지하기 위한 aspnet_compiler.exe 실행

그림 8과 9는 pswcompile 폴더와 Bin 폴더의 결과를 보여 줍니다.

그림 8. pswcompile 폴더의 미리 컴파일된 출력

그림 9. pswcompile\Bin 폴더의 미리 컴파일된 출력

그림 8은 이전 컴파일과 마찬가지로 웹 사이트 구조가 유지되었으며 Welcome.html 같은 정적 웹 UI 콘텐츠가 pswcompile 폴더에 복사되었음을 보여 줍니다. 그림 9는 웹 UI 콘텐츠 어셈블리와 App_Code.dll 같은 최상위 어셈블리가 pswcompile\Bin 폴더에 생성되었음을 보여 줍니다.

웹 UI 콘텐츠 페이지 자체를 볼 때 이러한 형식의 미리 컴파일의 차이를 볼 수 있습니다. 그림 9에서는 웹 UI 콘텐츠 페이지 자체가 유지되므로 pswcompile\Bin 폴더에 .compiled 파일이 더 이상 포함되지 않습니다. 이전 컴파일에서처럼 더미 파일 역할을 하는 대신 그림 10과 같이 .aspx 페이지가 다른 어셈블리에서 상속되도록 수정됩니다. 미리 컴파일한 후 페이지는 Bin 폴더에 있는 어셈블리에서 상속되며 이전 codeFile 참조는 제거됩니다.

그림 10. 수정된 는 미리 컴파일된 .aspx 파일에서 특성을 상속합니다 .

고정된 이름으로 미리 컴파일

태그를 유지하고 그림 11에 표시된 구문을 사용하여 고정 이름을 사용하도록 사이트를 미리 컴파일할 수 있습니다. 이전과 마찬가지로 -fixednames 옵션을 사용하면 Bin 디렉터리에 더 많은 어셈블리가 생성됩니다.

그림 11. 웹 UI 콘텐츠 태그를 유지하고 고정 어셈블리 이름을 사용하는 aspnet_compiler.exe 실행

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 사용하여 병합의 조합을 사용할 수 있습니다. 다음 표에서는 각 컴파일 형식을 사용해야 하는 경우와 병합 유틸리티를 사용해야 하는 경우에 대한 패턴을 나열합니다.

시나리오	참고
개발 중: 동적 컴파일을 사용합니다.	ASP.NET 2.0에서 Visual Studio 2005 및 동적 컴파일을 사용합니다. 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 옵션을 생략하면 어셈블리와 더미 페이지만 배포하는 웹 사이트를 만들어 배포된 웹 사이트에서 태그도 제거할 수 있습니다. 폴더의 파일을 변경하려면 폴더 어셈블리와 수정된 페이지를 다시 배포해야 합니다. 테스트 프로세스가 해당 폴더에 대해서만 작동하도록 제한할 수 있는 경우 다른 폴더가 여전히 유효하다고 가정할 수 있습니다. 그러나 실제로 태그 페이지가 이 웹 사이트에 유지되는 경우 Bin 폴더에 새 어셈블리를 추가하면 모든 페이지가 다시 컴파일됩니다. 기본적으로 어셈블리 이름은 폴더 이름을 기반으로 하지만 사용자 지정 이름을 사용하여 어셈블리의 접두사를 지정할 수 있습니다. 이 옵션을 사용할 때 최상위 어셈블리는 영향을 받지 않습니다. 정적 웹 UI 콘텐츠 및 사용자 지정 어셈블리도 영향을 받지 않습니다.
배포의 경우: 모든 웹 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\관리 하위 폴더 각각)를 병합한 결과입니다. Bin 폴더에는 여전히 App_Code.dll 같은 최상위 어셈블리가 포함되어 있습니다. 테마도 컴파일되어 단일 Themes.dll 어셈블리(파란색 원)로 병합되었습니다.

Aspnet_merge.exe aspnet_compiler.exe 명령의 -fixednames 옵션을 사용하거나 사용하지 않고 생성된 어셈블리에서 작업할 수 있습니다. 특정 폴더에 대한 어셈블리 병합을 자동으로 처리합니다.

그림 13. 호환되지 않는 미리 컴파일된 웹 사이트에서 웹 UI 콘텐츠 폴더를 병합한 결과

호환되지 않는 미리 컴파일된 웹 사이트의 경우 컴파일러는 .aspx 파일에 대해 .compiled 파일을 만듭니다. ASP.NET .compiled 파일을 사용하여 웹 요청에 대한 올바른 형식을 인스턴스화합니다. 병합 도구는 이러한 파일을 업데이트하여 병합된 새 어셈블리를 대신 참조합니다. 그림 14는 병합 작업의 .compiled 파일에 미치는 영향을 보여 냅니다.

그림 14. 병합 작업 후 수정된 .compiled 파일

폴더 이름은 병합된 어셈블리를 식별하는 데 사용되므로 웹 사이트의 웹 UI 콘텐츠 파일 집합에 대한 어셈블리를 확인하는 것이 비교적 간단합니다. 그러나 고유한 명명 규칙을 사용할 수 있으므로 aspnet_merge.exe 그림 15와 같이 -prefix 옵션을 사용하여 이러한 어셈블리에 대한 접두사를 지정할 수 있습니다.

그림 15. -prefix 옵션을 사용하여 aspnet_merge.exe 실행

그림 16에서는 -prefix 옵션과 병합한 결과로 만들어진 어셈블리를 보여 주었습니다. 이제 Root.dll 이름이 Contoso.dll Admin.dll 이름이 Contoso.Admin.dll 것을 알 수 있습니다.

그림 16. -prefix 옵션을 사용하여 호환되지 않는 미리 컴파일된 웹 사이트를 병합한 결과

참고 로컬 리소스가 있는 웹 사이트에서 로컬 리소스는 일반적으로 웹 UI 콘텐츠로 처리됩니다. 그러나 병합 도구는 기본적으로 로컬 리소스가 이미 폴더별로 지정되어 있으므로 로컬 리소스를 처리하지 않습니다.

호환 가능한 미리 컴파일된 웹 사이트에서 병합

호환 가능한 미리 컴파일된 웹 사이트에서 어셈블리를 병합하면 호환되지 않는 웹 사이트에서 병합되는 것과 동일한 병합된 출력이 생성됩니다. 차이점은 aspnet_merge.exe .aspx 페이지와 같은 태그 페이지를 수정하여 병합된 어셈블리를 가리킨다는 것입니다. 호환되지 않는 사이트와 마찬가지로 어셈블리는 각 폴더에 대해 생성되고 병합 도구는 동일한 명명 규칙을 적용합니다. 그림 17은 병합 후 예제 사이트의 Bin 폴더를 보여줍니다. 이제 Root.dll(루트 psw 폴더의 웹 UI 콘텐츠에서 발생) 및 Admin.dll(psw\관리 하위 폴더의 웹 UI 콘텐츠에서 발생)의 두 개의 웹 UI 콘텐츠에 대한 어셈블리가 있습니다.

그림 17. 호환 가능한 미리 컴파일된 웹 사이트에서 웹 UI 콘텐츠 폴더를 병합한 결과

그러나 호환 가능한 미리 컴파일된 웹 사이트에 관해서는 몇 가지 미묘한 차이가 있습니다. 미리 컴파일할 수 있는 웹 사이트에서 테마가 컴파일되지 않으므로 테마는 그대로 유지됩니다. 마찬가지로 로컬 리소스는 웹 UI 콘텐츠로 간주되며 수정할 수 있으므로 그대로 유지됩니다. 컴파일러는 .aspx, 에 대한 .compiled 파일을 만들지 않습니다. master 및 .ascx 파일은 애플리케이션에 남아 있습니다. 그러나 병합 프로세스 중에는 그림 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 어셈블리를 결합하는 경우 기본적으로 병합된 집합의 초기 원본 어셈블리에서 최종 병합된 어셈블리로 어셈블리 특성을 전달합니다. 원본 어셈블리는 다른 특성으로 표시될 수 있으므로 병합된 어셈블리에 적용되는 특성을 쉽게 확인할 수 없습니다.

병합된 어셈블리의 특성이 모호하지 않도록 aspnet_merge.exe App_Code 어셈블리에 정의된 어셈블리 특성을 원본 특성 집합으로 사용하거나 지정된 어셈블리를 특성을 정의하는 어셈블리로 사용하도록 지시할 수 있습니다.

예를 들어 그림 23은 그림 1에 표시된 웹 사이트의 App_Code 디렉터리에 추가될 수 있는 Assemblyinfo.cs 파일을 보여 줍니다.

그림 23. assemblyinfo.cs 파일이 App_Code 폴더에 추가됨

어셈블리를 병합하지 않으면 App_Code 어셈블리만 이러한 특성으로 표시됩니다. (Ildasm.exe 같은 도구를 사용하여 어셈블리를 검사하여 이를 볼 수 있습니다.) 병합된 어셈블리를 App_Code 어셈블리에 대해 정의된 특성으로 표시하려면 그림 24와 같이 -copyattrs 옵션을 사용합니다.

그림 24. 최종 병합된 어셈블리에 대해 App_Code 어셈블리에 정의된 특성을 사용하는 aspnet_merge.exe 실행

-copyattrs 옵션을 사용하면 최상위 어셈블리인 App_Code.dll 병합에 포함되지 않은 경우에도 App_Code 어셈블리의 특성이 사용됩니다. 웹 UI 콘텐츠 어셈블리만 병합하는 경우일 수 있습니다. 다음 목록에서는 그림 23에 설명된 명령으로 생성된 Contoso.dll 어셈블리에 대한 IL 매니페스트의 코드 조각을 보여 줍니다.

.assembly Contoso
{
  .... AssemblyFileVersionAttribute:.. =   // ...1.0.4567.0..
  .... AssemblyDescriptionAttribute:.. =   // ...Contoso's Web Site..
  .... AssemblyProductAttribute:.. =       // ...Contoso.Web..
  .... AssemblyCompanyAttribute:.. =       // ...Contoso..
..
  .ver 1:4000:0:0
}

App_Code 어셈블리가 아닌 다른 어셈블리의 특성을 지정하려면 –copyattrs 옵션을 사용하여 어셈블리 이름을 제공합니다. 이 옵션을 사용하는 한 가지 방법은 AssemblyInfo.cs 또는 AssemblyInfo.vb 파일에서 어셈블리를 만든 다음 병합된 어셈블리의 특성을 표시하는 데만 해당 어셈블리를 사용하는 것입니다.

병합된 어셈블리 서명

개발 팀은 다음과 같은 이유로 미리 컴파일된 애플리케이션에 서명할 수 있습니다.

• 어셈블리가 지정된 개발 팀에서 시작된 것으로 확인되도록 합니다. 서명 또는 키는 해당 organization만 사용할 수 있으며 어셈블리가 지정된 회사에서 발생한다는 어느 정도의 확신을 제공합니다.
• 알려진 키로 서명된 어셈블리에 대한 트러스트를 허용하고 인식할 수 없는 키가 있거나 키가 없는 어셈블리에 대한 실행 권한을 허용하지 않는 프로덕션 컴퓨터를 잠그려면.

병합 및 서명된 웹 사이트 어셈블리를 GAC에 추가하여 애플리케이션 간에 공유할 수 있습니다. 그러나 이렇게 하면 리소스 URL 기초(예: 이미지)에 문제가 발생할 수 있습니다. 일반적으로 미리 컴파일되거나 병합된 어셈블리를 GAC에 추가하는 것은 권장되지 않습니다. 외부 리소스를 참조하지 않는 사용자 컨트롤에서 만든 어셈블리와 같은 일부 제한된 상황에서는 GAC에 병합되고 서명된 어셈블리를 추가하는 것이 옵션일 수 있습니다.

aspnet_compiler.exe 사용하여 미리 컴파일된 사이트에서 어셈블리에 서명할 수 있습니다. 그러나 어셈블리를 병합하는 경우 병합 도구를 사용하여 어셈블리에 서명해야 합니다.

미리 컴파일된 웹 사이트를 병합할 때 aspnet_compiler.exe 사용하여 어셈블리가 이미 서명 또는 서명이 지연되었을 수 있습니다. 병합하는 동안 미리 서명된 비트 또는 서명되지 않은 비트에서 병합된 어셈블리에 서명할 수 있습니다. 병합된 어셈블리에 서명하려면 aspnet_merge.exe -keyfile, -keyContainer 또는 -delaysign과 함께 다음 옵션을 사용할 수 있습니다. aspnet_merge.exe 실행하여 미리 서명된 어셈블리를 병합하고 서명 옵션을 제공하지 않으면 결과 어셈블리는 서명되지 않습니다.

다음 명령은 미리 컴파일된 어셈블리를 Contoso.dll 라는 단일 어셈블리에 병합하고 Aspnet_merge.exe 사용하여 어셈블리에 서명하는 방법을 보여 줍니다.

1. 퍼블릭 및 프라이빗 키를 사용하여 키 파일을 만듭니다.

   sn –k contoso.snk 

2. 서명하지 않고 웹 사이트를 미리 컴파일합니다.

   aspnet_compiler -v psw pswcompile

3. 웹 애플리케이션을 병합하고 서명합니다.

   aspnet_merge pswcompile -keyfile contoso.snk -o Contoso

병합된 어셈블리 서명 지연

Aspnet_merge.exe 사용하여 서명을 지연하는 단계는 다음과 같습니다.

1. 퍼블릭 및 프라이빗 키를 사용하여 키 파일을 만듭니다. 일반적으로 제한된 사용자 집합만 액세스할 수 있는 안전한 위치에 퍼블릭 및 프라이빗 키파일을 유지합니다. 구문은 다음과 같습니다.

   sn –k contoso.snk 

2. 해당 파일에서 다른 키 파일로 공개 키를 추출합니다.

   sn –p contoso.snk contosopublicKey.snk

3. 서명하지 않고 웹 사이트를 미리 컴파일합니다.

   aspnet_compiler -v psw pswcompile

4. -delaysign 및 -keyfile 옵션을 지정하여 어셈블리에 병합 및 지연 서명:

   aspnet_merge pswcompile -delaysign -keyfile contosopublicKey.snk -o Contoso

병합된 어셈블리에 APTCA 적용

미리 컴파일된 웹 사이트가 완전 신뢰가 아닌 보안 수준에서 작동하는 경우 aspnet_compile.exe 함께 -aptca 옵션(부분적으로 신뢰할 수 있는 호출자 특성 허용)을 사용하여 어셈블리가 미리 컴파일되었는지 확인해야 합니다. 즉, 적절한 어셈블리 수준 특성이 컴파일된 어셈블리에 추가됩니다. 특성은 aspnet_merge.exe 결과로 병합된 어셈블리에서 유지됩니다.

참고 일부 원본 어셈블리가 전부는 아니지만 AllowPartiallyTrustedCallersAttribute (APTCA)로 표시된 경우 aspnet_merge.exe 원본 어셈블리 특성을 전달하지 않습니다. 대신 예외가 발생합니다. 이렇게 하면 병합된 어셈블리가 원래 의도한 것과 다른 수준의 트러스트를 일부 코드에 제공하지 않습니다. 병합하기 전에 모든 어셈블리가 APTCA로 표시되도록 하거나 -a 옵션과 병합하여 이 동작을 변경할 수 있습니다. 그러나 병합 시 –a 옵션을 사용하면 이전에 APTCA로 표시되지 않은 어셈블리가 이제 해당 특성으로 표시될 수 있습니다. 따라서 이전에는 사용할 수 없었던 어셈블리에서 부분적으로 신뢰할 수 있는 코드를 호출하도록 허용할 수 있습니다.

APTCA를 적용하는 단계는 다음과 같습니다.

1. -aptca 옵션을 사용하여 사이트를 미리 컴파일합니다.

   aspnet_compiler -v psw pswcompile –aptca

2. 어셈블리 병합:

   aspnet_merge pswcompile –o Contoso

병합된 어셈블리 버전 관리

미리 컴파일된 웹 사이트에 대해 생성된 어셈블리에 버전 관리 정보를 추가하려면 다음을 수행할 수 있습니다.

• AssemblyInfo.cs 또는 AssemblyInfo.vb 파일을 App_Code 폴더에 추가합니다. App_Code 폴더에 대해 생성된 어셈블리의 버전이 지정됩니다. 페이지 및 사용자 컨트롤에 대한 코드 숨김 파일에 버전 특성을 추가할 수도 있습니다. 그러나 개별 파일에 버전 특성을 추가하는 것은 지루하며 업데이트 가능한 미리 컴파일 레이아웃의 코드 숨김 파일에만 적용됩니다.
• assemblyInfo.cs 또는 AssemblyInfo.vb 파일에 대한 참조를 Web.config 파일의 컴파일러 요소의 <compilerOptions> 특성에 추가합니다. 이렇게 하면 웹 사이트에 대해 생성된 모든 어셈블리에 대한 버전 관리를 추가할 수 있습니다. 이 경우 프록시를 컴파일할 때 ASP.NET 코드가 아닌 형식 파일(예: WSDL)에 대한 컴파일러를 선택할 수 있으므로 C# 및 Visual Basic 컴파일러를 모두 포함해야 합니다.

Aspnet_merge.exe App_Code 어셈블리에서 특성을 복사하거나 –copyattrs 옵션을 사용하여 지정된 특정 어셈블리에서 복사하여 만든 어셈블리의 버전을 지정할 수 있습니다. 따라서 다른 어셈블리 특성처럼 처리됩니다. 병합된 어셈블리 또는 어셈블리에 대한 특성을 지정하기 위한 이러한 옵션을 사용하면 파일 버전, 어셈블리 버전 및 필요한 다른 어셈블리 특성을 포함하여 모든 버전 특성을 정의할 수 있습니다.

그림 25는 그림 1에 표시된 웹 사이트를 사용하여 App_Code 어셈블리의 특성을 적용하는 데 사용되는 병합 명령을 보여줍니다. 그림 22에 표시된 AssemblyInfo.cs 파일이 웹 사이트의 App_Code 폴더에 추가되었습니다.

그림 25. 최종 병합된 어셈블리에서 App_Code 어셈블리에 정의된 특성을 사용하는 aspnet_merge.exe 실행

다음 목록에서는 이전 명령을 실행할 때 Contoso.dll 적용되는 전체 메타데이터의 조각을 보여 줍니다.

.assembly Contoso
{
  .... AssemblyFileVersionAttribute:.. =  // ...1.0.4567..
  .... AssemblyDescriptionAttribute:.. =  // ..!Contoso Personal Web
// Site Starter Kit..
  .... 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. -d 옵션을 사용하여 aspnet_compiler.exe 실행하여 디버그 출력 만들기

디버그 출력 파일을 병합하려면 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_merge.exe 사용 MSBuild 파일 내에 사용자 지정 작업을 수동으로 추가한 다음 빌드 서버에서 실행할 수 있습니다.
• 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를 열고 웹 사이트를 만든 후에는 솔루션 탐색기 웹 사이트 노드를 마우스 오른쪽 단추로 클릭하고 웹 배포 프로젝트 추가를 선택하여 솔루션에 웹 배포 프로젝트를 추가할 수 있습니다. 솔루션 탐색기 웹 배포 프로젝트를 마우스 오른쪽 단추로 클릭하면 많은 배포 설정을 구성할 수 있는 속성 페이지를 표시할 수 있습니다. Visual Studio 2005 웹 배포 프로젝트를 사용하면 다음을 수행할 수 있습니다.

• aspnet_compiler.exe 옵션을 사용하여 디버그, 릴리스 또는 스테이징 빌드와 같은 여러 빌드 작업을 구성합니다.
• 해당 구성에서 병합 작업을 구성합니다.
• 버전 관리 및 서명을 처리합니다.
• 병합하는 동안 어셈블리 이름을 조작합니다.
• 배포 프로세스의 일부로 Web.config 파일 수정과 같은 추가 작업을 정의합니다.
• 다양한 사용자 지정 시나리오를 가능하게 하는 프로젝트 파일을 직접 수정합니다.
• 개발 시 프로젝트 빌드를 사용하지 않도록 설정하거나 배포 대상을 만들 때 웹 사이트 자체 빌드를 사용하지 않도록 설정합니다.

프로젝트 파일을 수동으로 편집하고 사용자 지정 작업 또는 작업을 빌드 전 및 빌드 후 작업으로 추가할 수도 있습니다. 자세한 내용은 MSDN 웹 사이트에서 Visual Studio 2005에서 웹 배포 프로젝트 사용 문서를 참조하세요.

그림 31은 출력 어셈블리에 대한 옵션을 설정하기 위한 속성 페이지를 보여줍니다.

.

그림 31: Visual Studio 2005 웹 배포 프로젝트의 출력 어셈블리 속성 페이지입니다.

여기서는 aspnet_merge.exe 도구에 사용할 수 있는 옵션에 해당하는 몇 가지 옵션이 있음을 알 수 있습니다.

Aspnet_merge.exe 도움말

이 문서에는 aspnet_merge.exe 대한 많은 옵션이 설명되어 있습니다. -? 옵션을 사용하여 aspnet_merge.exe 실행하여 여기에 설명되지 않은 이러한 항목 및 기타에 대한 추가 도움말을 얻을 수 있습니다.

요약

Aspnet_merge.exe 웹 사이트 프로덕션 환경을 관리하는 데 도움이 되는 새로운 유틸리티입니다. 병합 도구는 웹 사이트를 미리 컴파일할 때 aspnet_compiler.exe ASP.NET 컴파일러에서 생성할 수 있는 수많은 어셈블리를 결합합니다. 이렇게 하면 ASP.NET 컴파일러에서 만든 출력을 사용하는 게시 프로세스 또는 릴리스 관리 프로세스를 보다 쉽게 관리할 수 있습니다.

이 문서에서는 병합 도구와 함께 사용할 수 있는 다양한 옵션에 대해 설명하고 웹 사이트 미리 컴파일과 함께 병합 도구를 사용하는 방법을 설명합니다. 문서의 예제에서는 사용자 지정 빌드 모델에 통합할 수 있는 명령을 보여 줍니다.

Aspnet_merge.exe Visual Studio 2005용 새 웹 배포 프로젝트 추가 기능과 함께 설치됩니다. 이 추가 기능은 aspnet_compiler.exe 및 aspnet_merge.exe 도구에 대한 옵션을 관리하기 위한 포괄적인 UI를 제공하며 Visual Studio 내에서 배포 가능한 웹 사이트 만들기를 관리할 수 있습니다. 웹 배포 프로젝트에는 웹 사이트 배포를 관리하는 데 필요한 빌드 전 및 빌드 후 단계를 추가하는 기능도 포함됩니다.

본 문서는 예비 문서이며, 여기에 설명한 소프트웨어의 최종 상업적 출시 전에 크게 변경될 수 있습니다.

이 문서에 포함된 정보는 게시 날짜 당시 논의된 문제에 대한 Microsoft Corporation의 현재 관점을 나타냅니다. Microsoft는 변화하는 시장 상황에 대응해야 하므로 Microsoft의 약속으로 해석되지 않아야 하며, Microsoft는 게시 날짜 이후 제시된 정보의 정확성을 보증하지 않습니다.

이 백서는 정보 제공만을 목적으로 합니다. Microsoft는 이 문서에 있는 정보에 대한 명시적 또는 묵시적, 법적인 보증을 하지 않습니다.

해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와는 별도로 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나 검색 시스템에 저장 또는 도입되거나 전송될 수 없습니다.

Microsoft는 이 설명서 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권 또는 기타 지적 재산권 등에 대한 어떠한 사용권도 허용하지 않습니다.

다른 설명이 없는 한, 여기에 사용된 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 이벤트는 가공된 것이며 실제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와 연결하기 위한 의도가 없으며 그러한 것으로 유추해서도 안 됩니다.

© 2005 Microsoft Corporation. All rights reserved.

© Microsoft Corporation. All rights reserved.