ASP.NET 컴파일 도구(Aspnet_compiler.exe)

아티클
10/15/2014

ASP.NET 컴파일 도구(Aspnet_compiler.exe)를 사용하면 ASP.NET 웹 응용 프로그램을 현재 위치에서 컴파일하거나 배포용으로 프로덕션 서버와 같은 대상 위치에서 컴파일할 수 있습니다. 내부 컴파일을 수행하면 응용 프로그램이 컴파일되는 동안 최종 사용자가 응용 프로그램에 대한 첫 번째 요청에서 지연을 겪지 않으므로 응용 프로그램 성능에 도움이 됩니다. 배포용 컴파일은 코드 숨김 및 태그 파일과 같은 모든 소스 파일을 제거하는 방법 또는 태그 파일을 보존하는 방법 중 한 가지로 수행할 수 있습니다.

참고

Aspnet_compiler.exe의 올바른 버전을 찾는 방법에 대한 자세한 내용은 이 항목의 뒷부분에 나오는 올바른 버전의 Aspnet_compiler.exe 찾기를 참조하십시오.

aspnet_compiler  [-?]
                 [-m metabasePath | -v virtualPath [-p physicalPath]]
                 [[-u] [-f] [-d] [-fixednames] targetDir]
                 [-c]
                 [-errorstack]
                 [-nologo]
                 [[-keyfile file | -keycontainer container ] [-aptca] [-delaysign]]

옵션

Option	설명
-m metabasePath	컴파일할 응용 프로그램의 IIS 메타베이스 전체 경로를 지정합니다. IIS 메타베이스는 IIS 구성에 사용되는 계층적 정보 저장소입니다. 예를 들어, 기본 IIS 웹 사이트의 메타베이스 경로는 LM/W3SVC/1/ROOT입니다. 이 옵션은 -v 또는 -p 옵션과 함께 사용할 수 없습니다.
-v virtualPath	컴파일할 응용 프로그램의 가상 경로를 지정합니다. -p 옵션도 지정된 경우에는 컴파일할 응용 프로그램을 찾는 데 physicalPath 매개 변수의 값이 함께 사용됩니다. 그렇지 않으면 IIS 메타베이스가 사용되며, 이 도구는 소스 파일이 LM/W3SVC/1/ROOT 메타베이스 노드에 지정된 기본 웹 사이트에 있다고 가정합니다. 이 옵션은 -m 옵션과 함께 사용할 수 없습니다.
-p physicalPath	컴파일할 응용 프로그램이 들어 있는 루트 디렉터리의 전체 네트워크 경로 또는 로컬 디스크 경로를 지정합니다. -p 옵션을 지정하지 않으면 디렉터리를 찾을 때 IIS 메타베이스가 사용됩니다. 이 옵션은 -v 옵션과 함께 사용해야 하며, -m 옵션과는 함께 사용할 수 없습니다.
-u	Aspnet_compiler.exe에서 .aspx 페이지처럼 이후에 콘텐츠를 업데이트할 수 있는 미리 컴파일된 응용 프로그램을 만들도록 지정합니다. 이 옵션을 생략하면 결과 응용 프로그램은 컴파일된 파일만 포함하므로 배포 서버에서 업데이트될 수 없습니다. 응용 프로그램을 업데이트하려면 소스 태그 파일을 변경하고 다시 컴파일해야 합니다. targetDir 매개 변수가 포함되어야 합니다. 이 옵션을 사용하면 .aspx 파일에 있는 코드 블록(즉, script 요소에 또는 <% 및 %> 태그 사이에 있는 코드)은 컴파일되지 않습니다. 따라서 코드 블록에 컴파일 오류가 있는 경우 런타임에서만 .aspx 파일이 완전히 컴파일되기 때문에 런타임에서만 오류가 확인됩니다. .aspx 파일에 있는 코드 블록을 이용하는 사이트에 대해 이 옵션을 사용하는 것은 일반적으로 안전하지 않습니다.
-f	도구에서 targetDir 디렉터리와 하위 디렉터리의 기존 파일을 덮어쓰도록 지정합니다.
-d	응용 프로그램의 소스 구성 파일에 정의된 설정을 재정의하여 컴파일된 응용 프로그램에 디버그 정보가 반드시 포함되도록 합니다. 그렇지 않으면 어떤 디버그 출력도 수행되지 않습니다. 내부 컴파일에는 -d 옵션을 사용할 수 없습니다. 내부 컴파일에서는 디버깅 옵션에 대한 구성 설정을 부여합니다.
targetDir	컴파일된 응용 프로그램이 저장될 루트 디렉터리의 네트워크 경로 또는 로컬 디스크 경로입니다. targetDir 매개 변수가 포함되지 않으면 응용 프로그램은 현재 위치에서 컴파일됩니다.
-c	컴파일할 응용 프로그램 전체가 다시 빌드되도록 지정합니다. 이미 컴파일된 구성 요소는 다시 컴파일됩니다. 이 옵션을 생략하면 이 도구는 응용 프로그램 중에서 마지막으로 컴파일이 수행된 이후 수정된 부분만 빌드합니다.
-errorstack	이 도구에서 응용 프로그램 컴파일에 실패할 경우 스택 추적 정보가 포함되도록 지정합니다.
-keyfile file	AssemblyKeyFileAttribute가 컴파일된 어셈블리에 적용되도록 지정합니다. 이 특성은 강력한 이름을 생성하는 데 사용되는 공개/개인 키 쌍이 있는 파일의 이름을 나타냅니다. 이 옵션은 -aptca 옵션과 함께 사용해야 합니다. 이 특성이 코드 파일의 어셈블리에 이미 적용되었으면 Aspnet_compiler.exe는 예외를 throw합니다.
-keycontainer container	AssemblyKeyNameAttribute가 컴파일된 어셈블리에 적용되도록 지정합니다. 이 특성은 강력한 이름을 생성하는 데 사용되는 공개/개인 키 쌍의 컨테이너 이름을 나타냅니다. 이 옵션은 -aptca 옵션과 함께 사용해야 합니다. 이 특성이 코드 파일의 어셈블리에 이미 적용되었으면 Aspnet_compiler.exe는 예외를 throw합니다.
-aptca	AllowPartiallyTrustedCallersAttribute가 Aspnet_compiler.exe에서 생성하는 강력한 이름의 어셈블리에 적용되도록 지정합니다. 이 특성은 부분적으로 신뢰할 수 있는 호출자가 어셈블리에 액세스하도록 허용합니다. 이 옵션은 -keyfile 또는 -keycontainer 옵션과 함께 사용해야 합니다. 이 특성이 코드 파일의 어셈블리에 이미 적용되었으면 Aspnet_compiler.exe는 예외를 throw합니다.
-delaysign	AssemblyDelaySignAttribute가 생성된 어셈블리에 적용되도록 지정합니다. 이 특성은 어셈블리가 공개/개인 키 쌍이 아니라 공개 키 토큰으로만 서명되는 경우를 나타냅니다. 이 옵션은 -keyfile 또는 -keycontainer 옵션과 함께 사용해야 합니다. 이 특성이 코드 파일의 어셈블리에 이미 적용되었으면 Aspnet_compiler.exe는 예외를 throw합니다. -delaysign 옵션을 사용하면 Aspnet_compilier.exe에서 생성된 코드를 서명 전에 실행할 수 있습니다. 서명이 완료되기 전에는 코드가 악의적인 사용자로부터 공격을 받지 않도록 해야 합니다.
-fixednames	응용 프로그램의 각 페이지마다 하나의 어셈블리가 생성되도록 지정합니다. 각 어셈블리는 원래 페이지의 가상 경로로 명명됩니다. 이때 운영 체제의 파일 이름 제한을 초과하지 않아야 하며, 초과할 경우에는 해시가 생성되어 어셈블리 이름으로 사용됩니다. 내부 컴파일에는 -fixednames 옵션을 사용할 수 없습니다. 내부 컴파일에서는 컴파일 일괄 처리 모드에 대한 구성 설정을 부여합니다.
-nologo	저작권 메시지를 표시하지 않습니다.
-?	이 도구의 명령 구문 및 옵션을 표시합니다.

설명

ASP.NET 컴파일 도구는 두 가지 버전이 있습니다.

.NET Framework 2.0에 제공되는 버전. .NET Framework 2.0 CLR과 관련된 응용 프로그램 풀에 배포되는 웹 응용 프로그램에 이 버전을 사용합니다. 웹 응용 프로그램은 .NET Framework 2.0, .NET Framework 3.0 또는 .NET Framework 3.5를 대상으로 할 수 있습니다.
.NET Framework 4에 제공되는 버전. .NET Framework 4 CLR과 관련된 응용 프로그램 풀에 배포되는 웹 응용 프로그램에 이 버전을 사용합니다. 웹 응용 프로그램은 .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5 또는 .NET Framework 4을 대상으로 할 수 있습니다. 이 버전이 .NET Framework 2.0, .NET Framework 3.0 또는 .NET Framework 3.5를 대상으로 하는 웹 사이트에 사용되면 .NET Framework 2.0 버전과 비교하여 개선된 오류 보고 기능을 제공합니다.

.NET Framework의 특정 버전을 대상으로 하는 웹 사이트를 개발하고 컴파일하고 배포하는 방법에 대한 자세한 내용은 ASP.NET 웹 프로젝트에 대한 .NET Framework 다중 대상 지정 및 ASP.NET Side-by-Side 실행 개요를 참조하십시오. ASP.NET 컴파일 도구가 웹 사이트가 대상으로 하는 .NET Framework 버전을 확인하는 방법에 대한 자세한 내용은 BuildManager.TargetFramework 속성을 참조하십시오.

ASP.NET 컴파일 도구는 일반적으로 내부 컴파일과 배포용 컴파일의 두 가지 용도로 사용될 수 있습니다. 배포용 컴파일에서는 대상 출력 디렉터리가 지정됩니다. 다음 단원에서는 이러한 시나리오에 대해 설명합니다.

현재 위치에서 응용 프로그램 컴파일

ASP.NET 컴파일 도구는 현재 위치에서 응용 프로그램을 컴파일할 수 있습니다. 즉, 응용 프로그램에 대한 여러 요청을 수행하는 동작을 모방하여 정규 컴파일을 이끌어냅니다. 미리 컴파일된 사이트의 사용자는 처음 요청에서 페이지 컴파일로 인한 지연을 겪지 않습니다.

가장된 계정을 사용하는 경우에는 해당 계정과 로그온 사용자 계정이 모두 대상에 대한 쓰기 권한을 갖고 있어야 응용 프로그램을 미리 컴파일할 수 있습니다.

현재 위치에서 사이트를 미리 컴파일할 경우 다음 항목이 적용됩니다.

사이트는 파일 및 디렉터리 구조를 유지합니다.
모든 프로그래밍 언어의 컴파일러가 서버에 있는 사이트에서 사용되어야 합니다.
컴파일이 실패한 파일이 있으면 사이트 전체의 컴파일이 실패합니다.

새 소스 파일을 응용 프로그램에 추가한 다음 이 응용 프로그램을 현재 위치에서 다시 컴파일할 수도 있습니다. -c 옵션을 포함하지 않으면 새 파일이나 변경된 파일만 컴파일됩니다.

참고

중첩된 응용 프로그램이 포함된 응용 프로그램을 컴파일하더라도 중첩된 응용 프로그램은 컴파일되지 않습니다.중첩된 응용 프로그램은 별도로 컴파일해야 합니다.

참고

마스터 페이지가 포함된 웹 응용 프로그램을 컴파일하는 경우 응용 프로그램을 업데이트 가능한 사이트로 컴파일하면 컴파일에 실패하고 이름이 충돌합니다.마스터 페이지의 이름이 마스터 페이지에서 파생된 콘텐츠 페이지의 네임스페이스 이름과 일치하면 충돌이 발생할 수 있습니다.이러한 상속 관계는 @ Page 지시문의 Inherits 특성에 따라 설정됩니다.이 문제를 해결하려면 마스터 페이지의 클래스 이름 또는 네임스페이스 이름을 변경하거나 응용 프로그램을 업데이트할 수 없는 사이트로 컴파일합니다.

참고

.NET Framework 4 버전의 도구를 사용하여 웹 사이트를 제 위치에서 미리 컴파일하고 사이트가 .NET Framework의 이전 버전을 대상으로 하며 .NET Framework 2.0 CLR을 대상으로 하는 응용 프로그램 풀에 연결된 경우 처음 웹 응용 프로그램을 요청하면 사이트가 미리 컴파일되지 않은 것처럼 동적 컴파일이 발생합니다.그 이유는 명령줄 컴파일러가 .NET Framework 2.0 CLR에서 인식하지 못하는 .NET Framework 4 임시 폴더로 컴파일하기 때문입니다.

배포용으로 응용 프로그램 컴파일

targetDir 매개 변수를 지정하여 응용 프로그램을 배포용으로(대상 위치로) 컴파일합니다. targetDir가 웹 응용 프로그램의 최종 위치가 될 수 있으며, 또는 컴파일된 응용 프로그램을 다시 배포할 수도 있습니다.

-u 옵션을 사용하면 컴파일된 응용 프로그램을 다시 컴파일하지 않고 일부 파일만 변경하여 응용 프로그램을 컴파일할 수 있습니다. Aspnet_compiler.exe는 정적 파일 형식과 동적 파일 형식을 구분하며, 결과 응용 프로그램을 만들 때 이러한 형식을 구분해서 처리합니다.

정적 파일 형식은 연관된 컴파일러나 빌드 공급자가 없는 파일 형식을 의미하며 .css, .gif, .htm, .html, .jpg, .js 등과 같은 확장명을 갖습니다. 이러한 파일은 대상 위치에 복사될 뿐이며 디렉터리 구조에서의 상대적 위치는 보존됩니다.

동적 파일 형식은 연관된 컴파일러나 빌드 공급자가 있는 파일 형식이며 .asax, .ascx, .ashx, .aspx, .browser, .master 등과 같은 ASP.NET 특정 파일 확장명을 갖는 파일이 여기에 포함됩니다. ASP.NET 컴파일 도구는 이러한 파일에서 어셈블리를 생성합니다. -u 옵션을 생략하면 확장명이 .COMPILED인 파일도 생성됩니다. 이 파일은 원래의 소스 파일을 해당 어셈블리로 매핑합니다. 응용 프로그램 소스의 디렉터리 구조가 보존되도록 하기 위해 이 도구에서는 대상 응용 프로그램의 해당 위치에 자리 표시자 파일을 생성합니다.

컴파일된 응용 프로그램의 콘텐츠 수정 가능을 나타내려면 -u 옵션을 사용해야 합니다. 그렇지 않으면 이후 수정된 사항은 무시되거나 런타임 오류를 발생시킵니다.

다음 표에서는 -u 옵션이 포함된 경우에 ASP.NET 컴파일 도구에서 각기 다른 파일 형식을 처리하는 방법에 대해 설명합니다.

파일 형식	컴파일러 작업
.ascx, .aspx, .master	이러한 파일은 태그 코드와 소스 코드로 구분되는데 여기에는 코드 숨김 파일이 포함됩니다. 소스 코드는 해싱 알고리즘에서 파생된 이름을 갖는 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 인라인 코드, 즉 <script runat="server"> 요소로 묶인 코드는 태그에 포함되며 컴파일되지 않습니다. 태그를 포함할 새 파일이 소스 파일과 동일한 이름으로 만들어져 해당 출력 디렉터리에 저장됩니다.
.ashx, .asmx	이러한 파일은 컴파일되지 않으며 컴파일되지 않은 상태 그대로 출력 디렉터리로 옮겨집니다. 처리기 코드를 컴파일하려면 코드를 App_Code 디렉터리의 소스 코드 파일에 옮겨 놓습니다.
.cs, .vb, .jsl, .cpp 앞서 나열된 파일 형식에서 코드 숨김 파일은 제외됩니다.	이러한 파일은 컴파일되며 이 파일을 참조하는 어셈블리에 리소스 형태로 포함됩니다. 소스 파일은 출력 디렉터리에 복사되지 않습니다. 참조되지 않는 코드 파일은 컴파일되지 않습니다.
사용자 지정 파일 형식	이러한 파일은 컴파일되지 않습니다. 이러한 파일은 해당 출력 디렉터리에 복사됩니다.
App_Code 하위 디렉터리의 소스 코드 파일	이러한 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 참고 App_Code 디렉터리의 정적 파일 형식은 출력 디렉터리로 복사되지 않습니다.
App_GlobalResources 하위 디렉터리의 .resx 및 .resource 파일	이러한 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 주 출력 디렉터리에는 App_GlobalResources 하위 디렉터리가 만들어지지 않습니다. 참고 App_Code 하위 디렉터리의 코드가 컴파일되기 전에 App_GlobalResources 하위 디렉터리의 리소스 파일이 어셈블리로 컴파일됩니다.컴파일 후에는 리소스 파일을 수정할 수 없습니다.
App_LocalResources 하위 디렉터리의 .resx 및 .resource 파일	이러한 파일은 컴파일되지 않으며 해당 출력 디렉터리에 복사됩니다.
App_Themes 하위 디렉터리의 .skin 파일	.skin 파일 및 정적 테마 파일은 컴파일되지 않으며 해당 출력 디렉터리에 복사됩니다.
.browser Web.config 정적 파일 형식 Bin 디렉터리에 이미 존재하는 어셈블리	이러한 파일은 현재 상태로 출력 디렉터리에 복사됩니다.

다음 표에서는 -u 옵션이 생략된 경우에 ASP.NET 컴파일 도구에서 각기 다른 파일 형식을 처리하는 방법에 대해 설명합니다.

참고

컴파일된 응용 프로그램의 소스 코드를 수정하지 못하도록 하는 경고가 발생되지 않습니다.

파일 형식	컴파일러 작업
.aspx, .asmx, .ashx, .master	이러한 파일은 태그 코드와 소스 코드로 구분되는데 여기에는 코드 숨김 파일과 <script runat="server"> 요소로 묶인 모든 코드가 포함됩니다. 소스 코드는 해싱 알고리즘에서 파생된 이름을 갖는 어셈블리로 컴파일됩니다. 결과 어셈블리는 Bin 디렉터리에 저장됩니다. 인라인 코드, 즉 <% 및 %> 괄호로 묶인 코드는 태그에 포함되며 컴파일되지 않습니다. 컴파일러는 소스 파일과 동일한 이름으로 태그를 포함할 새 파일을 만듭니다. 이러한 결과 파일은 Bin 디렉터리에 저장됩니다. 또한 컴파일러는 매핑 정보를 포함하는 .COMPILED 확장명을 갖는 파일을 만듭니다. 이 파일의 이름은 소스 파일과 동일합니다. .COMPILED 파일은 소스 파일의 원래 위치에 맞게 출력 디렉터리에 저장됩니다.
.ascx	이러한 파일은 태그 코드와 소스 코드로 구분됩니다. 소스 코드는 해싱 알고리즘에서 파생된 이름을 갖는 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 태그 파일은 생성되지 않습니다.
.cs, .vb, .jsl, .cpp 앞서 나열된 파일 형식에서 코드 숨김 파일은 제외됩니다.	.ascx, .ashx 또는 .aspx 파일에서 생성된 어셈블리에서 참조되는 소스 코드는 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 소스 파일은 복사되지 않습니다.
사용자 지정 파일 형식	이러한 파일은 동적 파일처럼 컴파일됩니다. 기반이 되는 파일 형식에 따라 컴파일러는 출력 디렉터리에 매핑 파일을 둘 수 있습니다.
App_Code 하위 디렉터리의 파일	이 하위 디렉터리의 소스 코드 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 참고 App_Code 디렉터리의 정적 파일 형식은 출력 디렉터리로 복사되지 않습니다.
App_GlobalResources 하위 디렉터리의 파일	이러한 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. 주 출력 디렉터리에는 App_GlobalResources 하위 디렉터리가 만들어지지 않습니다. 구성 파일에서 appliesTo="All"을 지정한 경우 .resx 및 .resources 파일은 출력 디렉터리로 복사됩니다. 이러한 파일이 BuildProvider에서 참조되면 복사되지 않습니다.
App_LocalResources 하위 디렉터리의 .resx 및 .resource 파일	이러한 파일은 고유한 이름을 갖는 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. .resx 또는 .resource 파일은 출력 디렉터리에 복사되지 않습니다.
App_Themes 하위 디렉터리의 .skin 파일	테마는 어셈블리로 컴파일되어 Bin 디렉터리에 저장됩니다. .skin 파일에 대해 스텁 파일이 만들어져 해당 출력 디렉터리에 저장됩니다. .css와 같은 정적 파일은 출력 디렉터리에 복사됩니다.
.browser Web.config 정적 파일 형식 Bin 디렉터리에 이미 존재하는 어셈블리	이러한 파일은 현재 상태로 출력 디렉터리에 복사됩니다.

고정 어셈블리 이름

MSI Windows 설치 프로그램을 사용하여 웹 응용 프로그램을 배포하는 경우와 같은 일부 시나리오에서는 업데이트할 어셈블리 또는 구성 설정을 식별하기 위해 일관된 파일 이름과 내용 그리고 일관된 디렉터리 구조를 사용해야 합니다. 이러한 경우 -fixednames 옵션을 사용하여 ASP.NET 컴파일 도구에서 여러 페이지가 어셈블리로 컴파일되는 방법을 사용하지 않고 소스 파일마다 어셈블리를 컴파일하도록 지정할 수 있습니다. 이 경우 많은 수의 어셈블리가 만들어질 수 있으므로 확장성을 고려하는 경우에는 이 옵션을 주의해서 사용해야 합니다.

강력한 이름의 컴파일

-aptca, -delaysign, -keycontainer 및 -keyfile 옵션을 사용하여 Sn.exe(강력한 이름 도구)를 별도로 사용하지 않고 Aspnet_compiler.exe로 강력한 이름의 어셈블리를 만들 수 있습니다. 이러한 옵션은 각각 AllowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute 및 AssemblyKeyFileAttribute에 해당됩니다. 각 옵션은 컴파일된 어셈블리와 일치하는 특성을 적용하고 이 특성은 AllowMultiple 속성이 false로 설정된 AttributeUsageAttribute로 표시되므로, 이미 그 특성 중 하나로 표시된 소스 코드에서 이 키를 사용하면 컴파일이 실패합니다.

연결된 ASP.NET 클래스

System.Web.Compilation 네임스페이스의 일부 클래스는 IIS 외부 환경에서 코드가 Aspnet_compiler.exe를 액세스하거나 호출하도록 할 수 있습니다. ClientBuildManager 클래스는 응용 프로그램을 컴파일하도록 PrecompileApplication 메서드를 제공합니다. 또한 ClientBuildManager 클래스는 ClientBuildManagerParameter 클래스와 함께 사용하여 이 도구에서 사용되는 옵션과 일치하는 PrecompilationFlags를 지정할 수 있으며, 마찬가지로 강력한 이름 키를 지정할 수 있습니다.

예제

다음 명령은 WebApplication1 응용 프로그램을 현재 위치에서 컴파일합니다.

Aspnet_compiler -v /WebApplication1

다음 명령은 WebApplication1 응용 프로그램을 내부에서 컴파일하며 해당 도구에서는 오류를 보고해야 할 경우 스택 추적 정보를 추가합니다.

Aspnet_compiler -v /WebApplication1 -errorstack

다음 명령은 실제 디렉터리 경로를 사용하여 WebApplication1 응용 프로그램을 배포용으로 컴파일합니다. 또한 출력 어셈블리에 두 가지 특성을 추가합니다. -keyfile 옵션을 사용하여 AssemblyKeyFileAttribute 특성을 추가합니다. 이 특성은 생성된 어셈블리에 강력한 이름을 제공하기 위해 도구에서 사용할 공개/개인 키 쌍 정보가 Key.sn 파일에 포함되도록 지정합니다. 또한 이 명령은 -aptca 옵션을 사용하여 AllowPartiallyTrustedCallersAttribute 특성을 생성된 어셈블리에 추가합니다. 컴파일된 웹 응용 프로그램은 c:\applicationTarget 디렉터리에 만들어집니다.

Aspnet_compiler -v /WebApplication1 -p "c:\Documents and Settings\Default\My Documents\MyWebApplications\WebApplication1" -keyfile "c:\Documents and Settings\Default\My Documents\Key.sn" -aptca c:\applicationTarget

다음 명령은 기본 메타베이스 경로에서 WebService2 서비스를 컴파일하여 SampleWebService 대상 디렉터리를 컴파일된 응용 프로그램으로 덮어씁니다.

Aspnet_compiler -m /LM/W3SVC/1/ROOT/WebService2 -f c:\InetPub\wwwroot\SampleWebService

올바른 버전의 Aspnet_compiler.exe 찾기

Aspnet_compiler.exe 도구는 Microsoft.NET Framework 디렉터리에 설치됩니다. 컴퓨터에 여러 .NET Framework 버전이 함께 실행 중인 경우 도구의 여러 버전을 설치할 수 있습니다. 다음 표에는 서로 다른 버전의 .NET Framework에 대한 도구가 설치되는 위치가 나와 있습니다.

.NET Framework 버전	Aspnet_compiler.exe 파일 위치
.NET Framework 버전 2.0, 버전 3.0 및 버전 3.5(32비트 시스템)	%windir%\Microsoft.NET\Framework\v2.0.50727
.NET Framework 버전 2.0, 버전 3.0 및 버전 3.5(64비트 시스템)	%windir%\Microsoft.NET\Framework64\v2.0.50727
.NET Framework 버전 4(32비트 시스템)	%windir%\Microsoft.NET\Framework\v4.0.30319
.NET Framework 버전 4(64비트 시스템)	%windir%\Microsoft.NET\Framework64\v4.0.30319

참고 항목

다음을 통해 공유