참고
이 문서가 작성된 이후 ASP.NET 멤버 자격 공급자는 ASP.NET ID로 대체되었습니다. 이 문서를 작성할 때 추천한 멤버 자격 공급자가 아닌 ASP.NET ID 플랫폼을 사용하도록 앱을 업데이트하는 것이 좋습니다. ASP.NET ID는 를 포함하여 ASP.NET 멤버 자격 시스템에 비해 여러 가지 이점이 있습니다.
- 성능 향상
- 향상된 확장성 및 테스트 가능성
- OAuth, OpenID Connect 및 2단계 인증 지원
- 클레임 기반 ID 지원
- ASP.Net Core와의 상호 운용성 향상
ASP.NET 2.0에서는 구성 및 계측에 큰 변화가 있습니다. 새 ASP.NET 구성 API를 사용하면 구성을 프로그래밍 방식으로 변경할 수 있습니다. 또한 많은 새 구성 설정이 존재하여 새 구성 및 계측을 허용합니다.
ASP.NET 2.0에서는 구성 및 계측에 큰 변화가 있습니다. 새 ASP.NET 구성 API를 사용하면 구성을 프로그래밍 방식으로 변경할 수 있습니다. 또한 많은 새 구성 설정이 존재하여 새 구성 및 계측을 허용합니다.
이 모듈에서는 ASP.NET 구성 파일에서 읽고 쓰는 것과 관련된 구성 API ASP.NET 대해 설명하고 ASP.NET 계측도 다룹니다. ASP.NET 추적에서 사용할 수 있는 새로운 기능도 다룹니다.
ASP.NET 구성 API
ASP.NET 구성 API를 사용하면 단일 프로그래밍 인터페이스를 사용하여 애플리케이션 구성 데이터를 개발, 배포 및 관리할 수 있습니다. 구성 API를 사용하여 구성 파일에서 XML을 직접 편집하지 않고 전체 ASP.NET 구성을 프로그래밍 방식으로 개발하고 수정할 수 있습니다. 또한 개발한 콘솔 애플리케이션 및 스크립트, 웹 기반 관리 도구 및 MMC(Microsoft Management Console) 스냅인에서 구성 API를 사용할 수 있습니다.
다음 두 구성 관리 도구는 구성 API를 사용하며 .NET Framework 버전 2.0에 포함되어 있습니다.
- ASP.NET MMC 스냅인은 구성 API를 사용하여 관리 작업을 간소화하고 모든 수준의 구성 계층에서 로컬 구성 데이터의 통합 보기를 제공합니다.
- 웹 사이트 관리 도구를 사용하면 호스트된 사이트를 포함하여 로컬 및 원격 애플리케이션에 대한 구성 설정을 관리할 수 있습니다.
ASP.NET 구성 API는 웹 사이트 및 애플리케이션을 프로그래밍 방식으로 구성하는 데 사용할 수 있는 ASP.NET 관리 개체 집합으로 구성됩니다. 관리 개체는 .NET Framework 클래스 라이브러리로 구현됩니다. 구성 API 프로그래밍 모델은 컴파일 시간에 데이터 형식을 적용하여 코드 일관성과 안정성을 보장하는 데 도움이 됩니다. 애플리케이션 구성을 보다 쉽게 관리할 수 있도록 구성 API를 사용하면 데이터를 다른 구성 파일의 별도 컬렉션으로 보는 대신 구성 계층의 모든 지점에서 병합된 데이터를 단일 컬렉션으로 볼 수 있습니다. 또한 구성 API를 사용하면 구성 파일에서 XML을 직접 편집하지 않고도 전체 애플리케이션 구성을 조작할 수 있습니다. 마지막으로 API는 웹 사이트 관리 도구와 같은 관리 도구를 지원하여 구성 작업을 간소화합니다. 구성 API는 컴퓨터에서 구성 파일 만들기를 지원하고 여러 컴퓨터에서 구성 스크립트를 실행하여 배포를 간소화합니다.
참고
구성 API는 IIS 애플리케이션 만들기를 지원하지 않습니다.
로컬 및 원격 구성 설정 작업
Configuration 개체는 컴퓨터와 같은 특정 물리적 엔터티 또는 애플리케이션 또는 웹 사이트와 같은 논리 엔터티에 적용되는 구성 설정의 병합된 보기를 나타냅니다. 지정된 논리 엔터티는 로컬 컴퓨터 또는 원격 서버에 있을 수 있습니다. 지정된 엔터티에 대한 구성 파일이 없으면 Configuration 개체는 Machine.config 파일에 정의된 기본 구성 설정을 나타냅니다.
다음 클래스에서 열린 구성 메서드 중 하나를 사용하여 Configuration 개체를 가져올 수 있습니다.
- 엔터티가 클라이언트 애플리케이션인 경우 ConfigurationManager 클래스입니다.
- 엔터티가 웹 애플리케이션인 경우 WebConfigurationManager 클래스입니다.
이러한 메서드는 Configuration 개체를 반환하며, 이 개체는 기본 구성 파일을 처리하는 데 필요한 메서드와 속성을 제공합니다. 읽기 또는 쓰기를 위해 이러한 파일에 액세스할 수 있습니다.
읽는 중
GetSection 또는 GetSectionGroup 메서드를 사용하여 구성 정보를 읽습니다. 읽는 사용자 또는 프로세스에는 계층 구조의 모든 구성 파일에 대한 읽기 권한이 있어야 합니다.
참고
path 매개 변수를 사용하는 정적 GetSection 메서드를 사용하는 경우 path 매개 변수는 코드가 실행 중인 애플리케이션을 참조해야 합니다. 그렇지 않으면 매개 변수가 무시되고 현재 실행 중인 애플리케이션에 대한 구성 정보가 반환됩니다.
쓰기
Save 메서드 중 하나를 사용하여 구성 정보를 작성합니다. 작성하는 사용자 또는 프로세스에는 현재 구성 계층 수준의 구성 파일 및 디렉터리에 대한 쓰기 권한과 계층 구조의 모든 구성 파일에 대한 읽기 권한이 있어야 합니다.
지정된 엔터티에 대한 상속된 구성 설정을 나타내는 구성 파일을 생성하려면 다음 저장 구성 방법 중 하나를 사용합니다.
- 새 구성 파일을 만드는 Save 메서드입니다.
- 다른 위치에서 새 구성 파일을 생성하는 SaveAs 메서드입니다.
구성 클래스 및 네임스페이스
많은 구성 클래스와 메서드가 서로 비슷합니다. 다음 표에서는 가장 일반적으로 사용되는 구성 클래스 및 네임스페이스에 대해 설명합니다.
| 구성 클래스 또는 네임스페이스 | 설명 |
|---|---|
| System.Configuration 네임스페이스 | 모든 .NET Framework 애플리케이션에 대한 기본 구성 클래스를 포함합니다. 섹션 처리기 클래스는 GetSection 및 GetSectionGroup과 같은 메서드에서 섹션에 대한 구성 데이터를 가져오는 데 사용됩니다. 이러한 두 메서드는 비정적입니다. |
| System.Configuration.Configuration 클래스 | 컴퓨터, 애플리케이션, 웹 디렉터리 또는 기타 리소스에 대한 구성 데이터 집합을 나타냅니다. 이 클래스에는 구성 설정을 업데이트하고 섹션 및 섹션 그룹에 대한 참조를 얻기 위한 GetSection 및 GetSectionGroup과 같은 유용한 메서드가 포함되어 있습니다. 이 클래스는 WebConfigurationManager 및 ConfigurationManager 클래스의 메서드와 같은 디자인 타임 구성 데이터를 가져오는 메서드의 반환 형식으로 사용됩니다. |
| System.Web.Configuration 네임스페이스 | ASP.NET 구성 설정에 정의된 ASP.NET 구성 섹션에 대한 섹션 처리기 클래스 를 포함합니다. 섹션 처리기 클래스는 GetSection 및 GetSectionGroup과 같은 메서드에서 섹션에 대한 구성 데이터를 가져오는 데 사용됩니다. |
| System.Web.Configuration.WebConfigurationManager 클래스 | 런타임 및 디자인 타임 구성 설정에 대한 참조를 가져오는 데 유용한 방법을 제공합니다. 이러한 메서드는 System.Configuration.Configuration 클래스를 반환 형식으로 사용합니다. 이 클래스의 정적 GetSection 메서드 또는 System.Configuration.ConfigurationManager 클래스의 비정적 GetSection 메서드를 서로 바꿔 사용할 수 있습니다. 웹 애플리케이션 구성의 경우 System.Configuration.ConfigurationManager 클래스 대신 System.Web.Configuration.WebConfigurationManager 클래스를 사용하는 것이 좋습니다. |
| System.Configuration.Provider 네임스페이스 | 구성 공급자를 사용자 지정하고 확장하는 방법을 제공합니다. 구성 시스템의 모든 공급자 클래스에 대한 기본 클래스입니다. |
| System.Web.Management 네임스페이스 | 웹 애플리케이션의 상태를 관리하고 모니터링하는 데 사용할 수 있는 클래스와 인터페이스가 포함되어 있습니다. 엄밀히 말하면 이 네임스페이스는 구성 API의 일부로 간주되지 않습니다. 예를 들어 추적 및 이벤트 발생은 이 네임스페이스의 클래스에 의해 수행됩니다. |
| System.Management.Instrumentation 네임스페이스 | 애플리케이션 계측이 WMI(Windows Management Instrumentation)를 통해 관리 정보 및 이벤트를 잠재적 소비자에게 노출하는 데 필요한 클래스를 제공합니다. ASP.NET 상태 모니터링은 WMI를 사용하여 이벤트를 제공합니다. 엄밀히 말하면 이 네임스페이스는 구성 API의 일부로 간주되지 않습니다. |
ASP.NET 구성 파일에서 읽기
WebConfigurationManager 클래스는 ASP.NET 구성 파일에서 읽기 위한 핵심 클래스입니다. 기본적으로 ASP.NET 구성 파일을 읽는 세 가지 단계가 있습니다.
- OpenWebConfiguration 메서드를 사용하여 Configuration 개체를 가져옵니다.
- 구성 파일에서 원하는 섹션에 대한 참조를 가져옵니다.
- 구성 파일에서 원하는 정보를 읽습니다.
Configuration 개체는 특정 구성 파일을 나타내지 않습니다. 대신 컴퓨터, 애플리케이션 또는 웹 사이트의 구성에 대한 병합된 보기를 나타냅니다. 다음 코드 샘플에서는 ProductInfo라는 웹 애플리케이션의 구성을 나타내는 Configuration 개체를 인스턴스화합니다.
Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
참고
/ProductInfo 경로가 없는 경우 위의 코드는 machine.config 파일에 지정된 대로 기본 구성을 반환합니다.
Configuration 개체가 있으면 GetSection 또는 GetSectionGroup 메서드를 사용하여 구성 설정을 드릴인할 수 있습니다. 다음 예제에서는 위의 ProductInfo 애플리케이션에 대한 가장 설정에 대한 참조를 가져옵니다.
Configuration config =
WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
(IdentitySection)config.GetSection("system.web/identity");
ASP.NET 구성 파일에 쓰기
구성 파일에서 읽을 때와 마찬가지로 WebConfigurationManager 클래스는 Asp.NET 구성 파일에 쓰기 위한 핵심입니다. ASP.NET 구성 파일에 쓰는 세 단계도 있습니다.
- OpenWebConfiguration 메서드를 사용하여 Configuration 개체를 가져옵니다.
- 구성 파일에서 원하는 섹션에 대한 참조를 가져옵니다.
- Save 또는 SaveAs 메서드를 사용하여 구성 파일에서 원하는 정보를 작성합니다.
다음 코드는 컴파일> 요소의 <디버그 특성을 false로 변경합니다.
System.Configuration.Configuration updateWebConfig =
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/webApp");
System.Web.Configuration.CompilationSection compilation =
updateWebConfig.GetSection("system.web/compilation")
as System.Web.Configuration.CompilationSection;
compilation.Debug = false;
if (!compilation.SectionInformation.IsLocked) {
updateWebConfig.Save();
Response.Write("Save Success!");
} else {
Response.Write("Save Failed!");
}
이 코드를 실행하면 webApp 애플리케이션의 <web.config 파일에 대해 컴파일> 요소의 디버그 특성이 false로 설정됩니다.
System.Web.Management 네임스페이스
System.Web.Management 네임스페이스는 ASP.NET 애플리케이션의 상태를 관리하고 모니터링하기 위한 클래스와 인터페이스를 제공합니다.
로깅은 이벤트를 공급자와 연결하는 규칙을 정의하여 수행됩니다. 규칙은 공급자에게 전송되는 이벤트의 유형을 정의합니다. 로그할 수 있는 기본 이벤트는 다음과 같습니다.
| WebBaseEvent | 모든 이벤트에 대한 기본 이벤트 클래스입니다. 이벤트 코드, 이벤트 세부 정보 코드, 이벤트가 발생한 날짜 및 시간, 시퀀스 번호, 이벤트 메시지 및 이벤트 세부 정보와 같은 모든 이벤트에 필요한 속성을 포함합니다. |
|---|---|
| WebManagementEvent | 애플리케이션 수명, 요청, 오류 및 감사 이벤트와 같은 관리 이벤트에 대한 기본 이벤트 클래스입니다. |
| WebHeartbeatEvent | 애플리케이션에서 유용한 런타임 상태 정보를 캡처하기 위해 정기적으로 생성된 이벤트입니다. |
| WebAuditEvent | 권한 부여 실패, 암호 해독 실패 등의 조건을 표시하는 데 사용되는 보안 감사 이벤트의 기본 클래스입니다 . |
| WebRequestEvent | 모든 정보 요청 이벤트에 대한 기본 클래스입니다. |
| WebBaseErrorEvent | 오류 조건을 나타내는 모든 이벤트에 대한 기본 클래스입니다. |
사용 가능한 공급자 유형을 사용하면 이벤트 출력을 이벤트 뷰어, SQL Server, WMI(Windows Management Instrumentation) 및 메일로 보낼 수 있습니다. 미리 구성된 공급자 및 이벤트 매핑은 이벤트 출력을 기록하는 데 필요한 작업량을 줄입니다.
ASP.NET 2.0은 이벤트 로그 공급자를 사용하여 처리되지 않은 예외를 로깅할 뿐만 아니라 시작 및 중지하는 애플리케이션 도메인을 기반으로 이벤트를 기록합니다. 이렇게 하면 몇 가지 기본 시나리오를 다룰 수 있습니다. 예를 들어 애플리케이션에서 예외를 throw하지만 사용자가 오류를 저장하지 않고 재현할 수 없다고 가정해 보겠습니다. 기본 이벤트 로그 규칙을 사용하면 예외 및 스택 정보를 수집하여 발생한 오류 종류를 더 잘 파악할 수 있습니다. 애플리케이션이 세션 상태를 손실하는 경우 또 다른 예제가 적용됩니다. 이 경우 이벤트 로그에서 애플리케이션 도메인이 재활용 중인지 여부와 애플리케이션 도메인이 처음에 중지된 이유를 확인할 수 있습니다.
또한 상태 모니터링 시스템은 확장할 수 있습니다. 예를 들어 사용자 지정 웹 이벤트를 정의하고, 애플리케이션 내에서 이벤트를 실행한 다음, 이벤트 정보를 전자 메일과 같은 공급자에게 보내는 규칙을 정의할 수 있습니다. 이렇게 하면 계측을 상태 모니터링 공급자와 쉽게 연결할 수 있습니다. 또 다른 예로 주문이 처리될 때마다 이벤트를 발생시키고 각 이벤트를 SQL Server 데이터베이스로 보내는 규칙을 설정할 수 있습니다. 사용자가 여러 번 연속으로 로그온하지 못하는 경우 이벤트를 발생시키고 전자 메일 기반 공급자를 사용하도록 이벤트를 설정할 수도 있습니다.
기본 공급자 및 이벤트에 대한 구성은 전역 Web.config 파일에 저장됩니다. 전역 Web.config 파일은 Machine.config 파일에 저장된 모든 웹 기반 설정을 ASP.NET 1x로 저장합니다. 전역 Web.config 파일은 다음 디렉터리에 있습니다.
%windir%\Microsoft.Net\Framework\v2.0.*\config\Web.config
<전역 Web.config 파일의 healthMonitoring> 섹션에서는 기본 구성 설정을 제공합니다. 애플리케이션에 대한 Web.config 파일에서 <healthMonitoring 섹션을> 구현하여 이러한 설정을 재정의하거나 고유한 설정을 구성할 수 있습니다.
<전역 Web.config 파일의 healthMonitoring> 섹션에는 다음 항목이 포함되어 있습니다.
| providers | 이벤트 뷰어, WMI 및 SQL Server 대해 설정된 공급자를 포함합니다. |
|---|---|
| eventMappings | 다양한 WebBase 클래스에 대한 매핑을 포함합니다. 고유한 이벤트 클래스를 생성하는 경우 이 목록을 확장할 수 있습니다. 사용자 고유의 이벤트 클래스를 생성하면 정보를 보내는 공급자에 대한 세분성이 더 세분화됩니다. 예를 들어 사용자 지정 이벤트를 전자 메일로 보내는 동안 처리되지 않은 예외를 SQL Server 보내도록 구성할 수 있습니다. |
| rules | eventMappings를 공급자에 연결합니다. |
| 버퍼링 | SQL Server 및 전자 메일 공급자와 함께 사용하여 공급자에게 이벤트를 플러시하는 빈도를 결정합니다. |
다음은 전역 Web.config 파일의 코드 예제입니다.
<healthMonitoring>
<!-- Event Log Provider being added. -->
<providers>
<add name="EventLogProvider"
type="System.Web.Management.EventLogWebEventProvider,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
<!-- Event mapping provides a friendly name to the
events based on the WebBaseErrorEvent class. -->
<eventMappings>
<add name="All Errors"
type="System.Web.Management.WebBaseErrorEvent,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
startEventCode="0" endEventCode="2147483647" />
</eventMappings>
<!-- Rule tying the "All Errors" event mapping to the EventLog Provider. -->
<rules>
<add name="All Errors Default" eventName="All Errors"
provider="EventLogProvider"
profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
</rules>
</healthMonitoring>
이벤트 뷰어 이벤트를 저장하는 방법
앞에서 설명한 대로 이벤트 뷰어 이벤트를 로깅하기 위한 공급자가 전역 Web.config 파일에서 구성됩니다. 기본적으로 WebBaseErrorEvent 및 WebFailureAuditEvent 를 기반으로 하는 모든 이벤트가 기록됩니다. 이벤트 로그에 추가 정보를 기록하는 추가 규칙을 추가할 수 있습니다. 예를 들어 모든 이벤트(예: WebBaseEvent를 기반으로 하는 모든 이벤트)를 기록하려는 경우 Web.config 파일에 다음 규칙을 추가할 수 있습니다.
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="EventLogProvider" profile="Critical" />
</rules>
</healthMonitoring>
이 규칙은 모든 이벤트 이벤트 맵을 이벤트 로그 공급자에 연결합니다. eventMapping과 공급자는 모두 전역 Web.config 파일에 포함됩니다.
SQL Server 이벤트를 저장하는 방법
이 메서드는 Aspnet_regsql.exe 도구에서 생성되는 ASPNETDB 데이터베이스를 사용합니다. 기본 공급자는 App_data 폴더의 파일 기반 데이터베이스 또는 SQL Server 로컬 SQLExpress instance 사용하는 LocalSqlServer 연결 문자열을 사용합니다. LocalSqlServer 연결 문자열과 SqlProvider는 모두 전역 Web.config 파일에 구성됩니다.
전역 Web.config 파일의 LocalSqlServer 연결 문자열은 다음과 같습니다.
<connectionStrings>
<add name="LocalSqlServer"
connectionString="data source=.\SQLEXPRESS;
Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;
User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
다른 SQL Server instance 사용하려면 %windir%\Microsoft.Net\Framework\v2.0.* 폴더에 있는 Aspnet_regsql.exe 도구를 사용해야 합니다. Aspnet_regsql.exe 도구를 사용하여 SQL Server instance 사용자 지정 ASPNETDB 데이터베이스를 생성한 다음, 애플리케이션 구성 파일에 연결 문자열을 추가한 다음, 새 연결 문자열을 사용하여 공급자를 추가합니다. ASPNETDB 데이터베이스를 만든 후에는 eventMapping을 sqlProvider에 연결하는 규칙을 설정해야 합니다.
기본 SqlProvider를 사용하든 자체 공급자를 구성하든 관계없이 공급자를 이벤트 맵과 연결하는 규칙을 추가해야 합니다. 다음 규칙은 위에서 만든 새 공급자를 모든 이벤트 이벤트 맵에 연결합니다. 이 규칙은 WebBaseEvent 를 기반으로 모든 이벤트를 기록하고 MYASPNETDB 연결 문자열을 사용하는 MySqlWebEventProvider로 보냅니다. 다음 코드는 공급자를 이벤트 맵과 연결하는 규칙을 추가합니다.
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="MySqlWebEventProvider" profile="Critical"/>
</rules>
</healthMonitoring>
SQL Server 오류만 보내려면 다음 규칙을 추가할 수 있습니다.
<add name="All Errors"
eventName="All Errors"
provider="MySqlWebEventProvider"
profile="Critical"/>
WMI에 이벤트를 전달하는 방법
WMI에 이벤트를 전달할 수도 있습니다. WMI 공급자는 기본적으로 전역 Web.config 파일에서 구성됩니다.
다음 코드 예제에서는 WMI에 이벤트를 전달하는 규칙을 추가합니다.
<providers>
<add name="WmiWebEventProvider"
type="System.Web.Management.WmiWebEventProvider,System.Web,
Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
eventMapping을 공급자에 연결하는 규칙과 이벤트를 수신 대기하는 WMI 수신기 애플리케이션을 추가해야 합니다. 다음 코드 예제에서는 WMI 공급자를 모든 이벤트 이벤트 맵에 연결하는 규칙을 추가합니다.
<rules>
<add name="All Events"
eventName="All Events" provider="WmiWebEventProvider"
profile="Critical" />
</rules>
이벤트를 전자 메일로 전달하는 방법
이벤트를 전자 메일로 전달할 수도 있습니다. SQL Server 또는 이벤트 로그에 더 적합할 수 있는 많은 정보를 의도치 않게 자신에게 보낼 수 있으므로 전자 메일 공급자에 매핑하는 이벤트 규칙에 주의해야 합니다. 두 개의 전자 메일 공급자가 있습니다. SimpleMailWebEventProvider 및 TemplatedMailWebEventProvider. 각각에는 "template" 및 "detailedTemplateErrors" 특성을 제외하고 동일한 구성 특성이 있으며, 둘 다 TemplatedMailWebEventProvider에서만 사용할 수 있습니다.
참고
이러한 전자 메일 공급자 중 어느 것도 구성되지 않습니다. Web.config 파일에 추가해야 합니다.
이러한 두 전자 메일 공급자 간의 기본 차이점은 SimpleMailWebEventProvider가 수정할 수 없는 일반 템플릿으로 전자 메일을 보낸다는 것입니다. 샘플 Web.config 파일은 다음 규칙을 사용하여 구성된 공급자 목록에 이 전자 메일 공급자를 추가합니다.
<add name="mySimple-mailWebEventProvider"
type="System.Web.Management.Simple-mailWebEventProvider"
to="e-mail@foo.com" from="e-mail@foo.com"
maxMessagesPerNotification="1" maxEventsPerMessage="10"
buffer="true" bufferMode="Critical Notification"
subjectPrefix="Web Events"/>
전자 메일 공급자를 모든 이벤트 이벤트 맵에 연결하기 위해 다음 규칙도 추가됩니다.
<add name="All Events" eventName="All Events"
provider="mySimple-mailWebEventProvider" profile="Critical"/>
ASP.NET 2.0 추적
ASP.NET 2.0의 추적에는 세 가지 주요 개선 사항이 있습니다.
- 통합 추적 기능
- 추적 메시지에 대한 프로그래밍 방식 액세스
- 향상된 애플리케이션 수준 추적
통합 추적 기능
이제 System.Diagnostics.Trace 클래스에서 내보낸 메시지를 추적 출력을 ASP.NET 라우팅하고 ASP.NET 추적을 통해 내보낸 메시지를 System.Diagnostics.Trace로 라우팅할 수 있습니다. ASP.NET 계측 이벤트를 System.Diagnostics.Trace로 전달할 수도 있습니다. 이 기능은 추적> 요소의 새 writeToDiagnosticsTrace 특성에 <의해 제공됩니다. 이 부울 값이 true이면 추적 메시지를 표시하기 위해 등록된 모든 수신기에서 사용할 수 있도록 ASP.NET 추적 메시지가 System.Diagnostics 추적 인프라로 전달됩니다.
추적 메시지에 대한 프로그래밍 방식 액세스
ASP.NET 2.0을 사용하면 TraceContextRecord 클래스 및 TraceRecords 컬렉션을 통해 모든 추적 메시지에 프로그래밍 방식으로 액세스할 수 있습니다. 추적 메시지에 액세스하는 가장 효율적인 방법은 TraceContextEventHandler 대리자(ASP.NET 2.0의 새로운 기능)를 등록하여 새 TraceFinished 이벤트를 처리하는 것입니다. 그런 다음 원하는 대로 추적 메시지를 반복할 수 있습니다.
다음 코드 샘플에서는 이를 보여 줍니다.
void Page_Load(object sender, EventArgs e) {
// Register a handler for the TraceFinished event.
Trace.TraceFinished += new
TraceContextEventHandler(this.OnTraceFinished);
// Write a trace message.
Trace.Write("Web Forms Infrastructure Methods",
"USERMESSAGE: Page_Load complete.");
}
// A TraceContextEventHandler for the TraceFinished event.
void OnTraceFinished(object sender, TraceContextEventArgs e) {
TraceContextRecord r = null;
// Iterate through the collection of trace records and write
// them to the response stream.
foreach (object o in e.TraceRecords) {
r = (TraceContextRecord)o;
Response.Write(String.Format("trace message: {0} <BR>",
r.Message));
}
}
위의 예제에서는 TraceRecords 컬렉션을 반복한 다음 각 메시지를 응답 스트림에 씁니다.
향상된 Application-Level 추적
추적> 요소의 새 mostRecent 특성이 도입되어 애플리케이션 수준 추적이 <향상되었습니다. 이 특성은 가장 최근의 애플리케이션 수준 추적 출력이 표시되고 requestLimit로 표시된 제한을 초과하는 이전 추적 데이터가 삭제되는지 여부를 지정합니다. false이면 requestLimit 특성에 도달할 때까지 요청에 대한 추적 데이터가 표시됩니다.
ASP.NET 명령줄 도구
ASP.NET 구성에 도움이 되는 몇 가지 명령줄 도구가 있습니다. ASP.NET 개발자는 aspnet_regiis.exe 도구를 잘 알고 있어야 합니다. ASP.NET 2.0은 구성에 도움이 되는 세 가지 다른 명령줄 도구를 제공합니다.
다음 명령줄 도구를 사용할 수 있습니다.
| 도구 | 사용 |
|---|---|
| aspnet_regiis.exe | IIS에 ASP.NET 등록할 수 있습니다. 이 도구에는 ASP.NET 2.0과 함께 제공되는 두 가지 버전이 있습니다. 하나는 Framework 폴더의 32비트 시스템용이고 다른 하나는 Framework64 폴더의 64비트 시스템용입니다. 64비트 버전은 32비트 OS에 설치되지 않습니다. |
| aspnet_regsql.exe | ASP.NET SQL Server 등록 도구는 ASP.NET SQL Server 공급자가 사용할 Microsoft SQL Server 데이터베이스를 만들거나 기존 데이터베이스에서 옵션을 추가하거나 제거하는 데 사용됩니다. Aspnet_regsql.exe 파일은 웹 서버의 [drive:]\WINDOWS\Microsoft.NET\Framework\versionNumber 폴더에 있습니다. |
| aspnet_regbrowsers.exe | ASP.NET Browser 등록 도구는 모든 시스템 전체 브라우저 정의를 구문 분석하고 어셈블리로 컴파일하고 어셈블리를 전역 어셈블리 캐시에 설치합니다. 도구는 브라우저 정의 파일()을 사용합니다. 브라우저 파일) .NET Framework Browsers 하위 디렉터리. 도구는 %SystemRoot%\Microsoft.NET\Framework\version\ 디렉터리에서 찾을 수 있습니다. |
| aspnet_compiler.exe | ASP.NET 컴파일 도구를 사용하면 프로덕션 서버와 같은 대상 위치에 배치하거나 배포하기 위해 ASP.NET 웹 애플리케이션을 컴파일할 수 있습니다. 최종 사용자가 애플리케이션을 컴파일하는 동안 애플리케이션에 대한 첫 번째 요청이 지연되지 않으므로 현재 위치 컴파일은 애플리케이션 성능에 도움이 됩니다. |
aspnet_regiis.exe 도구는 ASP.NET 2.0의 새로운 도구가 아니므로 여기서는 설명하지 않습니다.
ASP.NET SQL Server 등록 도구 - aspnet_regsql.exe
ASP.NET SQL Server 등록 도구를 사용하여 여러 가지 유형의 옵션을 설정할 수 있습니다. SQL 연결을 지정하고, 정보를 관리하는 데 SQL Server 사용하는 ASP.NET 애플리케이션 서비스를 지정하고, SQL 캐시 종속성에 사용되는 데이터베이스 또는 테이블을 지정하고, SQL Server 사용하여 프로시저 및 세션 상태를 저장하는 지원을 추가하거나 제거할 수 있습니다.
여러 ASP.NET 애플리케이션 서비스는 공급자를 사용하여 데이터 원본에서 데이터 저장 및 검색을 관리합니다. 각 공급자는 데이터 원본과 관련이 있습니다. ASP.NET 다음 ASP.NET 기능에 대한 SQL Server 공급자를 포함합니다.
- 멤버 자격( SqlMembershipProvider 클래스).
- 역할 관리( SqlRoleProvider 클래스).
- 프로필( SqlProfileProvider 클래스).
- 웹 파트 개인 설정( SqlPersonalizationProvider 클래스).
- 웹 이벤트( SqlWebEventProvider 클래스).
ASP.NET 설치할 때 서버의 Machine.config 파일에는 공급자를 사용하는 각 ASP.NET 기능에 대해 SQL Server 공급자를 지정하는 구성 요소가 포함됩니다. 이러한 공급자는 기본적으로 SQL Server Express 2005의 로컬 사용자 instance 연결하도록 구성됩니다. 공급자가 사용하는 기본 연결 문자열을 변경하는 경우 컴퓨터 구성에 구성된 ASP.NET 기능을 사용하려면 먼저 Aspnet_regsql.exe 사용하여 선택한 기능에 대한 SQL Server 데이터베이스 및 데이터베이스 요소를 설치해야 합니다. SQL 등록 도구로 지정한 데이터베이스가 아직 없는 경우(명령줄에 지정되지 않은 경우 aspnetdb가 기본 데이터베이스가 됩니다.) 현재 사용자는 데이터베이스 내에서 스키마 요소를 만들 뿐만 아니라 SQL Server 데이터베이스를 만들 수 있는 권한이 있어야 합니다.
SQL 캐시 종속성
ASP.NET 출력 캐싱의 고급 기능은 SQL 캐시 종속성입니다. SQL 캐시 종속성은 테이블 폴링의 ASP.NET 구현을 사용하는 모드와 SQL Server 2005의 쿼리 알림 기능을 사용하는 두 번째 모드의 두 가지 작업 모드를 지원합니다. SQL 등록 도구를 사용하여 테이블 폴링 작업 모드를 구성할 수 있습니다.
세션 상태
기본적으로 세션 상태 값 및 정보는 ASP.NET 프로세스 내의 메모리에 저장됩니다. 또는 여러 웹 서버에서 공유할 수 있는 SQL Server 데이터베이스에 세션 데이터를 저장할 수 있습니다. SQL 등록 도구를 사용하여 세션 상태에 대해 지정한 데이터베이스가 아직 없는 경우 현재 사용자는 데이터베이스 내에서 스키마 요소를 만들 뿐만 아니라 SQL Server 데이터베이스를 만들 수 있는 권한이 있어야 합니다. 데이터베이스가 있는 경우 현재 사용자에게 기존 데이터베이스에 스키마 요소를 만들 수 있는 권한이 있어야 합니다.
SQL Server 세션 상태 데이터베이스를 설치하려면 Aspnet_regsql.exe 도구를 실행하고 명령을 사용하여 다음 정보를 제공합니다.
- -S 옵션을 사용하는 SQL Server instance 이름입니다.
- SQL Server 실행하는 컴퓨터에서 데이터베이스를 만들 수 있는 권한이 있는 계정의 로그온 자격 증명입니다. -E 옵션을 사용하여 현재 로그온한 사용자를 사용하거나 -U 옵션을 사용하여 -P 옵션과 함께 사용자 ID를 지정하여 암호를 지정합니다.
- 세션 상태 데이터베이스 를 추가하는 -ssadd 명령줄 옵션입니다.
기본적으로 Aspnet_regsql.exe 도구를 사용하여 SQL Server 2005 Express Edition 실행하는 컴퓨터에 세션 상태 데이터베이스를 설치할 수 없습니다.
ASP.NET 브라우저 등록 도구 - aspnet_regbrowsers.exe
ASP.NET 버전 1.1에서 Machine.config 파일에는 browserCaps라는 <섹션이 포함되어 있습니다>. 이 섹션에는 정규식을 기반으로 다양한 브라우저에 대한 구성을 정의하는 일련의 XML 항목이 포함되어 있습니다. ASP.NET 버전 2.0의 경우 새 입니다. BROWSER 파일은 XML 항목을 사용하여 특정 브라우저의 매개 변수를 정의합니다. 새 을 추가하여 새 브라우저에 정보를 추가합니다. 시스템의 %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers에 있는 폴더에 대한 브라우저 파일입니다.
애플리케이션은 브라우저 정보가 필요할 때마다 .config 파일을 읽지 않으므로 새 를 만들 수 있습니다. 브라우저 파일 및 Aspnet_regbrowsers.exe 실행하여 어셈블리에 필요한 변경 내용을 추가합니다. 이렇게 하면 서버가 새 브라우저 정보에 즉시 액세스할 수 있으므로 정보를 선택하기 위해 애플리케이션을 종료할 필요가 없습니다. 애플리케이션은 현재 HttpRequest의 Browser 속성을 통해 브라우저 기능에 액세스할 수 있습니다.
다음 옵션은 aspnet_regbrowser.exe 실행할 때 사용할 수 있습니다.
| 옵션 | 설명 |
|---|---|
| -? | 명령 창에 Aspnet_regbbrowsers.exe 도움말 텍스트를 표시합니다. |
| -i | 런타임 브라우저 기능 어셈블리를 만들고 전역 어셈블리 캐시에 설치합니다. |
| -u | 전역 어셈블리 캐시에서 런타임 브라우저 기능 어셈블리를 제거합니다. |
ASP.NET 컴파일 도구 - aspnet_compiler.exe
ASP.NET 컴파일 도구는 대상 출력 디렉터리가 지정된 배포를 위한 현재 위치 컴파일 및 컴파일의 두 가지 일반적인 방법으로 사용할 수 있습니다.
현재 위치에서 애플리케이션 컴파일
ASP.NET 컴파일 도구는 애플리케이션을 현재 위치에서 컴파일할 수 있습니다. 즉, 애플리케이션에 여러 요청을 하는 동작을 모방하여 정기적인 컴파일을 유발합니다. 미리 컴파일된 사이트의 사용자는 첫 번째 요청에서 페이지를 컴파일하여 지연이 발생하지 않습니다.
사이트를 미리 컴파일하면 다음 항목이 적용됩니다.
- 사이트는 파일 및 디렉터리 구조를 유지합니다.
- 서버의 사이트에서 사용하는 모든 프로그래밍 언어에 대한 컴파일러가 있어야 합니다.
- 파일이 컴파일에 실패하면 전체 사이트가 컴파일에 실패합니다.
새 원본 파일을 추가한 후 애플리케이션을 다시 컴파일할 수도 있습니다. -c 옵션을 포함하지 않는 한 도구는 새 파일 또는 변경된 파일만 컴파일합니다.
참고
중첩된 애플리케이션을 포함하는 애플리케이션의 컴파일은 중첩된 애플리케이션을 컴파일하지 않습니다. 중첩된 애플리케이션은 별도로 컴파일해야 합니다.
배포용 애플리케이션 컴파일
targetDir 매개 변수를 지정하여 배포용 애플리케이션(대상 위치로 컴파일)을 컴파일합니다. targetDir은 웹 애플리케이션의 최종 위치이거나 컴파일된 애플리케이션을 추가로 배포할 수 있습니다. -u 옵션을 사용하면 애플리케이션을 다시 컴파일하지 않고 컴파일된 애플리케이션의 특정 파일을 변경할 수 있는 방식으로 애플리케이션을 컴파일합니다. Aspnet_compiler.exe 정적 파일 형식과 동적 파일 형식을 구분하고 결과 애플리케이션을 만들 때 다르게 처리합니다.
- 정적 파일 형식은 이름이 .css, .gif, .htm, .html, .jpg, .js 등의 확장명이 있는 파일과 같이 연결된 컴파일러 또는 빌드 공급자가 없는 형식입니다. 이러한 파일은 단순히 대상 위치에 복사되며 디렉터리 구조의 상대 위치는 유지됩니다.
- 동적 파일 형식은 .asax, .ascx, .ashx, .aspx, .browser, 와 같은 ASP.NET 관련 파일 이름 확장명이 있는 파일을 포함하여 연결된 컴파일러 또는 빌드 공급자가 있는 파일입니다. master 등입니다. ASP.NET 컴파일 도구는 이러한 파일에서 어셈블리를 생성합니다. -u 옵션을 생략하면 도구는 파일 이름 확장명을 가진 파일도 만듭니다. 원래 원본 파일을 어셈블리에 매핑하는 컴파일되었습니다. 애플리케이션 원본의 디렉터리 구조가 유지되도록 하기 위해 도구는 대상 애플리케이션의 해당 위치에 자리 표시자 파일을 생성합니다.
컴파일된 애플리케이션의 콘텐츠를 수정할 수 있음을 나타내려면 -u 옵션을 사용해야 합니다. 그렇지 않으면 후속 수정이 무시되거나 런타임 오류가 발생합니다.
다음 표에서는 -u 옵션이 포함될 때 ASP.NET 컴파일 도구가 다른 파일 형식을 처리하는 방법을 설명합니다.
| 파일 유형 | 컴파일러 작업 |
|---|---|
| .ascx, .aspx, . master | 이러한 파일은 코드 숨김 파일과 runat="server"> 요소 스크립트로 묶<인 모든 코드를 모두 포함하는 태그 및 소스 코드로 분할됩니다. 소스 코드는 해시 알고리즘에서 파생된 이름을 사용하여 어셈블리로 컴파일되고 어셈블리는 Bin 디렉터리에 배치됩니다. %와 %> 대괄호 사이에 < 묶인 인라인 코드는 태그에 포함되며 컴파일되지 않습니다. 원본 파일과 이름이 같은 새 파일은 태그를 포함하도록 만들어지고 해당 출력 디렉터리에 배치됩니다. |
| .ashx, .asmx | 이러한 파일은 컴파일되지 않고 있는 그대로 출력 디렉터리로 이동되고 컴파일되지 않습니다. 처리기 코드를 컴파일하려면 코드를 App_Code 디렉터리의 소스 코드 파일에 배치합니다. |
| .cs, .vb, .jsl, .cpp(앞서 나열된 파일 형식에 대한 코드 숨김 파일 포함 안 됨) | 이러한 파일은 컴파일되어 이를 참조하는 어셈블리의 리소스로 포함됩니다. 원본 파일은 출력 디렉터리에 복사되지 않습니다. 코드 파일이 참조되지 않으면 컴파일되지 않습니다. |
| 사용자 지정 파일 형식 | 이러한 파일은 컴파일되지 않습니다. 이러한 파일은 해당 출력 디렉터리에 복사됩니다. |
| App_Code 하위 디렉터리의 소스 코드 파일 | 이러한 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 배치됩니다. |
| App_GlobalResources 하위 디렉터리의 .resx 및 .resource 파일 | 이러한 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 배치됩니다. 기본 출력 디렉터리 아래에 App_GlobalResources 하위 디렉터리가 만들어지지 않으며 원본 디렉터리에 있는 .resx 또는 .resources 파일이 출력 디렉터리에 복사되지 않습니다. |
| App_LocalResources 하위 디렉터리의 .resx 및 .resource 파일 | 이러한 파일은 컴파일되지 않으며 해당 출력 디렉터리에 복사됩니다. |
| App_Themes 하위 디렉터리의 .skin 파일 | .skin 파일 및 정적 테마 파일은 컴파일되지 않고 해당 출력 디렉터리에 복사됩니다. |
| .browser Web.config Bin 디렉터리에 이미 있는 정적 파일 형식 어셈블리 | 이러한 파일은 출력 디렉터리에 있는 그대로 복사됩니다. |
다음 표에서는 -u 옵션을 생략할 때 ASP.NET 컴파일 도구가 다른 파일 형식을 처리하는 방법을 설명합니다.
| 파일 유형 | 컴파일러 작업 |
|---|---|
| .aspx, .asmx, .ashx, . master | 이러한 파일은 코드 숨김 파일과 runat="server"> 요소 스크립트로 묶<인 모든 코드를 모두 포함하는 태그 및 소스 코드로 분할됩니다. 소스 코드는 해시 알고리즘에서 파생된 이름을 사용하여 어셈블리로 컴파일됩니다. 결과 어셈블리는 Bin 디렉터리에 배치됩니다. %와 %> 대괄호 사이에 < 묶인 인라인 코드는 태그에 포함되며 컴파일되지 않습니다. 컴파일러는 원본 파일과 동일한 이름의 태그를 포함할 새 파일을 만듭니다. 이러한 결과 파일은 Bin 디렉터리에 배치됩니다. 또한 컴파일러는 원본 파일과 이름이 같지만 확장명을 가진 파일도 만듭니다. 매핑 정보를 포함하는 COMPILED입니다. Tthe. 컴파일된 파일은 원본 파일의 원래 위치에 해당하는 출력 디렉터리에 배치됩니다. |
| .ascx | 이러한 파일은 태그 및 소스 코드로 분할됩니다. 소스 코드는 어셈블리로 컴파일되고 해시 알고리즘에서 파생된 이름으로 Bin 디렉터리에 배치됩니다. 태그 파일이 생성되지 않습니다. |
| .cs, .vb, .jsl, .cpp(앞서 나열된 파일 형식에 대한 코드 숨김 파일 포함 안 됨) | .ascx, .ashx 또는 .aspx 파일에서 생성된 어셈블리에서 참조하는 소스 코드는 어셈블리로 컴파일되어 Bin 디렉터리에 배치됩니다. 원본 파일이 복사되지 않습니다. |
| 사용자 지정 파일 형식 | 이러한 파일은 동적 파일처럼 컴파일됩니다. 기반 파일의 형식에 따라 컴파일러는 출력 디렉터리에 매핑 파일을 배치할 수 있습니다. |
| App_Code 하위 디렉터리의 파일 | 이 하위 디렉터리의 소스 코드 파일은 어셈블리로 컴파일되어 Bin 디렉터리에 배치됩니다. |
| 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 Installer를 사용하여 웹 애플리케이션을 배포하는 것과 같은 일부 시나리오에서는 일관된 파일 이름 및 콘텐츠뿐만 아니라 일관된 디렉터리 구조를 사용하여 업데이트에 대한 어셈블리 또는 구성 설정을 식별해야 합니다. 이러한 경우 -fixednames 옵션을 사용하여 여러 페이지가 어셈블리로 컴파일되는 를 사용하는 대신 ASP.NET 컴파일 도구가 각 소스 파일에 대한 어셈블리를 컴파일하도록 지정할 수 있습니다. 이로 인해 많은 수의 어셈블리가 발생할 수 있으므로 확장성에 관심이 있는 경우 이 옵션을 주의해서 사용해야 합니다.
강력한 이름 컴파일
Aspnet_compiler.exe 사용하여 강력한 이름 도구(Sn.exe)를 별도로 사용하지 않고 강력한 이름의 어셈블리를 만들 수 있도록 -aptca, -delaysign, -keycontainer 및 -keyfile 옵션이 제공됩니다. 이러한 옵션은 각각 AllowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute 및 AssemblyKeyFileAttribute에 해당합니다.
이러한 특성에 대한 논의는 이 과정의 scope 벗어났습니다.
랩
다음 랩은 각각 이전 랩을 기반으로 합니다. 순서대로 수행해야 합니다.
랩 1: 구성 API 사용
- mod9lab이라는 새 웹 사이트를 만듭니다.
- 사이트에 새 웹 구성 파일을 추가합니다.
- web.config 파일에 다음을 추가합니다.
<authorization>
<deny users="?"/>
</authorization>
<identity impersonate="true"/>
이렇게 하면 web.config 파일의 변경 내용을 저장할 수 있는 권한이 있습니다.
- Default.aspx에 새 레이블 컨트롤을 추가하고 ID를 lblDebugStatus로 변경합니다.
- Default.aspx에 새 Button 컨트롤을 추가합니다.
- 단추 컨트롤의 ID를 btnToggleDebug 로 변경하고 텍스트를 디버그 상태를 토글로 변경합니다.
- Default.aspx의 코드 숨김 파일에 대한 코드 보기를 열고 다음과 같이 System.Web.Configuration에 대한 using 문을 추가합니다.
using System.Web.Configuration;
- 아래와 같이 클래스와 Page_Init 메서드에 두 개의 프라이빗 변수를 추가합니다.
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
protected void Page_Init(object sender, EventArgs e) {
config = WebConfigurationManager.OpenWebConfiguration("/mod9lab");
compilation =
(CompilationSection)config.GetSection("system.web/compilation");
_debugStatus = compilation.Debug;
}
}
- Page_Load 다음 코드를 추가합니다.
lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();
- default.aspx를 저장하고 찾아봅니다. Label 컨트롤은 현재 디버그 상태 표시합니다.
- 디자이너에서 Button 컨트롤을 두 번 클릭하고 Button 컨트롤의 Click 이벤트에 다음 코드를 추가합니다.
compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();
- default.aspx를 저장하고 찾아보고 단추를 클릭합니다.
- 각 단추를 클릭한 후 web.config 파일을 열고 컴파일 섹션에서 디버그 특성을 <확인합니다> .
랩 2: 로깅 애플리케이션 다시 시작
이 랩에서는 이벤트 뷰어 애플리케이션 종료, 시작 및 다시 컴파일의 로깅을 전환할 수 있는 코드를 만듭니다.
- DropDownList를 default.aspx에 추가하고 ID를 ddlLogAppEvents로 변경합니다.
- DropDownList의 AutoPostBack 속성을 true로 설정합니다.
- DropDownList의 Items 컬렉션에 세 개의 항목을 추가합니다. 첫 번째 항목 값 선택 및 값 -1에 대한 텍스트를 만듭니다. 두 번째 항목 True의 텍스트 및 값과 세 번째 항목 False의 텍스트 및 값을 만듭니다.
- default.aspx에 새 레이블을 추가합니다. ID를 lblLogAppEvents로 변경합니다.
- default.aspx에 대한 코드 숨김 보기를 열고 아래와 같이 HealthMonitoringSection 형식의 변수에 대한 새 선언을 추가합니다.
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
// new variable below
private HealthMonitoringSection health;
}
- Page_Init 기존 코드에 다음 코드를 추가합니다.
health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");
- DropDownList를 두 번 클릭하고 SelectedIndexChanged 이벤트에 다음 코드를 추가합니다.
if (ddlLogAppEvents.SelectedValue != "-1") {
if (Convert.ToBoolean(ddlLogAppEvents.SelectedValue)) {
RuleSettings appRules = new
RuleSettings("AppRestartEvents",
"Application Lifetime Events",
"EventLogProvider");
health.Rules.Add(appRules);
config.Save();
} else {
health.Rules.Remove("AppRestartEvents");
config.Save();
}
}
default.aspx를 찾아봅니다.
드롭다운을 False로 설정합니다.
이벤트 뷰어 애플리케이션 로그를 지웁 수 있습니다.
단추를 클릭하여 애플리케이션에 대한 디버그 특성을 변경합니다.
이벤트 뷰어 애플리케이션 로그를 새로 고칩니다.
- 이벤트가 기록되었나요?
- 그렇게 생각하는 이유는 무엇인가요?
드롭다운을 True로 설정합니다 .
단추를 클릭하여 애플리케이션에 대한 디버그 특성을 토글합니다.
이벤트 뷰어 애플리케이션 로그인을 새로 고칩니다.
- 이벤트가 기록되었나요?
- 앱 종료의 이유는 무엇인가요?
로깅 켜기 및 끄기를 실험하고 web.config 파일의 변경 내용을 확인합니다.
추가 정보:
ASP.NET 2.0의 공급자 모델을 사용하면 애플리케이션 계측뿐만 아니라 멤버 자격, 프로필 등과 같은 다른 많은 용도에 대해 고유한 공급자를 만들 수 있습니다. 애플리케이션 이벤트를 텍스트 파일에 기록하는 사용자 지정 공급자를 작성하는 방법에 대한 자세한 내용은 이 링크를 참조하세요.