다음을 통해 공유

웹 개발용 ASP.NET 4 및 Visual Studio 2010 개요

  • 아티클

이 문서에서는 the.NET Framework 4 및 Visual Studio 2010에 포함된 ASP.NET 대한 많은 새로운 기능에 대한 개요를 제공합니다.

이 백서 다운로드

콘텐츠

핵심 서비스
Web.config 파일 리팩터링
확장 가능한 출력 캐싱
웹 애플리케이션 자동 시작
페이지를 영구적으로 리디렉션
세션 상태 축소
허용 가능한 URL 범위 확장
확장 가능한 요청 유효성 검사
개체 캐싱 및 개체 캐싱 확장성
확장 가능한 HTML, URL 및 HTTP 헤더 인코딩
단일 작업자 프로세스의 개별 애플리케이션에 대한 성능 모니터링
다중 대상 지정

Ajax
및 MVC에 포함된 jQuery _Toc253429251
Content Delivery Network 지원
ScriptManager 명시적 스크립트

Web Forms
Page.MetaKeywords 및 Page.MetaDescription 속성을 사용하여 메타 태그 설정
개별 컨트롤에 대해 상태 보기 사용
브라우저 기능 변경
ASP.NET 4의 라우팅
클라이언트 ID 설정
데이터 컨트롤에서 행 선택 유지
ASP.NET 차트 컨트롤
QueryExtender 컨트롤을 사용하여 데이터 필터링
Html 인코딩된 코드 식
프로젝트 템플릿 변경 내용
CSS 개선 사항
숨겨진 필드 주위에 div 요소 숨기기
템플릿 컨트롤에 대한 외부 테이블 렌더링
ListView 컨트롤 개선 사항
CheckBoxList 및 RadioButtonList 컨트롤 향상
메뉴 컨트롤 개선 사항
마법사 및 CreateUserWizard 컨트롤 56

_Toc253429274
영역 지원
데이터 주석 특성 유효성 검사 지원
템플릿 도우미

동적 데이터
기존 프로젝트에 동적 데이터 사용
선언적 DynamicDataManager 컨트롤 구문
엔터티 템플릿
URL 및 전자 메일 주소에 대한 새 필드 템플릿
DynamicHyperLink 컨트롤을 사용하여 링크 만들기
데이터 모델의 상속 지원
다 대 다 관계 지원(Entity Framework만 해당)
표시 및 지원 열거형을 제어하는 새 특성
필터에 대한 향상된 지원

Visual Studio 2010 웹 개발 개선 사항
향상된 CSS 호환성
HTML 및 JavaScript 코드 조각
JavaScript IntelliSense 향상된 기능

Visual Studio 2010을 사용하여 웹 애플리케이션 배포
웹 패키징
Web.config 변환
데이터베이스 배포
웹 애플리케이션용 원클릭 게시
리소스

면책 조항

핵심 서비스

ASP.NET 4에는 출력 캐싱 및 세션 상태 스토리지와 같은 핵심 ASP.NET 서비스를 개선하는 다양한 기능이 도입되었습니다.

Web.config 파일 리팩터링

Web.config Ajax, 라우팅 및 IIS 7과의 통합과 같은 새로운 기능이 추가됨에 따라 웹 애플리케이션에 대한 구성이 포함된 파일은 지난 몇 번의 .NET Framework 릴리스에서 상당히 증가했습니다. 이로 인해 Visual Studio와 같은 도구 없이 새 웹 애플리케이션을 구성하거나 시작하기가 더 어려워졌습니다. .NET Framework 4에서 주요 구성 요소가 파일로 machine.config 이동되었으며 애플리케이션은 이제 이러한 설정을 상속합니다. 이렇게 하면 Web.config ASP.NET 4개 애플리케이션의 파일이 비어 있거나 Visual Studio에 애플리케이션이 대상으로 하는 프레임워크 버전을 지정하는 다음 줄만 포함할 수 있습니다.

<?xml version="1.0"?>
  <configuration>
   <system.web>
    <compilation targetFramework="4.0" /> 
   </system.web>
  </configuration>

확장 가능한 출력 캐싱

ASP.NET 1.0이 릴리스된 이후 출력 캐싱을 통해 개발자는 생성된 페이지, 컨트롤 및 HTTP 응답의 출력을 메모리에 저장할 수 있었습니다. 후속 웹 요청에서 ASP.NET 출력을 처음부터 다시 생성하는 대신 메모리에서 생성된 출력을 검색하여 콘텐츠를 더 빠르게 제공할 수 있습니다. 그러나 이 접근 방식에는 제한 사항이 있습니다. 생성된 콘텐츠는 항상 메모리에 저장되어야 하며, 트래픽이 많은 서버에서는 출력 캐싱에서 사용하는 메모리가 웹 애플리케이션의 다른 부분의 메모리 요구와 경쟁할 수 있습니다.

ASP.NET 4는 하나 이상의 사용자 지정 출력 캐시 공급자를 구성할 수 있는 확장성 지점을 출력 캐싱에 추가합니다. 출력 캐시 공급자는 모든 스토리지 메커니즘을 사용하여 HTML 콘텐츠를 유지할 수 있습니다. 이렇게 하면 로컬 또는 원격 디스크, 클라우드 스토리지 및 분산 캐시 엔진을 포함할 수 있는 다양한 지속성 메커니즘에 대한 사용자 지정 출력 캐시 공급자를 만들 수 있습니다.

새 System.Web.Caching.OutputCacheProvider 형식에서 파생되는 클래스로 사용자 지정 출력 캐시 공급자를 만듭니다. 그런 다음, 다음 예제와 Web.config 같이 outputCache 요소의 새 공급자 하위 섹션을 사용하여 파일에서 공급자를 구성할 수 있습니다.

<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache"
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>

</caching>

기본적으로 ASP.NET 4에서는 defaultProvider 특성이 AspNetInternalProvider로 설정된 이전 예제와 같이 모든 HTTP 응답, 렌더링된 페이지 및 컨트롤이 메모리 내 출력 캐시를 사용합니다. defaultProvider에 다른 공급자 이름을 지정하여 웹 애플리케이션에 사용되는 기본 출력 캐시 공급자를 변경할 수 있습니다.

또한 컨트롤 및 요청당 다른 출력 캐시 공급자를 선택할 수 있습니다. 다른 웹 사용자 컨트롤에 대해 다른 출력 캐시 공급자를 선택하는 가장 쉬운 방법은 다음 예제와 같이 컨트롤 지시문에서 새 providerName 특성을 사용하여 선언적으로 선택하는 것입니다.

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

HTTP 요청에 대해 다른 출력 캐시 공급자를 지정하려면 좀 더 많은 작업이 필요합니다. 공급자를 선언적으로 지정하는 대신 파일의 새 GetOuputCacheProviderName 메서드를 재정의 Global.asax 하여 특정 요청에 사용할 공급자를 프로그래밍 방식으로 지정합니다. 다음 예제에 이 작업을 수행하는 방법이 나와 있습니다.

public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

ASP.NET 4에 출력 캐시 공급자 확장성을 추가하여 이제 웹 사이트에 대해 보다 공격적이고 지능적인 출력 캐싱 전략을 추구할 수 있습니다. 예를 들어 이제 디스크에서 트래픽이 낮은 페이지를 캐싱하면서 메모리에 있는 사이트의 "상위 10개" 페이지를 캐시할 수 있습니다. 또는 렌더링된 페이지에 대해 다양한 조합으로 캐시할 수 있지만, 메모리 사용량이 프런트 엔드 웹 서버에서 오프로드되도록 분산 캐시를 사용할 수 있습니다.

웹 애플리케이션 자동 시작

일부 웹 애플리케이션은 첫 번째 요청을 처리하기 전에 많은 양의 데이터를 로드하거나 비용이 많이 드는 초기화 처리를 수행해야 합니다. 이전 버전의 ASP.NET 이러한 상황에서는 ASP.NET 애플리케이션을 "절전 모드 해제"한 다음 파일의 Application_Load 메서드 Global.asax 중에 초기화 코드를 실행하는 사용자 지정 방법을 고안해야 했습니다.

이 시나리오를 직접 해결하는 자동 시작 이라는 새로운 확장성 기능은 windows Server 2008 R2의 IIS 7.5에서 ASP.NET 4가 실행되는 경우 사용할 수 있습니다. 자동 시작 기능은 애플리케이션 풀을 시작하고, ASP.NET 애플리케이션을 초기화한 다음, HTTP 요청을 수락하는 제어된 접근 방식을 제공합니다.

참고

IIS 7.5용 IIS 애플리케이션 Warm-Up 모듈

IIS 팀은 IIS 7.5용 애플리케이션 Warm-Up 모듈의 첫 번째 베타 테스트 버전을 릴리스했습니다. 이렇게 하면 애플리케이션을 이전에 설명한 것보다 더 쉽게 준비할 수 있습니다. 사용자 지정 코드를 작성하는 대신 웹 애플리케이션이 네트워크의 요청을 수락하기 전에 실행할 리소스의 URL을 지정합니다. 이 준비는 IIS 서비스를 시작하는 동안(IIS 애플리케이션 풀을 AlwaysRunning으로 구성한 경우) 및 IIS 작업자 프로세스가 재활용되는 경우에 발생합니다. 재활용하는 동안 새로 생성된 작업자 프로세스가 완전히 준비될 때까지 이전 IIS 작업자 프로세스는 요청을 계속 실행하므로 애플리케이션은 초기화되지 않은 캐시로 인해 중단이나 기타 문제가 발생하지 않습니다. 이 모듈은 버전 2.0부터 모든 버전의 ASP.NET 작동합니다.

자세한 내용은 IIS.net 웹 사이트의 애플리케이션 준비 를 참조하세요. 준비 기능을 사용하는 방법을 보여 주는 연습은 IIS.net 웹 사이트의 IIS 7.5 애플리케이션 Warm-Up 모듈을 사용한 시작 참조하세요.

자동 시작 기능을 사용하기 위해 IIS 관리자는 파일에서 다음 구성 applicationHost.config 을 사용하여 IIS 7.5의 애플리케이션 풀을 자동으로 시작하도록 설정합니다.

<applicationpools>
  <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>

단일 애플리케이션 풀에는 여러 애플리케이션이 포함될 수 있으므로 파일에서 다음 구성을 사용하여 자동으로 시작할 개별 애플리케이션을 applicationHost.config 지정합니다.

<sites>
  <site name="MySite" id="1">
    <application path="/" 
      serviceAutoStartEnabled="true"
      serviceAutoStartProvider="PrewarmMyCache" >
      <!-- Additional content -->
    </application>
  </site>

</sites>

<!-- Additional content -->

<serviceautostartproviders>
  <add name="PrewarmMyCache"
    type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceautostartproviders>

IIS 7.5 서버가 콜드 시작되었거나 개별 애플리케이션 풀을 재활용할 때 IIS 7.5는 파일의 applicationHost.config 정보를 사용하여 자동으로 시작해야 하는 웹 애플리케이션을 결정합니다. 자동 시작으로 표시된 각 애플리케이션에 대해 IIS7.5는 애플리케이션이 일시적으로 HTTP 요청을 수락하지 않는 상태에서 애플리케이션을 시작하기 위해 ASP.NET 4에 요청을 보냅니다. 이 상태인 경우 ASP.NET serviceAutoStartProvider 특성에 정의된 형식을 인스턴스화하고(이전 예제와 같이) 공용 진입점으로 호출합니다.

다음 예제와 같이 IProcessHostPreloadClient 인터페이스를 구현하여 필요한 진입점으로 관리되는 자동 시작 형식을 만듭니다.

public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Perform initialization. 
    }
}

초기화 코드가 Preload 메서드에서 실행되고 메서드가 반환되면 ASP.NET 애플리케이션이 요청을 처리할 준비가 됩니다.

IIS .5 및 ASP.NET 4에 자동 시작을 추가하여 이제 첫 번째 HTTP 요청을 처리하기 전에 비용이 많이 드는 애플리케이션 초기화를 수행하기 위한 잘 정의된 접근 방식을 사용할 수 있습니다. 예를 들어 새 자동 시작 기능을 사용하여 애플리케이션을 초기화한 다음, 애플리케이션이 초기화되고 HTTP 트래픽을 수락할 준비가 되었음을 부하 분산 장치에 알릴 수 있습니다.

페이지 영구 리디렉션

웹 애플리케이션에서는 시간이 지남에 따라 페이지 및 기타 콘텐츠를 이동하는 것이 일반적이며, 이로 인해 검색 엔진에서 부실 링크가 누적될 수 있습니다. ASP.NET 개발자는 일반적으로 Response.Redirect 메서드를 사용하여 요청을 새 URL로 전달하여 이전 URL에 대한 요청을 처리했습니다. 그러나 리디렉션 메서드는 HTTP 302 Found(임시 리디렉션) 응답을 발급하므로 사용자가 이전 URL에 액세스하려고 할 때 추가 HTTP 왕복이 발생합니다.

ASP.NET 4는 다음 예제와 같이 HTTP 301 이동 영구 응답을 쉽게 실행할 수 있는 새 RedirectPermanent 도우미 메서드를 추가합니다.

RedirectPermanent("/newpath/foroldcontent.aspx");

영구 리디렉션을 인식하는 검색 엔진 및 기타 사용자 에이전트는 콘텐츠와 연결된 새 URL을 저장하므로 임시 리디렉션을 위해 브라우저에서 수행한 불필요한 왕복이 제거됩니다.

세션 상태 축소

ASP.NET 웹 팜에 세션 상태를 저장하기 위한 두 가지 기본 옵션인 out-of-process 세션 상태 서버를 호출하는 세션 상태 공급자와 Microsoft SQL Server 데이터베이스에 데이터를 저장하는 세션 상태 공급자를 제공합니다. 두 옵션 모두 웹 애플리케이션의 작업자 프로세스 외부에 상태 정보를 저장하는 것을 포함하므로 세션 상태는 원격 스토리지로 전송되기 전에 직렬화해야 합니다. 개발자가 세션 상태에서 저장하는 정보의 양에 따라 직렬화된 데이터의 크기가 상당히 커질 수 있습니다.

ASP.NET 4에는 두 종류의 out-of-process 세션 상태 공급자에 대한 새로운 압축 옵션이 도입되었습니다. 다음 예제에 표시된 compressionEnabled 구성 옵션이 true로 설정되면 ASP.NET .NET Framework System.IO.Compression.GZipStream 클래스를 사용하여 직렬화된 세션 상태를 압축(및 압축 해제)합니다.

<sessionState
  mode="SqlServer"
  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

파일에 새 특성을 간단히 추가하면 Web.config 웹 서버에서 예비 CPU 주기가 있는 애플리케이션은 직렬화된 세션 상태 데이터의 크기가 크게 감소할 수 있습니다.

허용 가능한 URL 범위 확장

ASP.NET 4에는 애플리케이션 URL의 크기를 확장하기 위한 새로운 옵션이 도입되었습니다. 이전 버전의 ASP.NET NTFS 파일 경로 제한에 따라 URL 경로 길이가 260자로 제한됩니다. ASP.NET 4에서는 두 개의 새 httpRuntime 구성 특성을 사용하여 애플리케이션에 맞게 이 제한을 늘리거나 줄일 수 있습니다. 다음 예제에서는 이러한 새 특성을 보여줍니다.

<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />

더 길거나 짧은 경로(프로토콜, 서버 이름 및 쿼리 문자열을 포함하지 않는 URL 부분)를 허용하려면 maxUrlLength 특성을 수정합니다. 더 길거나 짧은 쿼리 문자열을 허용하려면 maxQueryStringLength 특성의 값을 수정합니다.

ASP.NET 4를 사용하면 URL 문자 검사 사용되는 문자를 구성할 수도 있습니다. ASP.NET URL의 경로 부분에서 잘못된 문자를 찾으면 요청을 거부하고 HTTP 400 오류를 발생합니다. 이전 버전의 ASP.NET URL 문자 검사는 고정된 문자 집합으로 제한되었습니다. ASP.NET 4에서는 다음 예제와 같이 httpRuntime 구성 요소의 새 requestPathInvalidCharacters 특성을 사용하여 유효한 문자 집합을 사용자 지정할 수 있습니다.

<httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?"  />

기본적으로 requestPathInvalidCharacters 특성은 8개의 문자를 잘못된 문자로 정의합니다. (기본적으로 requestPathInvalidCharacters 에 할당된 문자열에서는 파일이 XML 파일이므로 보다 작음(<), 보다 큼(>) 및 앰퍼샌드(&) 문자가 인코딩 Web.config 됩니다. 필요에 따라 잘못된 문자 집합을 사용자 지정할 수 있습니다.

참고

참고 ASP.NET 4는 IETF(http://www.ietf.org/rfc/rfc2396.txt)의 RFC 2396에 정의된 잘못된 URL 문자이므로 항상 0x1F 0x00 ASCII 범위의 문자를 포함하는 URL 경로를 거부합니다. IIS 6 이상을 실행하는 Windows Server 버전에서 http.sys 프로토콜 디바이스 드라이버는 이러한 문자가 포함된 URL을 자동으로 거부합니다.

확장 가능한 요청 유효성 검사

ASP.NET 요청 유효성 검사는 들어오는 HTTP 요청 데이터를 검색하여 XSS(사이트 간 스크립팅) 공격에 일반적으로 사용되는 문자열을 검색합니다. 잠재적인 XSS 문자열이 발견되면 요청 유효성 검사에서 의심 문자열에 플래그를 지정하고 오류를 반환합니다. 기본 제공 요청 유효성 검사는 XSS 공격에 사용되는 가장 일반적인 문자열을 찾은 경우에만 오류를 반환합니다. XSS 유효성 검사를 더 공격적으로 만들려는 이전 시도는 너무 많은 가양성을 초래했습니다. 그러나 고객은 더 공격적이거나 반대로 특정 페이지 또는 특정 유형의 요청에 대한 XSS 검사를 의도적으로 완화하려는 요청 유효성 검사를 원할 수 있습니다.

ASP.NET 4에서는 사용자 지정 요청 유효성 검사 논리를 사용할 수 있도록 요청 유효성 검사 기능을 확장할 수 있습니다. 요청 유효성 검사를 확장하려면 새 System.Web.Util.RequestValidator 형식에서 파생되는 클래스를 만들고 사용자 지정 형식을 사용하도록 애플리케이션(파일의 Web.confighttpRuntime 섹션)을 구성합니다. 다음 예제에서는 사용자 지정 요청 유효성 검사 클래스를 구성하는 방법을 보여줍니다.

<httpRuntime requestValidationType="Samples.MyValidator, Samples" />

새 requestValidationType 특성에는 사용자 지정 요청 유효성 검사를 제공하는 클래스를 지정하는 표준 .NET Framework 형식 식별자 문자열이 필요합니다. 각 요청에 대해 ASP.NET 들어오는 HTTP 요청 데이터의 각 부분을 처리하는 사용자 지정 형식을 호출합니다. 들어오는 URL, 모든 HTTP 헤더(쿠키 및 사용자 지정 헤더 모두) 및 엔터티 본문은 다음 예제와 같이 사용자 지정 요청 유효성 검사 클래스에서 검사할 수 있습니다.

public class CustomRequestValidation : RequestValidator
{
    protected override bool IsValidRequestString(
      HttpContext context, string value, 
      RequestValidationSource requestValidationSource, 
      string collectionKey, 
      out int validationFailureIndex) 
    {...}
 }

들어오는 HTTP 데이터의 일부를 검사하지 않으려는 경우 요청 유효성 검사 클래스가 대체되어 ASP.NET 기본 요청 유효성 검사가 단순히 base를 호출하여 실행되도록 할 수 있습니다 . IsValidRequestString.

개체 캐싱 및 개체 캐싱 확장성

첫 번째 릴리스 이후 ASP.NET 강력한 메모리 내 개체 캐시(System.Web.Caching.Cache)를 포함했습니다. 캐시 구현이 너무 인기가 있어 웹이 아닌 애플리케이션에서 사용되었습니다. 그러나 Windows Forms 또는 WPF 애플리케이션이 ASP.NET 개체 캐시를 사용할 수 있도록 에 대한 참조 System.Web.dll 를 포함하는 것은 어색합니다.

모든 애플리케이션에 캐싱을 사용할 수 있도록 .NET Framework 4에는 새 어셈블리, 새 네임스페이스, 일부 기본 형식 및 구체적인 캐싱 구현이 도입됩니다. 새 System.Runtime.Caching.dll 어셈블리에는 System.Runtime.Caching 네임스페이스에 새 캐싱 API가 포함되어 있습니다. 네임스페이스에는 두 가지 핵심 클래스 집합이 포함되어 있습니다.

  • 모든 형식의 사용자 지정 캐시 구현을 빌드하기 위한 토대를 제공하는 추상 형식입니다.
  • 구체적인 메모리 내 개체 캐시 구현( System.Runtime.Caching.MemoryCache 클래스).

새 MemoryCache 클래스는 ASP.NET 캐시에서 밀접하게 모델링되며 대부분의 내부 캐시 엔진 논리를 ASP.NET 공유합니다. System.Runtime.Caching의 공용 캐싱 API가 사용자 지정 캐시 개발을 지원하도록 업데이트되었지만 ASP.NET Cache 개체를 사용한 경우 새 API에서 친숙한 개념을 찾을 수 있습니다.

새 MemoryCache 클래스 및 지원 기본 API에 대한 심층적인 논의에는 전체 문서가 필요합니다. 그러나 다음 예제에서는 새 캐시 API의 작동 방식을 설명합니다. 이 예제는 에 대한 종속성 없이 Windows Forms 애플리케이션에 대해 System.Web.dll작성되었습니다.

private void btnGet_Click(object sender, EventArgs e) 
{ 
    //Obtain a reference to the default MemoryCache instance. 
    //Note that you can create multiple MemoryCache(s) inside 
    //of a single application. 
    ObjectCache cache = MemoryCache.Default; 

    //In this example the cache is storing the contents of a file string 
    fileContents = cache["filecontents"] as string;

    //If the file contents are not currently in the cache, then 
    //the contents are read from disk and placed in the cache. 
    if (fileContents == null) 
    {
        //A CacheItemPolicy object holds all the pieces of cache 
        //dependency and cache expiration metadata related to a single 
        //cache entry. 
        CacheItemPolicy policy = new CacheItemPolicy(); 

        //Build up the information necessary to create a file dependency. 
        //In this case we just need the file path of the file on disk. 
        List filePaths = new List(); 
        filePaths.Add("c:\\data.txt"); 

        //In the new cache API, dependencies are called "change monitors". 
        //For this example we want the cache entry to be automatically expired 
        //if the contents on disk change. A HostFileChangeMonitor provides 
        //this functionality. 
        policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths)); 

        //Fetch the file's contents 
        fileContents = File.ReadAllText("c:\\data.txt"); 

        //And then store the file's contents in the cache 
        cache.Set("filecontents", fileContents, policy); 

    } 
    MessageBox.Show(fileContents); 
}

확장 가능한 HTML, URL 및 HTTP 헤더 인코딩

ASP.NET 4에서는 다음과 같은 일반적인 텍스트 인코딩 작업에 대한 사용자 지정 인코딩 루틴을 만들 수 있습니다.

  • HTML 인코딩.
  • URL 인코딩.
  • HTML 특성 인코딩.
  • 아웃바운드 HTTP 헤더 인코딩

다음 예제와 같이 새 System.Web.Util.HttpEncoder 형식에서 파생된 다음 파일의 Web.confighttpRuntime 섹션에서 사용자 지정 형식을 사용하도록 ASP.NET 구성하여 사용자 지정 인코더를 만들 수 있습니다.

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />

사용자 지정 인코더가 구성되면 ASP.NET System.Web.HttpUtility 또는 System.Web.HttpServerUtility 클래스의 공용 인코딩 메서드가 호출될 때마다 사용자 지정 인코딩 구현을 자동으로 호출합니다. 이렇게 하면 웹 개발 팀의 한 부분이 공격적인 문자 인코딩을 구현하는 사용자 지정 인코더를 만들 수 있으며 나머지 웹 개발 팀은 공용 ASP.NET 인코딩 API를 계속 사용합니다. httpRuntime 요소에서 사용자 지정 인코더를 중앙에서 구성하면 공용 ASP.NET 인코딩 API의 모든 텍스트 인코딩 호출이 사용자 지정 인코더를 통해 라우팅됩니다.

단일 작업자 프로세스의 개별 애플리케이션에 대한 성능 모니터링

단일 서버에서 호스트할 수 있는 웹 사이트의 수를 늘리기 위해 많은 호스트는 단일 작업자 프로세스에서 여러 ASP.NET 애플리케이션을 실행합니다. 그러나 여러 애플리케이션에서 단일 공유 작업자 프로세스를 사용하는 경우 서버 관리자가 문제가 발생한 개별 애플리케이션을 식별하기가 어렵습니다.

ASP.NET 4는 CLR에서 도입한 새로운 리소스 모니터링 기능을 활용합니다. 이 기능을 사용하도록 설정하려면 구성 파일에 다음 XML 구성 조각을 aspnet.config 추가할 수 있습니다.

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 

</configuration>

참고

참고 파일은 aspnet.config .NET Framework 설치된 디렉터리에 있습니다. 파일이 아닙니다 Web.config .

appDomainResourceMonitoring 기능을 사용하도록 설정하면 "ASP.NET 애플리케이션" 성능 범주에서 두 개의 새로운 성능 카운터인 %Managed Processor Time 및 Managed Memory Used를 사용할 수 있습니다. 이러한 두 성능 카운터는 새 CLR 애플리케이션 도메인 리소스 관리 기능을 사용하여 개별 ASP.NET 애플리케이션의 예상 CPU 시간 및 관리되는 메모리 사용률을 추적합니다. 따라서 ASP.NET 4를 사용하면 관리자는 이제 단일 작업자 프로세스에서 실행되는 개별 애플리케이션의 리소스 사용량을 보다 세분화할 수 있습니다.

멀티 타기팅

특정 버전의 .NET Framework 대상으로 하는 애플리케이션을 만들 수 있습니다. ASP.NET 4에서는 파일의 Web.config컴파일 요소에 새 특성을 사용하여 .NET Framework 4 이상을 대상으로 지정할 수 있습니다. .NET Framework 4를 명시적으로 대상으로 지정하고 system.codedom의 항목과 같은 선택적 요소를 Web.config 파일에 포함하는 경우 이러한 요소는 .NET Framework 4에 대해 정확해야 합니다. (.NET Framework 4를 명시적으로 대상으로 지정하지 않으면 대상 프레임워크가 파일에 항목 Web.config 이 없는 것으로 유추됩니다.)

다음 예제에서는 파일의 컴파일 요소에서 targetFramework 특성을 사용하는 방법을 Web.config 보여줍니다.

<compilation targetFramework="4.0"/>

특정 버전의 .NET Framework 대상으로 지정하는 방법에 대해 다음 사항에 유의하세요.

  • .NET Framework 4 애플리케이션 풀에서 ASP.NET 빌드 시스템은 파일에 targetFramework 특성 Web.config 이 포함되지 않거나 파일이 누락된 경우 Web.config .NET Framework 4를 대상으로 가정합니다. (애플리케이션을 .NET Framework 4에서 실행하려면 코딩을 변경해야 할 수 있습니다.)
  • targetFramework 특성을 포함하고 system.codeDom 요소가 파일에 정의된 Web.config 경우 이 파일에는 .NET Framework 4에 대한 올바른 항목이 포함되어야 합니다.
  • aspnet_compiler 명령을 사용하여 애플리케이션(예: 빌드 환경)을 미리 컴파일하는 경우 대상 프레임워크에 올바른 버전의 aspnet_compiler 명령을 사용해야 합니다. .NET Framework 2.0(%WINDIR%\Microsoft.NET\Framework\v2.0.50727)과 함께 제공된 컴파일러를 사용하여 .NET Framework 3.5 이하 버전에 대해 컴파일합니다. .NET Framework 4와 함께 제공되는 컴파일러를 사용하여 해당 프레임워크를 사용하거나 이후 버전을 사용하여 만든 애플리케이션을 컴파일합니다.
  • 런타임에 컴파일러는 컴퓨터에 설치된 최신 프레임워크 어셈블리(따라서 GAC)를 사용합니다. 나중에 프레임워크를 업데이트하는 경우(예: 가상 버전 4.1이 설치됨) targetFramework 특성이 더 낮은 버전(예: 4.0)을 대상으로 하는 경우에도 최신 버전의 프레임워크에서 기능을 사용할 수 있습니다. 그러나 Visual Studio 2010의 디자인 타임 또는 aspnet_compiler 명령을 사용하는 경우 프레임워크의 최신 기능을 사용하면 컴파일러 오류가 발생합니다.

Ajax

jQuery Web Forms 및 MVC에 포함됨

Web Forms 및 MVC 모두에 대한 Visual Studio 템플릿에는 오픈 소스 jQuery 라이브러리가 포함됩니다. 새 웹 사이트 또는 프로젝트를 만들 때 다음 3개의 파일이 포함된 Scripts 폴더가 만들어집니다.

  • jQuery-1.4.1.js – 사람이 읽을 수 있는 수정되지 않은 jQuery 라이브러리 버전입니다.
  • jQuery-14.1.min.js – jQuery 라이브러리의 축소된 버전입니다.
  • jQuery-1.4.1-vsdoc.js – jQuery 라이브러리에 대한 Intellisense 설명서 파일입니다.

애플리케이션을 개발하는 동안 jQuery의 수정되지 않은 버전을 포함합니다. 프로덕션 애플리케이션에 대한 jQuery의 축소된 버전을 포함합니다.

예를 들어 다음 Web Forms 페이지에서는 jQuery를 사용하여 포커스가 있을 때 ASP.NET TextBox 컨트롤의 배경색을 노란색으로 변경하는 방법을 보여 줍니다.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">
    <title>Show jQuery</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>

        <asp:TextBox ID="txtFirstName" runat="server" />
        <br />
        <asp:TextBox ID="txtLastName" runat="server" />
    </div>
    </form>
    <script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>

    <script type="text/javascript">
    
        $("input").focus( function() { $(this).css("background-color", "yellow"); });
    
    </script>
</body>
</html>

Content Delivery Network 지원

Microsoft Ajax CDN(Content Delivery Network)을 사용하면 ASP.NET Ajax 및 jQuery 스크립트를 웹 애플리케이션에 쉽게 추가할 수 있습니다. 예를 들어 다음과 같은 Ajax.microsoft.com 가리키는 태그를 <script> 페이지에 추가하여 jQuery 라이브러리 사용을 시작할 수 있습니다.

<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>

Microsoft Ajax CDN을 사용하여 Ajax 응용 프로그램의 성능을 크게 향상시킬 수 있습니다. Microsoft Ajax CDN의 콘텐츠는 전 세계 서버에 캐시됩니다. 또한 Microsoft Ajax CDN을 통해 브라우저에서 다른 도메인에 있는 웹 사이트에 대한 캐시된 JavaScript 파일을 다시 사용할 수 있습니다.

Microsoft Ajax Content Delivery Network는 보안 소켓 계층을 사용하여 웹 페이지를 제공해야 하는 경우 SSL(HTTPS)을 지원합니다.

CDN을 사용할 수 없는 경우 대체를 구현합니다. 대체를 테스트합니다.

Microsoft Ajax CDN에 대해 자세히 알아보려면 다음 웹 사이트를 방문하세요.

https://www.asp.net/ajaxlibrary/CDN.ashx

ASP.NET ScriptManager는 Microsoft Ajax CDN을 지원합니다. EnableCdn 속성 하나만 설정하면 CDN에서 모든 ASP.NET 프레임워크 JavaScript 파일을 검색할 수 있습니다.

<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />

EnableCdn 속성을 true 값으로 설정하면 ASP.NET 프레임워크는 유효성 검사에 사용되는 모든 JavaScript 파일과 UpdatePanel을 포함하여 CDN에서 모든 ASP.NET 프레임워크 JavaScript 파일을 검색합니다. 이 하나의 속성을 설정하면 웹 애플리케이션의 성능에 큰 영향을 미칠 수 있습니다.

WebResource 특성을 사용하여 사용자 고유의 JavaScript 파일에 대한 CDN 경로를 설정할 수 있습니다. 새 CdnPath 속성은 EnableCdn 속성을 true 값으로 설정할 때 사용되는 CDN의 경로를 지정합니다.

[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]

ScriptManager 명시적 스크립트

이전에는 ASP.NET ScriptManger를 사용한 경우 전체 모놀리식 ASP.NET Ajax 라이브러리를 로드해야 했습니다. 새 ScriptManager.AjaxFrameworkMode 속성을 활용하여 ASP.NET Ajax 라이브러리의 구성 요소를 정확히 제어하고 필요한 ASP.NET Ajax 라이브러리의 구성 요소만 로드할 수 있습니다.

ScriptManager.AjaxFrameworkMode 속성을 다음 값으로 설정할 수 있습니다.

  • 사용 -- ScriptManager 컨트롤에 모든 핵심 프레임워크 스크립트(레거시 동작)의 결합된 스크립트 파일인 MicrosoftAjax.js 스크립트 파일이 자동으로 포함되도록 지정합니다.
  • 사용 안 함 - 모든 Microsoft Ajax 스크립트 기능이 비활성화되고 ScriptManager 컨트롤이 스크립트를 자동으로 참조하지 않도록 지정합니다.
  • 명시적 -- 페이지에 필요한 개별 프레임워크 핵심 스크립트 파일에 대한 스크립트 참조를 명시적으로 포함하고 각 스크립트 파일에 필요한 종속성에 대한 참조를 포함하도록 지정합니다.

예를 들어 AjaxFrameworkMode 속성을 Explicit 값으로 설정하면 필요한 특정 ASP.NET Ajax 구성 요소 스크립트를 지정할 수 있습니다.

<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">

<Scripts>
    <asp:ScriptReference Name="MicrosoftAjaxCore.js" />
    <asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
    <asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
    <asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />    
</Scripts>
</asp:ScriptManager>

Web Forms

Web Forms ASP.NET 1.0 릴리스 이후 ASP.NET 핵심 기능이었습니다. 다음을 포함하여 ASP.NET 4에 대한 많은 향상된 기능이 이 영역에 있습니다.

  • 메타 태그를 설정하는 기능입니다.
  • 보기 상태에 대한 제어를 더 많이 합니다.
  • 브라우저 기능을 더 쉽게 사용할 수 있습니다.
  • Web Forms ASP.NET 라우팅 사용을 지원합니다.
  • 생성된 ID에 대한 더 많은 제어.
  • 데이터 컨트롤에서 선택한 행을 유지하는 기능입니다.
  • FormView 및 ListView 컨트롤에서 렌더링된 HTML을 더 자세히 제어합니다.
  • 데이터 원본 컨트롤에 대한 필터링 지원.

Page.MetaKeywords 및 Page.MetaDescription 속성을 사용하여 메타 태그 설정

ASP.NET 4는 Page 클래스 MetaKeywords 및 MetaDescription에 두 개의 속성을 추가합니다. 이러한 두 속성은 다음 예제와 같이 페이지의 해당 메타 태그를 나타냅니다.

<head id="Head1" runat="server"> 
  <title>Untitled Page</title> 
  <meta name="keywords" content="These, are, my, keywords" /> 
  <meta name="description" content="This is the description of my page" /> 
</head>

이 두 속성은 페이지의 Title 속성과 동일한 방식으로 작동합니다. 다음 규칙을 따릅니다.

  1. Head 요소에 속성 이름(Page.MetaKeywords의 경우 name="keywords", Page.MetaDescription의 경우 name="description")과 일치하는 메타 태그가 없으면 메타 태그가 렌더링될 때 페이지에 추가됩니다.
  2. 이러한 이름의 메타 태그가 이미 있는 경우 이러한 속성은 기존 태그의 내용에 대한 get 및 set 메서드 역할을 합니다.

런타임에 이러한 속성을 설정하여 데이터베이스 또는 다른 원본에서 콘텐츠를 가져올 수 있으며 태그를 동적으로 설정하여 특정 페이지의 대상을 설명할 수 있습니다.

다음 예제와 같이 Web Forms 페이지 태그 맨 위에 있는 @ Page 지시문에서 키워드 및 설명 속성을 설정할 수도 있습니다.

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  Keywords="These, are, my, keywords" 
  Description="This is a description" %>

그러면 페이지에 이미 선언된 메타 태그 내용(있는 경우)이 재정의됩니다.

설명 메타 태그의 내용은 Google에서 검색 목록 미리 보기를 개선하는 데 사용됩니다. 자세한 내용은 Google Webmaster Central 블로그 에서 메타 설명으로 코드 조각 개선을 참조하세요. Google 및 Windows Live Search는 키워드의 콘텐츠를 아무것도 사용하지 않지만 다른 검색 엔진은 사용할 수 있습니다.

이러한 새 속성은 간단한 기능이지만 이러한 속성을 수동으로 추가하거나 메타 태그를 만들기 위한 사용자 고유의 코드를 작성할 필요가 없습니다.

개별 컨트롤에 대해 상태 보기 사용

기본적으로 보기 상태는 페이지에 대해 사용하도록 설정되며, 그 결과 페이지의 각 컨트롤은 애플리케이션에 필요하지 않더라도 보기 상태를 잠재적으로 저장합니다. 보기 상태 데이터는 페이지가 생성하고 클라이언트에 페이지를 보내고 다시 게시하는 데 걸리는 시간을 늘리는 태그에 포함됩니다. 필요한 것보다 더 많은 뷰 상태를 저장하면 성능이 크게 저하될 수 있습니다. 이전 버전의 ASP.NET 개발자는 페이지 크기를 줄이기 위해 개별 컨트롤에 대한 보기 상태를 사용하지 않도록 설정할 수 있었지만 개별 컨트롤에 대해 명시적으로 표시해야 했습니다. ASP.NET 4에서 웹 서버 컨트롤에는 기본적으로 보기 상태를 사용하지 않도록 설정한 다음 페이지에서 필요한 컨트롤에 대해서만 사용하도록 설정할 수 있는 ViewStateMode 속성이 포함됩니다.

ViewStateMode 속성은 Enabled, Disabled 및 Inherit의 세 가지 값이 있는 열거형을 사용합니다. 사용하도록 설정하면 해당 컨트롤 및 상속으로 설정되거나 아무것도 설정되지 않은 자 식 컨트롤에 대한 보기 상태가 활성화됩니다. 사용 안 함으로 설정하면 뷰 상태가 비활성화되고 상속 은 컨트롤이 부모 컨트롤에서 ViewStateMode 설정을 사용하도록 지정합니다.

다음 예제에서는 ViewStateMode 속성의 작동 방식을 보여 줍니다. 다음 페이지의 컨트롤에 대한 태그 및 코드에는 ViewStateMode 속성에 대한 값이 포함됩니다.

<form id="form1" runat="server"> 
  <script runat="server"> 
      protected override void OnLoad(EventArgs e) { 
      if (!IsPostBack) { 
        label1.Text = label2.Text = "[DynamicValue]"; 
      } 
      base.OnLoad(e); 
    } 
  </script> 
  <asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled"> 
      Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br /> 
    <asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled"> 
        Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" /> 
    </asp:PlaceHolder> 
  </asp:PlaceHolder> 
  <hr /> 
  <asp:button ID="Button1" runat="server" Text="Postback" /> 
  <%-- Further markup here --%>

보듯이 코드는 PlaceHolder1 컨트롤에 대한 보기 상태를 사용하지 않도록 설정합니다. 자식 label1 컨트롤은 이 속성 값을 상속하므로(상속 은 컨트롤에 대한 ViewStateMode 의 기본값입니다.) 따라서 뷰 상태를 저장하지 않습니다. PlaceHolder2 컨트롤에서 ViewStateMode 는 Enabled로 설정되므로 label2는 이 속성을 상속하고 뷰 상태를 저장합니다. 페이지가 처음 로드되면 두 Label 컨트롤의 Text 속성이 "[DynamicValue] 문자열로 설정됩니다.

이러한 설정의 효과는 페이지가 처음 로드될 때 브라우저에 다음 출력이 표시된다는 것입니다.

비활성화 : [DynamicValue]

사용:[DynamicValue]

그러나 포스트백 후에는 다음 출력이 표시됩니다.

비활성화 : [DeclaredValue]

사용:[DynamicValue]

label1 컨트롤(ViewStateMode 값이 Disabled로 설정됨)은 코드에서 로 설정된 값을 유지하지 않았습니다. 그러나 label2 컨트롤(ViewStateMode 값이 Enabled로 설정됨)은 해당 상태를 유지했습니다.

다음 예제와 같이 @ Page 지시문에서 ViewStateMode를 설정할 수도 있습니다.

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeBehind="Default.aspx.cs" 
  Inherits="WebApplication1._Default" 
  ViewStateMode="Disabled" %>

Page 클래스는 다른 컨트롤일 뿐입니다. 페이지의 다른 모든 컨트롤에 대한 부모 컨트롤 역할을 합니다. ViewStateMode의 기본값은 Page 인스턴스에 대해 사용입니다. 컨트롤은 기본값 상속이므로 페이지 또는 컨트롤 수준에서 ViewStateMode를 설정하지 않는 한 컨트롤은 Enabled 속성 값을 상속합니다.

ViewStateMode 속성 값은 EnableViewState 속성이 true로 설정된 경우에만 보기 상태가 유지되는지 여부를 결정합니다. EnableViewState 속성을 false로 설정하면 ViewStateMode가 Enabled로 설정된 경우에도 보기 상태가 유지되지 않습니다.

이 기능에는 master 페이지의 ContentPlaceHolder 컨트롤을 사용하는 것이 좋습니다. 여기서 master 페이지에 대해 ViewStateMode를 사용 안 함으로 설정한 다음 보기 상태가 필요한 컨트롤을 포함하는 ContentPlaceHolder 컨트롤에 대해 개별적으로 사용하도록 설정할 수 있습니다.

브라우저 기능 변경

ASP.NET 사용자가 브라우저 기능이라는 기능을 사용하여 사이트를 검색하는 데 사용하는 브라우저의 기능을 결정합니다. 브라우저 기능은 HttpBrowserCapabilities 개체( Request.Browser 속성에 의해 노출됨)로 표시됩니다. 예를 들어 HttpBrowserCapabilities 개체를 사용하여 현재 브라우저의 형식과 버전이 특정 버전의 JavaScript를 지원하는지 여부를 확인할 수 있습니다. 또는 HttpBrowserCapabilities 개체를 사용하여 요청이 모바일 디바이스에서 시작되었는지 여부를 확인할 수 있습니다.

HttpBrowserCapabilities 개체는 브라우저 정의 파일 집합에 의해 구동됩니다. 이러한 파일에는 특정 브라우저의 기능에 대한 정보가 포함되어 있습니다. ASP.NET 4에서, 이러한 브라우저 정의 파일은 최근 도입 된 브라우저와 구글 크롬, 모션 블랙 베리 스마트 폰의 연구, 애플 아이폰과 같은 장치에 대한 정보를 포함하도록 업데이트되었습니다.

다음 목록에는 새 브라우저 정의 파일이 나와 있습니다.

  • blackberry.browser
  • chrome.browser
  • Default.browser
  • firefox.browser
  • gateway.browser
  • generic.browser
  • ie.browser
  • iemobile.browser
  • iphone.browser
  • opera.browser
  • safari.browser

브라우저 기능 공급자 사용

ASP.NET 버전 3.5 서비스 팩 1에서 브라우저에 있는 기능을 다음과 같은 방법으로 정의할 수 있습니다.

  • 컴퓨터 수준에서 다음 폴더에 .browser XML 파일을 만들거나 업데이트합니다.

  • \Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

  • 브라우저 기능을 정의한 후 Visual Studio 명령 프롬프트에서 다음 명령을 실행하여 브라우저 기능 어셈블리를 다시 빌드하고 GAC에 추가합니다.

  • aspnet_regbrowsers.exe -I c

  • 개별 애플리케이션의 경우 애플리케이션의 App_Browsers 폴더에 파일을 만듭니 .browser 다.

이러한 접근 방식을 사용하려면 XML 파일을 변경해야 하며 컴퓨터 수준 변경의 경우 aspnet_regbrowsers.exe 프로세스를 실행한 후 애플리케이션을 다시 시작해야 합니다.

ASP.NET 4에는 브라우저 기능 공급자라고 하는 기능이 포함되어 있습니다. 이름에서 알 수 있듯이 이를 통해 공급자를 빌드하여 자체 코드를 사용하여 브라우저 기능을 확인할 수 있습니다.

실제로 개발자는 사용자 지정 브라우저 기능을 정의하지 않는 경우가 많습니다. 브라우저 파일은 업데이트하기 어렵고 업데이트 프로세스는 상당히 복잡하며 파일의 XML 구문 .browser 은 사용하고 정의하기 복잡할 수 있습니다. 이 프로세스를 훨씬 쉽게 만드는 것은 일반적인 브라우저 정의 구문이나 최신 브라우저 정의가 포함된 데이터베이스 또는 이러한 데이터베이스에 대한 웹 서비스가 있는 경우입니다. 새로운 브라우저 기능 공급자 기능을 사용하면 타사 개발자가 이러한 시나리오를 가능하고 실용적으로 사용할 수 있습니다.

새로운 ASP.NET 4 브라우저 기능 공급자 기능을 사용하는 두 가지 기본 방법이 있습니다. 즉, ASP.NET 브라우저 기능 정의 기능을 확장하거나 완전히 대체합니다. 다음 섹션에서는 먼저 기능을 바꾸는 방법과 기능을 확장하는 방법을 설명합니다.

ASP.NET 브라우저 기능 교체

ASP.NET 브라우저 기능 정의 기능을 완전히 대체하려면 다음 단계를 수행합니다.

  1. 다음 예제와 같이 HttpCapabilitiesProvider 에서 파생되고 GetBrowserCapabilities 메서드를 재정의하는 공급자 클래스를 만듭니다.

    public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); 
        Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); 
        values[String.Empty] = request.UserAgent; 
        values["browser"] = "MyCustomBrowser"; 
        browserCaps.Capabilities = values; 
        return browserCaps;
    } 
}

    이 예제의 코드는 브라우저라는 기능만 지정하고 해당 기능을 MyCustomBrowser로 설정하여 새 HttpBrowserCapabilities 개체를 만듭니다.

  2. 애플리케이션에 공급자를 등록합니다.

    애플리케이션에서 공급자를 사용하려면 또는 Machine.config 파일의 browserCaps 섹션에 Web.config공급자 특성을 추가해야 합니다. (특정 모바일 디바이스의 폴더와 같이 애플리케이션의 특정 디렉터리에 대한 위치 요소에서 공급자 특성을 정의할 수도 있습니다.) 다음 예제에서는 구성 파일에서 공급자 특성을 설정하는 방법을 보여줍니다.

    <system.web> 
<browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, 
  Version=1.0.0.0, Culture=neutral" /> 
</system.web>

    새 브라우저 기능 정의를 등록하는 또 다른 방법은 다음 예제와 같이 코드를 사용하는 것입니다.

    void Application_Start(object sender, EventArgs e) 
{ 
    HttpCapabilitiesBase.BrowserCapabilitiesProvider =
    new ClassLibrary2.CustomProvider();
    // ... 
 }

    이 코드는 파일의 Application_Start 이벤트에서 Global.asax 실행되어야 합니다. 해결된 HttpCapabilitiesBase 개체에 대해 캐시가 유효한 상태로 유지되도록 하려면 애플리케이션의 코드가 실행되기 전에 BrowserCapabilitiesProvider 클래스를 변경해야 합니다.

HttpBrowserCapabilities 개체 캐싱

앞의 예제에는 HttpBrowserCapabilities 개체를 가져오기 위해 사용자 지정 공급자가 호출될 때마다 코드가 실행된다는 문제가 있습니다. 이 작업은 각 요청 중에 여러 번 발생할 수 있습니다. 이 예제에서 공급자에 대한 코드는 많은 작업을 수행하지 않습니다. 그러나 사용자 지정 공급자의 코드가 HttpBrowserCapabilities 개체를 가져오기 위해 상당한 작업을 수행하는 경우 성능에 영향을 줄 수 있습니다. 이러한 일이 발생하지 않도록 HttpBrowserCapabilities 개체를 캐시할 수 있습니다. 다음 단계를 수행합니다.

  1. 다음 예제와 같이 HttpCapabilitiesProvider에서 파생되는 클래스를 만듭니다.

    public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        string cacheKey = BuildCacheKey(); 
        int cacheTime = GetCacheTime(); 
        HttpBrowserCapabilities browserCaps = 
        HttpContext.Current.Cache[cacheKey] as 
        HttpBrowserCapabilities; 
        if (browserCaps == null) 
        { 
            HttpBrowserCapabilities browserCaps = new 
            HttpBrowserCapabilities(); 
            Hashtable values = new Hashtable(180, 
            StringComparer.OrdinalIgnoreCase); 
            values[String.Empty] = request.UserAgent; 
            values["browser"] = "MyCustomBrowser"; 
            browserCaps.Capabilities = values; 
            HttpContext.Current.Cache.Insert(cacheKey, 
            browserCaps, null, DateTime.MaxValue, 
            TimeSpan.FromSeconds(cacheTime));
        } 
        return browserCaps; 
    } 
}

    이 예제에서 코드는 사용자 지정 BuildCacheKey 메서드를 호출하여 캐시 키를 생성하고 사용자 지정 GetCacheTime 메서드를 호출하여 캐시할 시간을 가져옵니다. 그런 다음, 코드는 확인된 HttpBrowserCapabilities 개체를 캐시에 추가합니다. 개체는 캐시에서 검색하고 사용자 지정 공급자를 사용하는 후속 요청에 다시 사용할 수 있습니다.

  2. 이전 절차에서 설명한 대로 애플리케이션에 공급자를 등록합니다.

ASP.NET 브라우저 기능 확장

이전 섹션에서는 ASP.NET 4에서 새 HttpBrowserCapabilities 개체를 만드는 방법을 설명했습니다. 이미 ASP.NET 있는 브라우저 기능 정의에 새 브라우저 기능 정의를 추가하여 ASP.NET 브라우저 기능 기능을 확장할 수도 있습니다. XML 브라우저 정의를 사용하지 않고 이 작업을 수행할 수 있습니다. 다음 절차에서는 방법을 보여줍니다.

  1. 다음 예제와 같이 HttpCapabilitiesEvaluator 에서 파생되고 GetBrowserCapabilities 메서드를 재정의하는 클래스를 만듭니다.

    public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
        base.GetHttpBrowserCapabilities(request);
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    } 
}

    이 코드는 먼저 ASP.NET 브라우저 기능 기능을 사용하여 브라우저를 식별합니다. 그러나 요청에 정의된 정보를 기반으로 브라우저가 식별되지 않는 경우(즉, HttpBrowserCapabilities 개체의 Browser 속성이 문자열 "알 수 없음"인 경우) 코드는 사용자 지정 공급자(MyBrowserCapabilitiesEvaluator)를 호출하여 브라우저를 식별합니다.

  2. 이전 예제에 설명된 대로 애플리케이션에 공급자를 등록합니다.

기존 기능 정의에 새 기능을 추가하여 브라우저 기능 기능 확장

사용자 지정 브라우저 정의 공급자를 만들고 새 브라우저 정의를 동적으로 만드는 것 외에도 추가 기능을 사용하여 기존 브라우저 정의를 확장할 수 있습니다. 이렇게 하면 원하는 것과 가깝지만 몇 가지 기능만 부족한 정의를 사용할 수 있습니다. 이렇게 하려면 다음 단계를 따릅니다.

  1. 다음 예제와 같이 HttpCapabilitiesEvaluator 에서 파생되고 GetBrowserCapabilities 메서드를 재정의하는 클래스를 만듭니다.

    public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
          base.GetHttpBrowserCapabilities(request); 
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    }
}

    예제 코드는 기존 ASP.NET HttpCapabilitiesEvaluator 클래스를 확장하고 다음 코드를 사용하여 현재 요청 정의와 일치하는 HttpBrowserCapabilities 개체를 가져옵니다.

    HttpBrowserCapabilities browserCaps = 
    base.GetHttpBrowserCapabilities(request);

    그러면 코드에서 이 브라우저에 대한 기능을 추가하거나 수정할 수 있습니다. 새 브라우저 기능을 지정하는 방법에는 두 가지가 있습니다.

    • HttpCapabilitiesBase 개체의 Capabilities 속성에 의해 노출되는 IDictionary 개체에 키/값 쌍을 추가합니다. 이전 예제에서 코드는 값이 true인 MultiTouch라는 기능을 추가합니다.

    • HttpCapabilitiesBase 개체의 기존 속성을 설정합니다. 이전 예제에서 코드는 Frames 속성을 true로 설정합니다. 이 속성은 Capabilities 속성에 의해 노출되는 IDictionary 개체의 접근자일 뿐입니다.

      참고

      참고 이 모델은 제어 어댑터를 포함하여 HttpBrowserCapabilities의 모든 속성에 적용됩니다.

  2. 이전 절차에서 설명한 대로 애플리케이션에 공급자를 등록합니다.

ASP.NET 4의 라우팅

ASP.NET 4는 Web Forms 라우팅 사용에 대한 기본 제공 지원을 추가합니다. 라우팅을 사용하면 물리적 파일에 매핑되지 않는 요청 URL을 수락하도록 애플리케이션을 구성할 수 있습니다. 대신 라우팅을 사용하여 사용자에게 의미가 있고 애플리케이션에 대한 SEO(검색 엔진 최적화)에 도움이 될 수 있는 URL을 정의할 수 있습니다. 예를 들어 기존 애플리케이션에서 제품 범주를 표시하는 페이지의 URL은 다음 예제와 같을 수 있습니다.

http://website/products.aspx?categoryid=12

라우팅을 사용하여 동일한 정보를 렌더링하도록 다음 URL을 허용하도록 애플리케이션을 구성할 수 있습니다.

http://website/products/software

라우팅은 ASP.NET 3.5 SP1부터 사용할 수 있습니다. (ASP.NET 3.5 SP1에서 라우팅을 사용하는 방법의 예는 Phil Haack의 블로그에서 WebForms로 라우팅 사용 .) 그러나 ASP.NET 4에는 다음을 포함하여 라우팅을 더 쉽게 사용할 수 있는 몇 가지 기능이 포함되어 있습니다.

  • 경로를 정의할 때 사용하는 간단한 HTTP 처리기인 PageRouteHandler 클래스입니다. 클래스는 요청이 라우팅되는 페이지에 데이터를 전달합니다.
  • 새 속성 HttpRequest.RequestContext 및 Page.RouteData ( HttpRequest.RequestContext.RouteData 개체의 프록시임). 이러한 속성을 사용하면 경로에서 전달되는 정보에 더 쉽게 액세스할 수 있습니다.
  • System.Web.Compilation.RouteUrlExpressionBuilder 및 System.Web.Compilation.RouteValueExpressionBuilder에 정의된 다음 새 식 작성기:
  • RouteUrl - ASP.NET 서버 컨트롤 내에서 경로 URL에 해당하는 URL을 만드는 간단한 방법을 제공합니다.
  • RouteContext 개체에서 정보를 추출하는 간단한 방법을 제공하는 RouteValue입니다.
  • RouteParameter 클래스를 사용하면 RouteContext 개체에 포함된 데이터를 FormParameter와 유사하게 데이터 원본 컨트롤에 대한 쿼리에 더 쉽게 전달할 수 있습니다.

Web Forms 페이지에 대한 라우팅

다음 예제에서는 Route 클래스의 새 MapPageRoute 메서드를 사용하여 Web Forms 경로를 정의하는 방법을 보여 줍니다.

public class Global : System.Web.HttpApplication 
{ 
    void Application_Start(object sender, EventArgs e) 
    { 
        RouteTable.Routes.MapPageRoute("SearchRoute", 
          "search/{searchterm}", "~/search.aspx"); 
        RouteTable.Routes.MapPageRoute("UserRoute", 
          "users/{username}", "~/users.aspx"); 
    } 
}

ASP.NET 4에서는 MapPageRoute 메서드를 소개합니다. 다음 예제는 이전 예제에 표시된 SearchRoute 정의와 동일하지만 PageRouteHandler 클래스를 사용합니다.

RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}", 
  new PageRouteHandler("~/search.aspx")));

예제의 코드는 경로를 실제 페이지(첫 번째 경로 ~/search.aspx에서 )에 매핑합니다. 또한 첫 번째 경로 정의는 searchterm이라는 매개 변수를 URL에서 추출하여 페이지로 전달하도록 지정합니다.

MapPageRoute 메서드는 다음 메서드 오버로드를 지원합니다.

  • MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess)
  • MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary 기본값)
  • MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary 기본값, RouteValueDictionary 제약 조건)

checkPhysicalUrlAccess 매개 변수는 경로가 라우팅되는 실제 페이지(이 경우 search.aspx)에 대한 보안 권한과 들어오는 URL(이 경우 search/{searchterm})에 대한 권한을 검사 여부를 지정합니다. checkPhysicalUrlAccess 값이 false이면 들어오는 URL의 권한만 확인됩니다. 이러한 권한은 다음과 같은 설정을 사용하여 파일에 정의 Web.config 됩니다.

<configuration> 
  <location path="search.aspx"> 
    <system.web> 
      <authorization> 
        <allow roles="admin"/> 
        <deny users="*"/> 
      </authorization> 
    </system.web> 
  </location> 
  <location path="search"> 
    <system.web> 
      <authorization> 
        <allow users="*"/> 
      </authorization> 
    </system.web> 
  </location> 

</configuration>

예제 구성에서 관리자 역할에 있는 사용자를 제외한 모든 사용자의 실제 페이지에 search.aspx 대한 액세스가 거부됩니다. checkPhysicalUrlAccess 매개 변수를 true(기본값)로 설정하면 실제 페이지 search.aspx가 해당 역할의 사용자로 제한되므로 관리자 사용자만 URL /search/{searchterm}에 액세스할 수 있습니다. checkPhysicalUrlAccess가 false로 설정되어 있고 사이트가 이전 예제와 같이 구성된 경우 인증된 모든 사용자가 URL /search/{searchterm}에 액세스할 수 있습니다.

Web Forms 페이지에서 라우팅 정보 읽기

Web Forms 물리적 페이지의 코드에서 HttpRequest.RequestContext 및 Page.RouteData라는 두 가지 새 속성을 사용하여 URL(또는 다른 개체가 RouteData 개체에 추가한 기타 정보)에서 라우팅이 추출한 정보에 액세스할 수 있습니다. (Page.RouteData 는 HttpRequest.RequestContext.RouteData를 래핑합니다.) 다음 예제에서는 Page.RouteData를 사용하는 방법을 보여줍니다.

protected void Page_Load(object sender, EventArgs e) 
{ 
    string searchterm = Page.RouteData.Values["searchterm"] as string; 
    label1.Text = searchterm; 
}

이 코드는 이전에 예제 경로에 정의된 대로 searchterm 매개 변수에 대해 전달된 값을 추출합니다. 다음 요청 URL을 고려합니다.

http://localhost/search/scott/

이 요청이 수행되면 페이지에 "scott"이라는 단어가 렌더링됩니다 search.aspx .

태그의 라우팅 정보에 액세스

이전 섹션에서 설명한 메서드는 Web Forms 페이지의 코드에서 경로 데이터를 가져오는 방법을 보여줍니다. 동일한 정보에 액세스할 수 있도록 태그에 식을 사용할 수도 있습니다. 식 작성자는 선언적 코드를 사용하는 강력하고 우아한 방법입니다. 자세한 내용은 Phil Haack의 블로그에서 사용자 지정 식 작성기를 사용하여 본 인 표현 항목을 참조하세요.

ASP.NET 4에는 Web Forms 라우팅을 위한 두 개의 새 식 작성기가 포함되어 있습니다. 다음 예제에서는 사용하는 방법을 보여줍니다.

<asp:HyperLink ID="HyperLink1" runat="server" 
  NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>

예제에서 RouteUrl 식은 경로 매개 변수를 기반으로 하는 URL을 정의하는 데 사용됩니다. 이렇게 하면 전체 URL을 태그에 하드 코딩할 필요가 없으며 나중에 이 링크를 변경하지 않고도 URL 구조를 변경할 수 있습니다.

앞에서 정의한 경로에 따라 이 태그는 다음 URL을 생성합니다.

http://localhost/search/scott

ASP.NET 입력 매개 변수에 따라 올바른 경로(즉, 올바른 URL을 생성)를 자동으로 작동합니다. 사용할 경로를 지정할 수 있는 경로 이름을 식에 포함할 수도 있습니다.

다음 예제에서는 RouteValue 식을 사용하는 방법을 보여줍니다.

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />

이 컨트롤이 포함된 페이지가 실행되면 레이블에 "scott" 값이 표시됩니다.

RouteValue 식을 사용하면 태그에서 경로 데이터를 간단하게 사용할 수 있으며 태그에서 더 복잡한 Page.RouteData["x"] 구문을 사용할 필요가 없습니다.

데이터 원본 제어 매개 변수에 경로 데이터 사용

RouteParameter 클래스를 사용하면 경로 데이터를 데이터 소스 컨트롤의 쿼리에 대한 매개 변수 값으로 지정할 수 있습니다. 다음 예제와 같이 클래스와 매우 유사하게 작동합니다 .

<asp:sqldatasource id="SqlDataSource1" runat="server" 
    connectionstring="<%$ ConnectionStrings:MyNorthwind %>" 
    selectcommand="SELECT CompanyName,ShipperID FROM Shippers where 
      CompanyName=@companyname" 
  <selectparameters> 
    <asp:routeparameter name="companyname" RouteKey="searchterm" /> 
  </selectparameters> 

</asp:sqldatasource>

이 경우 경로 매개 변수 searchterm의 값은 Select 문의 매개 변수에 사용됩니다@companyname.

클라이언트 ID 설정

새 ClientIDMode 속성은 ASP.NET 오랜 문제, 즉 컨트롤이 렌더링하는 요소에 대한 ID 특성을 만드는 방법을 해결합니다. 애플리케이션에 이러한 요소를 참조하는 클라이언트 스크립트가 포함된 경우 렌더링된 요소의 ID 특성을 아는 것이 중요합니다.

웹 서버 컨트롤에 대해 렌더링되는 HTML의 ID 특성은 컨트롤의 ClientID 속성을 기반으로 생성됩니다. ASP.NET 4까지 ClientID 속성에서 id 특성을 생성하는 알고리즘은 이름 지정 컨테이너(있는 경우)를 ID와 연결하고 반복 컨트롤의 경우(데이터 컨트롤에서와 같이) 접두사 및 순차 번호를 추가하는 것이었습니다. 이는 항상 페이지에 있는 컨트롤의 ID가 고유하도록 보장하지만 알고리즘으로 인해 예측할 수 없는 제어 ID가 발생하므로 클라이언트 스크립트에서 참조하기가 어려웠습니다.

새 ClientIDMode 속성을 사용하면 컨트롤에 대해 클라이언트 ID를 생성하는 방법을 보다 정확하게 지정할 수 있습니다. 페이지를 비롯한 모든 컨트롤에 대해 ClientIDMode 속성을 설정할 수 있습니다. 가능한 설정은 다음과 같습니다.

  • AutoID – 이전 버전의 ASP.NET 사용된 ClientID 속성 값을 생성하는 알고리즘과 동일합니다.
  • 정적 – 부모 명명 컨테이너의 ID를 연결하지 않고 ClientID 값이 ID와 동일하게 지정합니다. 이는 웹 사용자 컨트롤에서 유용할 수 있습니다. 웹 사용자 컨트롤은 다른 페이지와 다른 컨테이너 컨트롤에 있을 수 있으므로 ID 값을 예측할 수 없으므로 AutoID 알고리즘을 사용하는 컨트롤에 대한 클라이언트 스크립트를 작성하기 어려울 수 있습니다.
  • 예측 가능 – 이 옵션은 주로 반복 템플릿을 사용하는 데이터 컨트롤에서 사용하기 위한 것입니다. 컨트롤의 명명 컨테이너의 ID 속성을 연결하지만 생성된 ClientID 값에는 "ctlxxx"와 같은 문자열이 포함되지 않습니다. 이 설정은 컨트롤의 ClientIDRowSuffix 속성과 함께 작동합니다. ClientIDRowSuffix 속성을 데이터 필드 이름으로 설정하면 해당 필드의 값이 생성된 ClientID 값의 접미사로 사용됩니다. 일반적으로 데이터 레코드의 기본 키를 ClientIDRowSuffix 값으로 사용합니다.
  • 상속 – 이 설정은 컨트롤의 기본 동작입니다. 컨트롤의 ID 생성이 해당 부모와 동일하다는 것을 지정합니다.

페이지 수준에서 ClientIDMode 속성을 설정할 수 있습니다. 현재 페이지의 모든 컨트롤에 대한 기본 ClientIDMode 값을 정의합니다.

페이지 수준의 기본 ClientIDMode 값은 AutoID이고 컨트롤 수준의 기본 ClientIDMode 값은 상속입니다. 따라서 코드에서 이 속성을 설정하지 않으면 모든 컨트롤이 기본적으로 AutoID 알고리즘으로 설정됩니다.

다음 예제와 같이 @ Page 지시문에서 페이지 수준 값을 설정합니다.

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  ClientIDMode="Predictable" %>

컴퓨터(컴퓨터) 수준 또는 애플리케이션 수준에서 구성 파일에서 ClientIDMode 값을 설정할 수도 있습니다. 애플리케이션의 모든 페이지에 있는 모든 컨트롤에 대한 기본 ClientIDMode 설정을 정의합니다. 컴퓨터 수준에서 값을 설정하는 경우 해당 컴퓨터의 모든 웹 사이트에 대한 기본 ClientIDMode 설정을 정의합니다. 다음 예제에서는 구성 파일의 ClientIDMode 설정을 보여줍니다.

<system.web> 
  <pages clientIDMode="Predictable"></pages> 
</system.web>

앞에서 설명한 대로 ClientID 속성의 값은 컨트롤의 부모에 대한 명명 컨테이너에서 파생됩니다. master 페이지를 사용하는 경우와 같은 일부 시나리오에서는 컨트롤이 렌더링된 다음 HTML의 ID와 같은 ID로 끝날 수 있습니다.

<div id="ctl00_ContentPlaceHolder1_ParentPanel"> 
  <div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
      type="text" value="Hello!" 
      id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" /> 
</div>

태그에 표시된 입력 요소(TextBox 컨트롤)가 페이지 깊숙이 있는 두 개의 명명 컨테이너(중첩 ContentPlaceholder 컨트롤)에 불과하지만 master 페이지가 처리되는 방식 때문에 최종 결과는 다음과 같은 컨트롤 ID입니다.

ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

이 ID는 페이지에서 고유하도록 보장되지만 대부분의 경우 불필요하게 길어집니다. 렌더링된 ID의 길이를 줄이고 ID 생성 방법을 더 자세히 제어하려고 합니다. 예를 들어 "ctlxxx" 접두사를 제거하려고 합니다. 이 작업을 수행하는 가장 쉬운 방법은 다음 예제와 같이 ClientIDMode 속성을 설정하는 것입니다.

<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static"> 
  <tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable"> 
    <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox> 
  </tc:NamingPanel> 

</tc:NamingPanel>

이 샘플에서 ClientIDMode 속성은 가장 바깥쪽 NamingPanel 요소에 대해 Static으로 설정되고 내부 NamingControl 요소에 대해 예측 가능으로 설정됩니다. 이러한 설정으로 인해 다음 태그가 발생합니다(페이지의 나머지 부분과 master 페이지는 이전 예제와 동일한 것으로 간주됩니다.)

<div id="ParentPanel"> 
  <div id="ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
        type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" /> 
</div>

정적 설정은 가장 바깥쪽 NamingPanel 요소 내의 모든 컨트롤에 대한 명명 계층 구조를 다시 설정하고 생성된 ID에서 ContentPlaceHolder 및 MasterPage ID를 제거하는 효과가 있습니다. 렌더링된 요소의 이름 특성은 영향을 받지 않으므로 이벤트, 뷰 상태 등에 대해 일반적인 ASP.NET 기능이 유지됩니다. 명명 계층을 다시 설정하는 부작용은 NamingPanel 요소에 대한 태그를 다른 ContentPlaceholder 컨트롤로 이동하더라도 렌더링된 클라이언트 ID는 동일하게 유지된다는 것입니다.

참고

참고 렌더링된 컨트롤 ID가 고유한지 확인하는 것은 사용자에게 달려 있습니다. 그렇지 않은 경우 클라이언트 document.getElementById 함수와 같은 개별 HTML 요소에 고유한 ID가 필요한 기능을 중단할 수 있습니다.

Data-Bound 컨트롤에서 예측 가능한 클라이언트 ID 만들기

레거시 알고리즘에 의해 데이터 바인딩된 목록 컨트롤의 컨트롤에 대해 생성된 ClientID 값은 길 수 있으며 실제로 예측할 수 없습니다. ClientIDMode 기능을 사용하면 이러한 ID가 생성되는 방식을 보다 세밀하게 제어할 수 있습니다.

다음 예제의 태그에는 ListView 컨트롤이 포함됩니다.

<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1" 
    OnSelectedIndexChanged="ListView1_SelectedIndexChanged" 
    ClientIDMode="Predictable" 
    RowClientIDRowSuffix="ProductID"> 
</asp:ListView>

이전 예제에서는 ClientIDMode 및 RowClientIDRowSuffix 속성이 태그에 설정됩니다. ClientIDRowSuffix 속성은 데이터 바인딩된 컨트롤에서만 사용할 수 있으며 사용 중인 컨트롤에 따라 동작이 다릅니다. 차이점은 다음과 같습니다.

  • GridView 컨트롤 - 런타임에 결합된 데이터 원본에서 하나 이상의 열 이름을 지정하여 클라이언트 ID를 만들 수 있습니다. 예를 들어 RowClientIDRowSuffix 를 "ProductName, ProductId"로 설정하면 렌더링된 요소의 컨트롤 ID는 다음과 같은 형식이 됩니다.

  • rootPanel_GridView1_ProductNameLabel_Chai_1

  • ListView 컨트롤 - 클라이언트 ID에 추가되는 단일 열을 데이터 원본에 지정할 수 있습니다. 예를 들어 ClientIDRowSuffix 를 "ProductName"으로 설정하면 렌더링된 컨트롤 ID의 형식은 다음과 같습니다.

  • rootPanel_ListView1_ProductNameLabel_1

  • 이 경우 후행 1은 현재 데이터 항목의 제품 ID에서 파생됩니다.

  • 반복기 컨트롤 - 이 컨트롤은 ClientIDRowSuffix 속성을 지원하지 않습니다. Repeater 컨트롤에서 현재 행의 인덱스가 사용됩니다. Repeater 컨트롤과 함께 ClientIDMode="예측 가능"을 사용하면 다음과 같은 형식의 클라이언트 ID가 생성됩니다.

  • Repeater1_ProductNameLabel_0

  • 후행 0은 현재 행의 인덱스입니다.

FormView 및 DetailsView 컨트롤은 여러 행을 표시하지 않으므로 ClientIDRowSuffix 속성을 지원하지 않습니다.

데이터 컨트롤에서 행 선택 유지

GridView 및 ListView 컨트롤을 사용하면 사용자가 행을 선택할 수 있습니다. 이전 버전의 ASP.NET 페이지의 행 인덱스 기준이 선택되었습니다. 예를 들어 1페이지에서 세 번째 항목을 선택한 다음 2페이지로 이동하면 해당 페이지의 세 번째 항목이 선택됩니다.

지속형 선택은 처음에 .NET Framework 3.5 SP1의 동적 데이터 프로젝트에서만 지원되었습니다. 이 기능을 사용하도록 설정하면 현재 선택한 항목은 항목의 데이터 키를 기반으로 합니다. 즉, 1페이지에서 세 번째 행을 선택하고 2페이지로 이동하면 2페이지에서 아무것도 선택되지 않습니다. 1페이지로 다시 이동하면 세 번째 행이 계속 선택됩니다. 이제 다음 예제와 같이 EnablePersistedSelection 속성을 사용하여 모든 프로젝트의 GridView 및 ListView 컨트롤에 대해 지속형 선택이 지원됩니다.

<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true"> 
</asp:GridView>

ASP.NET 차트 컨트롤

ASP.NET 차트 컨트롤은 .NET Framework 데이터 시각화 제품을 확장합니다. 차트 컨트롤을 사용하여 복잡한 통계 또는 재무 분석을 위해 직관적이고 시각적으로 매력적인 차트가 있는 ASP.NET 페이지를 만들 수 있습니다. ASP.NET 차트 컨트롤은 .NET Framework 버전 3.5 SP1 릴리스에 대한 추가 기능으로 도입되었으며 .NET Framework 4 릴리스의 일부입니다.

컨트롤에는 다음 기능이 포함됩니다.

  • 35가지 개별 차트 종류
  • 차트 영역, 제목, 범례 및 주석을 무제한으로 사용할 수 있습니다.
  • 모든 차트 요소에 대한 다양한 모양 설정입니다.
  • 대부분의 차트 종류에 대한 3차원 지원.
  • 데이터 요소 주위에 자동으로 맞출 수 있는 스마트 데이터 레이블입니다.
  • 줄무늬, 배율 나누기 및 로그 크기 조정.
  • 데이터 분석 및 변환을 위한 50개가 넘는 재무 및 통계 수식
  • 차트 데이터의 간단한 바인딩 및 조작입니다.
  • 날짜, 시간 및 통화와 같은 일반적인 데이터 형식을 지원합니다.
  • Ajax를 사용하는 클라이언트 클릭 이벤트를 포함하여 대화형 작업 및 이벤트 기반 사용자 지정을 지원합니다.
  • 상태 관리
  • 이진 스트리밍

다음 그림에서는 ASP.NET 차트 컨트롤에서 생성되는 재무 차트의 예를 보여 줍니다.

ASP.NET 차트 컨트롤에서 생성된 네 개의 재무 차트 예제입니다.

그림 2: 차트 컨트롤 예제 ASP.NET

ASP.NET 차트 컨트롤을 사용하는 방법에 대한 자세한 예제를 보려면 MSDN 웹 사이트의 Microsoft 차트 컨트롤용 샘플 환경 페이지에서 샘플 코드를 다운로드하세요. 차트 제어 포럼에서 커뮤니티 콘텐츠의 더 많은 샘플을 찾을 수 있습니다.

ASP.NET 페이지에 차트 컨트롤 추가

다음 예제에서는 태그를 사용하여 ASP.NET 페이지에 차트 컨트롤을 추가하는 방법을 보여 줍니다. 예제에서 차트 컨트롤은 정적 데이터 요소에 대한 세로 막대형 차트를 생성합니다.

<asp:Chart ID="Chart1" runat="server"> 
  <Series> 
    <asp:Series Name="Series1" ChartType="Column"> 
      <Points> 
        <asp:DataPoint AxisLabel="Product A" YValues="345"/> 
        <asp:DataPoint AxisLabel="Product B" YValues="456"/> 
        <asp:DataPoint AxisLabel="Product C" YValues="125"/> 
        <asp:DataPoint AxisLabel="Product D" YValues="957"/> &

      lt;/Points> 
    </asp:Series> 
  </Series> 
  <ChartAreas> 
    <asp:ChartArea Name="ChartArea1"> 
      <AxisY IsLogarithmic="True" /> 
    </asp:ChartArea> 
  </ChartAreas> 
  <Legends> 
    <asp:Legend Name="Legend1" Title="Product Sales" /> 
  </Legends> 

</asp:Chart>

3차원 차트 사용

Chart 컨트롤에는 차트 영역의 특성을 정의하는 ChartArea 개체를 포함할 수 있는 ChartAreas 컬렉션이 포함되어 있습니다. 예를 들어 차트 영역에 3차원을 사용하려면 다음 예제와 같이 Area3DStyle 속성을 사용합니다.

<asp:ChartArea Name="ChartArea1"> 
  <area3dstyle 
      Rotation="10" 
      Perspective="10" 
      Enable3D="True" 
      Inclination="15" 
      IsRightAngleAxes="False" 
      WallWidth="0" 
      IsClustered="False" /> 
      
  <%-- Additional markup here --%> 
</asp:ChartArea>

아래 그림은 가로 막대형 차트 종류가 4개인 3차 원 차트를 보여줍니다.

가로 막대형 차트 종류 4개 계열을 보여 주는 3차원 가로 막대형 차트입니다.

그림 3: 3차원 가로 막대형 차트

배율 나누기 및 로그 눈금 사용

눈금 나누기와 로그 눈금은 차트에 정교함을 추가하는 두 가지 추가 방법입니다. 이러한 기능은 차트 영역의 각 축에 따라 다릅니다. 예를 들어 차트 영역의 기본 Y 축에서 이러한 기능을 사용하려면 ChartArea 개체에서 AxisY.IsLogarithmic 및 ScaleBreakStyle 속성을 사용합니다. 다음 코드 조각은 기본 Y축에서 눈금 나누기를 사용하는 방법을 보여 둡니다.

<asp:ChartArea Name="ChartArea1">

  <axisy>

    <ScaleBreakStyle 
        BreakLineStyle="Wave" 
        CollapsibleSpaceThreshold="40" 
        Enabled="True" />
  </axisy>

<%-- Additional markup here --%>
</asp:ChartArea>

아래 그림에서는 배율 구분이 활성화된 Y축을 보여 줍니다.

눈금 나누기를 사용하는 Y축을 보여 주는 가로 막대형 차트입니다.

그림 4: 배율 구분

QueryExtender 컨트롤을 사용하여 데이터 필터링

데이터 기반 웹 페이지를 만드는 개발자에게 매우 일반적인 작업은 데이터를 필터링하는 것입니다. 이 작업은 일반적으로 데이터 소스 컨트롤에서 Where 절을 빌드하여 수행되었습니다. 이 방법은 복잡할 수 있으며 경우에 따라 Where 구문을 사용하면 기본 데이터베이스의 전체 기능을 활용할 수 없습니다.

필터링을 더 쉽게 하기 위해 ASP.NET 4에 새 QueryExtender 컨트롤이 추가되었습니다. 이러한 컨트롤에서 반환된 데이터를 필터링하기 위해 이 컨트롤을 EntityDataSource 또는 LinqDataSource 컨트롤에 추가할 수 있습니다. QueryExtender 컨트롤은 LINQ를 사용하므로 데이터가 페이지로 전송되기 전에 데이터베이스 서버에 필터가 적용되므로 작업이 매우 효율적입니다.

QueryExtender 컨트롤은 다양한 필터 옵션을 지원합니다. 다음 섹션에서는 이러한 옵션에 대해 설명하고 사용 방법의 예를 제공합니다.

검색 옵션의 경우 QueryExtender 컨트롤은 지정된 필드에서 검색을 수행합니다. 다음 예제에서 컨트롤은 TextBoxSearch 컨트롤에 입력된 텍스트를 사용하고 LinqDataSource 컨트롤에서 반환된 데이터의 및 Supplier.CompanyName 열에서 해당 내용을 ProductName 검색합니다.

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:SearchExpression DataFields="ProductName, Supplier.CompanyName" 
      SearchType="StartsWith"> 
    <asp:ControlParameter ControlID="TextBoxSearch" /> 
  </asp:SearchExpression> 
</asp:QueryExtender>

범위

범위 옵션은 검색 옵션과 비슷하지만 범위를 정의할 값 쌍을 지정합니다. 다음 예제에서 QueryExtender 컨트롤은 LinqDataSource 컨트롤에서 반환된 데이터의 열을 검색 UnitPrice 합니다. 범위는 페이지의 TextBoxFrom 및 TextBoxTo 컨트롤에서 읽습니다.

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:RangeExpression DataField="UnitPrice" MinType="Inclusive" 
      MaxType="Inclusive"> 
    <asp:ControlParameter ControlID="TextBoxFrom" /> 
    <asp:ControlParameter ControlID="TexBoxTo" /> 
  </asp:RangeExpression> 

</asp:QueryExtender>

PropertyExpression

속성 식 옵션을 사용하면 속성 값에 대한 비교를 정의할 수 있습니다. 식이 true로 평가되면 검사 중인 데이터가 반환됩니다. 다음 예제에서 QueryExtender 컨트롤은 열의 데이터를 페이지의 CheckBoxDiscontinued 컨트롤의 값과 비교하여 데이터를 Discontinued 필터링합니다.

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
   <asp:PropertyExpression>
      <asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
   </asp:PropertyExpression>
</asp:QueryExtender>

CustomExpression

마지막으로 QueryExtender 컨트롤에 사용할 사용자 지정 식을 지정할 수 있습니다. 이 옵션을 사용하면 사용자 지정 필터 논리를 정의하는 페이지에서 함수를 호출할 수 있습니다. 다음 예제에서는 QueryExtender 컨트롤에서 사용자 지정 식을 선언적으로 지정하는 방법을 보여줍니다.

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:CustomExpression OnQuerying="FilterProducts" /> 
</asp:QueryExtender>

다음 예제에서는 QueryExtender 컨트롤에 의해 호출되는 사용자 지정 함수를 보여줍니다. 이 경우 Where 절을 포함하는 데이터베이스 쿼리를 사용하는 대신 코드는 LINQ 쿼리를 사용하여 데이터를 필터링합니다.

protected void FilterProducts(object sender, CustomExpressionEventArgs e) 
{ 
    e.Query = from p in e.Query.Cast() 
      where p.UnitPrice >= 10 
      select p; 
}

다음 예제에서는 QueryExtender 컨트롤에서 한 번에 하나의 식만 사용하는 것을 보여 줍니다. 그러나 QueryExtender 컨트롤 내에 여러 식을 포함할 수 있습니다.

Html 인코딩된 코드 식

일부 ASP.NET 사이트(특히 ASP.NET MVC)는 구문(종종 "코드 너겟"이라고 함)을 사용하여 <%= expression %> 응답에 일부 텍스트를 쓰는 데 크게 의존합니다. 코드 식을 사용하는 경우 텍스트를 HTML로 인코딩하는 것을 잊기 쉽습니다. 텍스트가 사용자 입력에서 가져온 경우 XSS(교차 사이트 스크립팅) 공격에 페이지를 열어 둘 수 있습니다.

ASP.NET 4에서는 코드 식에 대해 다음과 같은 새 구문을 소개합니다.

<%: expression %>

이 구문은 응답에 쓸 때 기본적으로 HTML 인코딩을 사용합니다. 이 새 식은 다음과 같이 효과적으로 변환됩니다.

<%= HttpUtility.HtmlEncode(expression) %>

예를 들어 <%: Request["UserInput"] %는>Request["UserInput"] 값에 대해 HTML 인코딩을 수행합니다.

이 기능의 목표는 이전 구문의 모든 인스턴스를 새 구문으로 바꿀 수 있도록 하여 사용할 모든 단계에서 결정하지 않도록 하는 것입니다. 그러나 출력되는 텍스트가 HTML이거나 이미 인코딩된 경우가 있습니다. 이 경우 이중 인코딩이 발생할 수 있습니다.

이러한 경우 ASP.NET 4는 구체적인 구현인 HtmlString과 함께 새로운 인터페이스 IHtmlString을 도입합니다. 이러한 형식의 인스턴스를 사용하면 반환 값이 HTML로 표시하기 위해 이미 제대로 인코딩(또는 검사됨)되어 있으므로 값이 HTML로 다시 인코딩되지 않아야 함을 나타낼 수 있습니다. 예를 들어 다음 항목은 HTML로 인코딩되지 않아야 합니다( 및 이 아님).

<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>

ASP.NET MVC 2 도우미 메서드는 이중 인코딩되지 않고 ASP.NET 4를 실행하는 경우에만 이 새 구문을 사용하도록 업데이트되었습니다. 이 새 구문은 ASP.NET 3.5 SP1을 사용하여 애플리케이션을 실행할 때 작동하지 않습니다.

XSS 공격으로부터 보호를 보장하지는 않습니다. 예를 들어 따옴표에 없는 특성 값을 사용하는 HTML에는 여전히 취약한 사용자 입력이 포함될 수 있습니다. ASP.NET 컨트롤 및 ASP.NET MVC 도우미의 출력에는 항상 권장되는 접근 방식인 따옴표에 특성 값이 포함됩니다.

마찬가지로 이 구문은 사용자 입력을 기반으로 JavaScript 문자열을 만들 때와 같이 JavaScript 인코딩을 수행하지 않습니다.

프로젝트 템플릿 변경 내용

이전 버전의 ASP.NET Visual Studio를 사용하여 새 웹 사이트 프로젝트 또는 웹 애플리케이션 프로젝트를 만들 때 결과 프로젝트에는 다음 그림과 같이 Default.aspx 페이지, 기본 Web.config 파일 및 App_Data 폴더만 포함됩니다.

Visual Studio 파일 메뉴의 스크린샷. 기본 파일 및 폴더를 보여 주는 새 프로젝트 예제가 강조 표시됩니다.

Visual Studio는 다음 그림과 같이 파일을 전혀 포함하지 않는 빈 웹 사이트 프로젝트 형식도 지원합니다.

Visual Studio 파일 메뉴의 스크린샷 예제 프로젝트 디렉터리에는 파일이나 폴더가 없는 것으로 표시됩니다.

그 결과 초보자에게는 프로덕션 웹 애플리케이션을 빌드하는 방법에 대한 지침이 거의 없습니다. 따라서 ASP.NET 4에는 빈 웹 애플리케이션 프로젝트용 템플릿과 웹 애플리케이션 및 웹 사이트 프로젝트에 각각 하나씩 세 개의 새 템플릿이 도입되었습니다.

빈 웹 애플리케이션 템플릿

이름에서 알 수 있듯이 빈 웹 애플리케이션 템플릿은 제거된 웹 애플리케이션 프로젝트입니다. 다음 그림과 같이 Visual Studio 새 프로젝트 대화 상자에서 이 프로젝트 템플릿을 선택합니다.

Visual Studio 새 프로젝트 대화 상자의 스크린샷. 빈 ASP.NET 웹 애플리케이션이라는 항목이 강조 표시됩니다.

(전체 크기 이미지를 보려면 클릭)

빈 ASP.NET 웹 애플리케이션을 만들 때 Visual Studio는 다음 폴더 레이아웃을 만듭니다.

Visual Studio 파일 메뉴를 보여 주는 스크린샷 웹 점 구성이라는 제목의 파일이 강조 표시됩니다.

이는 한 가지 예외를 제외하고 이전 버전의 ASP.NET 빈 웹 사이트 레이아웃과 유사합니다. Visual Studio 2010에서 빈 웹 애플리케이션 및 빈 웹 사이트 프로젝트에는 프로젝트가 대상으로 하는 프레임워크를 식별하기 위해 Visual Studio에서 사용하는 정보가 포함된 다음과 같은 최소 Web.config 파일이 포함되어 있습니다.

! <?xml version =

이 targetFramework 속성이 없으면 Visual Studio는 이전 애플리케이션을 열 때 호환성을 유지하기 위해 기본적으로 .NET Framework 2.0을 대상으로 지정합니다.

웹 애플리케이션 및 웹 사이트 프로젝트 템플릿

Visual Studio 2010과 함께 제공되는 다른 두 개의 새 프로젝트 템플릿에는 주요 변경 내용이 포함되어 있습니다. 다음 그림에서는 새 웹 애플리케이션 프로젝트를 만들 때 생성되는 프로젝트 레이아웃을 보여 있습니다. (웹 사이트 프로젝트의 레이아웃은 거의 동일합니다.)

  • 새 프로젝트로 만든 프로젝트 파일 및 폴더를 보여 주는 Visual Studio 파일 메뉴의 스크린샷

프로젝트에는 이전 버전에서 만들지 않은 여러 파일이 포함됩니다. 또한 새 웹 애플리케이션 프로젝트는 기본 멤버 자격 기능으로 구성되므로 새 애플리케이션에 대한 액세스 보안을 빠르게 시작할 수 있습니다. 이러한 포함 Web.config 으로 인해 새 프로젝트의 파일에는 멤버 자격, 역할 및 프로필을 구성하는 데 사용되는 항목이 포함됩니다. 다음 예제에서는 새 웹 애플리케이션 프로젝트에 대한 파일을 보여줍니다 Web.config . (이 경우 roleManager 는 사용하지 않도록 설정됩니다.)

웹 애플리케이션 프로젝트의 구성 파일 예제를 보여 주는 Visual Studio 편집 환경의 스크린샷

(전체 크기 이미지를 보려면 클릭)

프로젝트에는 디렉터리에 두 번째 Web.config 파일 Account 도 포함됩니다. 두 번째 구성 파일은 로그인하지 않은 사용자의 ChangePassword.aspx 페이지에 대한 액세스를 보호하는 방법을 제공합니다. 다음 예제에서는 두 번째 Web.config 파일의 내용을 보여 줍니다.

<?xml version=

새 프로젝트 템플릿에서 기본적으로 만든 페이지에도 이전 버전보다 더 많은 콘텐츠가 포함되어 있습니다. 프로젝트에는 기본 master 페이지 및 CSS 파일이 포함되어 있으며 기본 페이지(Default.aspx)는 기본적으로 master 페이지를 사용하도록 구성됩니다. 그 결과 웹 애플리케이션 또는 웹 사이트를 처음 실행할 때 기본(홈) 페이지가 이미 작동합니다. 실제로 새 MVC 애플리케이션을 시작할 때 표시되는 기본 페이지와 비슷합니다.

새 MVC 애플리케이션을 시작할 때 만든 기본 페이지의 브라우저 보기를 보여 주는 스크린샷

(전체 크기 이미지를 보려면 클릭)

이러한 프로젝트 템플릿 변경의 의도는 새 웹 애플리케이션 빌드를 시작하는 방법에 대한 지침을 제공하는 것입니다. 의미상 올바른 엄격한 XHTML 1.0 규격 태그와 CSS를 사용하여 지정된 레이아웃을 사용하면 템플릿의 페이지는 ASP.NET 4개의 웹 애플리케이션을 빌드하는 모범 사례를 나타냅니다. 기본 페이지에는 쉽게 사용자 지정할 수 있는 2열 레이아웃도 있습니다.

예를 들어 새 웹 애플리케이션의 경우 일부 색을 변경하고 내 ASP.NET 애플리케이션 로고 대신 회사 로고를 삽입하려고 합니다. 이렇게 하려면 아래에 Content 새 디렉터리를 만들어 로고 이미지를 저장합니다.

로고 파일이 포함된 images 폴더가 있는 파일 디렉터리를 보여 주는 스크린샷

페이지에 이미지를 추가하려면 다음 예제와 같이 파일을 열고 Site.Master 내 ASP.NET 애플리케이션 텍스트가 정의된 위치를 찾은 다음 src 특성이 새 로고 이미지로 설정된 이미지 요소로 바꿉 있습니다.

<div class=

(전체 크기 이미지를 보려면 클릭)

그런 다음 Site.css 파일로 이동하여 CSS 클래스 정의를 수정하여 페이지의 배경색과 헤더의 배경색을 변경할 수 있습니다.

이러한 변경의 결과는 매우 적은 노력으로 사용자 지정된 홈페이지를 표시할 수 있다는 것입니다.

사용자 지정된 홈페이지의 브라우저 보기를 보여 주는 스크린샷.

(전체 크기 이미지를 보려면 클릭)

CSS 개선 사항

ASP.NET 4의 주요 작업 영역 중 하나는 최신 HTML 표준을 준수하는 HTML을 렌더링하는 데 도움이 되는 것입니다. 여기에는 ASP.NET 웹 서버 컨트롤에서 CSS 스타일을 사용하는 방법에 대한 변경 내용이 포함됩니다.

렌더링에 대한 호환성 설정

기본적으로 웹 애플리케이션 또는 웹 사이트에서 .NET Framework 4를 대상으로 하는 경우 pages 요소의 controlRenderingCompatibilityVersion 특성은 "4.0"으로 설정됩니다. 이 요소는 컴퓨터 수준 Web.config 파일에 정의되며 기본적으로 모든 ASP.NET 4개 애플리케이션에 적용됩니다.

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5|4.0"/> 
</system.web>

controlRenderingCompatibility 값은 향후 릴리스에서 잠재적인 새 버전 정의를 허용하는 문자열입니다. 현재 릴리스에서는 이 속성에 대해 다음 값이 지원됩니다.

  • "3.5". 이 설정은 레거시 렌더링 및 태그를 나타냅니다. 컨트롤에서 렌더링된 태그는 100% 이전 버전과 호환되며 xhtmlConformance 속성의 설정이 적용됩니다.
  • "4.0". 속성에 이 설정이 있는 경우 ASP.NET 웹 서버 컨트롤은 다음을 수행합니다.
  • xhtmlConformance 속성은 항상 "Strict"로 처리됩니다. 결과적으로 컨트롤은 XHTML 1.0 Strict 태그를 렌더링합니다.
  • 입력이 아닌 컨트롤을 사용하지 않도록 설정해도 더 이상 잘못된 스타일이 렌더링되지 않습니다.
  • 이제 숨겨진 필드 주변의 div 요소가 스타일이 지정되어 사용자가 만든 CSS 규칙을 방해하지 않습니다.
  • 메뉴 컨트롤은 의미상 올바르고 접근성 지침을 준수하는 렌더링 태그를 제어합니다.
  • 유효성 검사 컨트롤은 인라인 스타일을 렌더링하지 않습니다.
  • 이전에 border="0"(ASP.NET Table 컨트롤 및 ASP.NET 이미지 컨트롤에서 파생된 컨트롤)을 렌더링한 컨트롤은 더 이상 이 특성을 렌더링하지 않습니다.

컨트롤 사용 안 림

ASP.NET 3.5 SP1 및 이전 버전에서 프레임워크는 Enabled 속성이 false로 설정된 모든 컨트롤에 대해 HTML 태그에서 disabled 특성을 렌더링합니다. 그러나 HTML 4.01 사양에 따라 입력 요소만 이 특성을 가져야 합니다.

ASP.NET 4에서는 다음 예제와 같이 controlRenderingCompatibilityVersion 속성을 "3.5"로 설정할 수 있습니다.

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5"/> 
</system.web>

다음과 같이 레이블 컨트롤에 대한 태그를 만들어 컨트롤을 사용하지 않도록 설정할 수 있습니다.

<asp:Label id="Label" runat="server" Text="Test" Enabled="false">

Label 컨트롤은 다음 HTML을 렌더링합니다.

<span id="Label1" disabled="disabled">Test</span>

ASP.NET 4에서는 controlRenderingCompatibilityVersion을 "4.0"으로 설정할 수 있습니다. 이 경우 입력 요소를 렌더링하는 컨트롤만 컨트롤의 Enabled 속성이 false로 설정된 경우 비활성화된 특성을 렌더링합니다. HTML 입력 요소를 렌더링하지 않는 컨트롤은 컨트롤에 대해 비활성화된 모양을 정의하는 데 사용할 수 있는 CSS 클래스를 참조하는 클래스 특성을 렌더링합니다. 예를 들어 이전 예제에 표시된 레이블 컨트롤은 다음 태그를 생성합니다.

<span id="Span1" class="aspnetdisabled">Test</span>

이 컨트롤에 대해 지정된 클래스의 기본값은 "aspNetDisabled"입니다. 그러나 WebControl 클래스의 static DisabledCssClass 정적 속성을 설정하여 이 기본값을 변경할 수 있습니다. 컨트롤 개발자의 경우 SupportsDisabledAttribute 속성을 사용하여 특정 컨트롤에 사용할 동작을 정의할 수도 있습니다.

숨겨진 필드 주위에 div 요소 숨기기

ASP.NET 2.0 이상 버전은 XHTML 표준을 준수하기 위해 div 요소 내에 시스템별 숨겨진 필드(예: 뷰 상태 정보를 저장하는 데 사용되는 숨겨진 요소)를 렌더링합니다. 그러나 이로 인해 CSS 규칙이 페이지의 div 요소에 영향을 줄 때 문제가 발생할 수 있습니다. 예를 들어 숨겨진 div 요소 주위의 페이지에 1픽셀 선이 나타날 수 있습니다. ASP.NET 4에서 ASP.NET 생성된 숨겨진 필드를 묶는 div 요소는 다음 예제와 같이 CSS 클래스 참조를 추가합니다.

<div class="aspNetHidden">...</div>

그런 다음, 다음 예제와 같이 ASP.NET 생성된 숨겨진 요소에만 적용되는 CSS 클래스를 정의할 수 있습니다.

<style type="text/css"> 
  DIV# aspNetHidden {border:0;} 

</style>

템플릿 컨트롤에 대한 외부 테이블 렌더링

기본적으로 템플릿을 지원하는 다음 ASP.NET 웹 서버 컨트롤은 인라인 스타일을 적용하는 데 사용되는 외부 테이블에 자동으로 래핑됩니다.

  • Formview
  • 로그인
  • PasswordRecovery
  • ChangePassword
  • 마법사
  • CreateUserWizard

외부 테이블을 태그에서 제거할 수 있는 RenderOuterTable 이라는 새 속성이 이러한 컨트롤에 추가되었습니다. 예를 들어 FormView 컨트롤의 다음 예제를 살펴보겠습니다.

<asp:FormView ID="FormView1" runat="server"> 
  <ItemTemplate> 
      Content 
  </ItemTemplate> 

</asp:FormView>

이 태그는 HTML 테이블을 포함하는 다음 출력을 페이지에 렌더링합니다.

<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;"> 
  <tr> 
    <td colspan="2"> 
      Content 
    </td> 
  </tr> 

</table>

테이블이 렌더링되지 않도록 하려면 다음 예제와 같이 FormView 컨트롤의 RenderOuterTable 속성을 설정할 수 있습니다.

<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">

이전 예제에서는 테이블, tr 및 td 요소 없이 다음 출력을 렌더링합니다.

콘텐츠

이 향상된 기능을 사용하면 컨트롤에서 예기치 않은 태그를 렌더링하지 않으므로 컨트롤의 콘텐츠 스타일을 CSS로 더 쉽게 지정할 수 있습니다.

참고

참고 이 변경은 Visual Studio 2010 디자이너에서 자동 서식 함수에 대한 지원을 사용하지 않도록 설정합니다. 자동 서식 옵션에서 생성된 스타일 특성을 호스트할 수 있는 테이블 요소가 더 이상 없기 때문입니다.

ListView 컨트롤 개선 사항

ListView 컨트롤은 ASP.NET 4에서 더 쉽게 사용할 수 있습니다. 이전 버전의 컨트롤에서는 알려진 ID가 있는 서버 컨트롤이 포함된 레이아웃 템플릿을 지정해야 했습니다. 다음 태그는 ASP.NET 3.5에서 ListView 컨트롤을 사용하는 방법에 대한 일반적인 예제를 보여 줍니다.

<asp:ListView ID="ListView1" runat="server"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder> 
  </LayoutTemplate> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 
</asp:ListView>

ASP.NET 4에서는 ListView 컨트롤에 레이아웃 템플릿이 필요하지 않습니다. 이전 예제에 표시된 태그를 다음 태그로 바꿀 수 있습니다.

<asp:ListView ID="ListView1" runat="server"> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 

</asp:ListView>

CheckBoxList 및 RadioButtonList 컨트롤 향상

ASP.NET 3.5에서는 다음 두 설정을 사용하여 CheckBoxList 및 RadioButtonList 에 대한 레이아웃을 지정할 수 있습니다.

  • 흐름. 컨트롤은 콘텐츠를 포함하도록 범위 요소를 렌더링합니다.
  • 테이블. 컨트롤은 해당 콘텐츠를 포함하도록 테이블 요소를 렌더링합니다.

다음 예제에서는 이러한 각 컨트롤에 대한 태그를 보여 줍니다.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow"> 
  <asp:ListItem Text="CheckBoxList" Value="cbl" /> 
</asp:CheckBoxList> 

<asp:RadioButtonList runat="server" RepeatLayout="Table"> 
  <asp:ListItem Text="RadioButtonList" Value="rbl" /> 
</asp:RadioButtonList>

기본적으로 컨트롤은 다음과 유사한 HTML을 렌더링합니다.

<span id="Span2"><input id="CheckBoxList1_0" type="checkbox" 
    name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span> 
    
<table id="RadioButtonList1" border="0"> 
  <tr> 
    <td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td> 
  </tr> 

</table>

이러한 컨트롤에는 의미상 올바른 HTML을 렌더링하려면 항목 목록이 포함되어 있으므로 HTML 목록(li) 요소를 사용하여 콘텐츠를 렌더링해야 합니다. 이렇게 하면 보조 기술을 사용하여 웹 페이지를 더 쉽게 읽을 수 있으며 CSS를 사용하여 컨트롤의 스타일을 더 쉽게 지정할 수 있습니다.

ASP.NET 4에서 CheckBoxList 및 RadioButtonList 컨트롤은 RepeatLayout 속성에 대해 다음과 같은 새 값을 지원합니다.

  • OrderedList – 콘텐츠는 ol 요소 내에서 li 요소로 렌더링됩니다.
  • UnorderedList – 콘텐츠는 ul 요소 내에서 li 요소로 렌더링됩니다.

다음 예제에서는 이러한 새 값을 사용하는 방법을 보여줍니다.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" 
      RepeatLayout="OrderedList">
  <asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>

<asp:RadioButtonList ID="RadioButtonList1" runat="server"  
      RepeatLayout="UnorderedList">
  <asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>

이전 태그는 다음 HTML을 생성합니다.

<ol id="CheckBoxList1">

  <li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
    
<ul id="RadioButtonList1">
  <li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>

</ul>

참고

참고 RepeatLayout 을 OrderedList 또는 UnorderedList로 설정하면 RepeatDirection 속성을 더 이상 사용할 수 없으며 속성이 태그 또는 코드 내에서 설정된 경우 런타임에 예외가 throw됩니다. 이러한 컨트롤의 시각적 레이아웃이 CSS를 사용하여 정의되므로 속성에는 값이 없습니다.

ASP.NET 전에 메뉴 컨트롤은 일련의 HTML 테이블을 렌더링했습니다. 이로 인해 인라인 속성을 설정하는 것 외에 CSS 스타일을 적용하기가 더 어려워졌으며 접근성 표준을 준수하지도 않았습니다.

ASP.NET 4에서 컨트롤은 이제 순서가 지정되지 않은 목록 및 목록 요소로 구성된 의미 체계 태그를 사용하여 HTML을 렌더링합니다. 다음 예제에서는 메뉴 컨트롤에 대한 ASP.NET 페이지의 태그를 보여 줍니다.

<asp:Menu ID="Menu1" runat="server"> 
  <Items> <asp:MenuItem Text="Home" Value="Home" /> 
    <asp:MenuItem Text="About" Value="About" /> 
  </Items> 

</asp:Menu>

페이지가 렌더링될 때 컨트롤은 다음 HTML을 생성합니다(명확성 을 위해 onclick 코드가 생략됨).

<div id="Menu1"> 
  <ul> 
    <li><a href="#" onclick="...">Home</a></li> 
    <li><a href="#" onclick="...">About</a></li> 
  </ul> 

</div> 
<script type="text/javascript"> 
  new Sys.WebForms.Menu('Menu1'); 
</script>

렌더링 개선 사항 외에도 포커스 관리를 사용하여 메뉴의 키보드 탐색이 개선되었습니다. 메뉴 컨트롤이 포커스를 받으면 화살표 키를 사용하여 요소를 탐색할 수 있습니다. 메뉴 컨트롤은 이제 접근성 향상을 위해 ARIA(액세스 가능한 풍부한 인터넷 애플리케이션) 역할 및 특성 follo날개로 연결합니다.

메뉴 컨트롤의 스타일은 렌더링된 HTML 요소와 일치하지 않고 페이지 맨 위에 있는 스타일 블록으로 렌더링됩니다. 컨트롤의 스타일을 완전히 제어하려면 새 IncludeStyleBlock 속성을 false로 설정할 수 있습니다. 이 경우 스타일 블록이 내보내지지 않습니다. 이 속성을 사용하는 한 가지 방법은 Visual Studio 디자이너에서 자동 서식 기능을 사용하여 메뉴의 모양을 설정하는 것입니다. 그런 다음 페이지를 실행하고 페이지 원본을 연 다음 렌더링된 스타일 블록을 외부 CSS 파일에 복사할 수 있습니다. Visual Studio에서 스타일을 실행 취소하고 IncludeStyleBlock 을 false로 설정합니다. 그 결과 외부 스타일시트에서 스타일을 사용하여 메뉴 모양이 정의됩니다.

마법사 및 CreateUserWizard 컨트롤

ASP.NET 마법사 및 CreateUserWizard 컨트롤은 렌더링하는 HTML을 정의할 수 있는 템플릿을 지원합니다. (CreateUserWizard는마법사에서 파생됩니다.) 다음 예제에서는 완전히 템플릿이 있는 CreateUserWizard 컨트롤에 대한 태그를 보여 줍니다.

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0"> 
  <HeaderTemplate> 
  </HeaderTemplate>
 
  <SideBarTemplate> 
  </SideBarTemplate>
 
  <StepNavigationTemplate> 
  </StepNavigationTemplate> 

  <StartNavigationTemplate> 
  </StartNavigationTemplate> 

  <FinishNavigationTemplate> 
  </FinishNavigationTemplate> 

  <WizardSteps> 
    <asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate>

      <CustomNavigationTemplate> 
      </CustomNavigationTemplate>

    </asp:CreateUserWizardStep>
 
    <asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CompleteWizardStep> 

  </WizardSteps> 

</asp:CreateUserWizard>

컨트롤은 다음과 유사한 HTML을 렌더링합니다.

<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;"> 
  <tr> 
    <td>Header</td> 
  </tr> 
  <tr style="height:100%;"> 
    <td> 
      <table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;"> 
        <tr> 
          <td style="height:100%;width:100%;"></td> 
        </tr> 
      </table> 
    </td> 
  </tr> 
  <tr> 
    <td align="right"></td> 
  </tr> 

</table>

ASP.NET 3.5 SP1에서는 템플릿 내용을 변경할 수 있지만 마법사 컨트롤의 출력을 제한적으로 제어할 수 있습니다. ASP.NET 4에서는 LayoutTemplate 템플릿을 만들고 예약된 이름을 사용하여 PlaceHolder 컨트롤을 삽입하여 마법사 컨트롤 을 렌더링하는 방법을 지정할 수 있습니다. 다음 예제에서는 이러한 방법을 보여줍니다.

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="headerPlaceholder" runat="server" /> 
    <asp:PlaceHolder ID="sideBarPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="wizardStepPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="navigationPlaceholder" runat="server" /> 
  </LayoutTemplate> 
  <HeaderTemplate> 
    Header 
  </HeaderTemplate> 
  <WizardSteps> 
    <asp:CreateUserWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
    <asp:CompleteWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
  </WizardSteps> 

</asp:CreateUserWizard>

이 예제에는 LayoutTemplate 요소에 다음과 같은 명명된 자리 표시자가 포함되어 있습니다.

  • headerPlaceholder – 런타임에 HeaderTemplate 요소의 내용으로 바뀝니다.
  • sideBarPlaceholder – 런타임에 SideBarTemplate 요소의 내용으로 바뀝니다.
  • wizardStepPlaceHolder – 런타임에 WizardStepTemplate 요소의 내용으로 바뀝니다.
  • navigationPlaceholder – 런타임에 정의한 탐색 템플릿으로 바뀝니다.

자리 표시자를 사용하는 예제의 태그는 템플릿에 실제로 정의된 콘텐츠 없이 다음 HTML을 렌더링합니다.

<span>
</span>

이제 사용자 정의가 아닌 유일한 HTML은 span 요소입니다. (향후 릴리스에서는 span 요소도 렌더링되지 않을 것으로 예상합니다.) 이제 마법사 컨트롤에서 생성되는 거의 모든 콘텐츠를 완전히 제어할 수 있습니다.

ASP.NET MVC

ASP.NET MVC는 2009년 3월에 3.5 SP1을 ASP.NET 추가 기능 프레임워크로 도입되었습니다. Visual Studio 2010에는 새로운 기능과 기능이 포함된 ASP.NET MVC 2가 포함되어 있습니다.

영역 지원

영역을 사용하면 컨트롤러와 뷰를 다른 섹션과 상대적으로 격리된 대규모 애플리케이션의 섹션으로 그룹화할 수 있습니다. 각 영역은 기본 애플리케이션에서 참조할 수 있는 별도의 ASP.NET MVC 프로젝트로 구현할 수 있습니다. 이렇게 하면 대규모 애플리케이션을 빌드할 때 복잡성을 관리하고 여러 팀이 단일 애플리케이션에서 더 쉽게 함께 작업할 수 있습니다.

Data-Annotation 특성 유효성 검사 지원

DataAnnotations 특성을 사용하면 메타데이터 특성을 사용하여 유효성 검사 논리를 모델에 연결할 수 있습니다. DataAnnotations 특성은 ASP.NET 3.5 SP1의 ASP.NET 동적 데이터에 도입되었습니다. 이러한 특성은 기본 모델 바인더에 통합되었으며 사용자 입력의 유효성을 검사하는 메타데이터 기반 수단을 제공합니다.

템플릿 도우미

템플릿 도우미를 사용하면 템플릿 편집 및 표시를 데이터 형식과 자동으로 연결할 수 있습니다. 예를 들어 템플릿 도우미를 사용하여 Date-picker UI 요소가 System.DateTime 값에 대해 자동으로 렌더링되도록 지정할 수 있습니다. 이는 ASP.NET 동적 데이터의 필드 템플릿과 비슷합니다.

Html.EditorFor 및 Html.DisplayFor 도우미 메서드는 여러 속성이 있는 복잡한 개체뿐만 아니라 표준 데이터 형식 렌더링을 기본적으로 지원합니다. 또한 DisplayName 및 ScaffoldColumn 과 같은 데이터 주석 특성을 ViewModel 개체에 적용하여 렌더링을 사용자 지정합니다.

UI 도우미의 출력을 더욱 사용자 지정하고 생성되는 항목을 완전히 제어하려는 경우가 많습니다. Html.EditorFor 및 Html.DisplayFor 도우미 메서드는 렌더링된 출력을 재정의하고 제어할 수 있는 외부 템플릿을 정의할 수 있는 템플릿 메커니즘을 사용하여 이를 지원합니다. 템플릿은 클래스에 대해 개별적으로 렌더링할 수 있습니다.

Dynamic Data

Dynamic Data는 2008년 중반에 .NET Framework 3.5 SP1 릴리스에 도입되었습니다. 이 기능은 다음을 포함하여 데이터 기반 애플리케이션을 만들기 위한 많은 향상된 기능을 제공합니다.

  • 데이터 기반 웹 사이트를 신속하게 빌드하기 위한 RAD 환경입니다.
  • 데이터 모델에 정의된 제약 조건을 기반으로 하는 자동 유효성 검사입니다.
  • Dynamic Data 프로젝트의 일부인 필드 템플릿을 사용하여 GridView 및 DetailsView 컨트롤의 필드에 대해 생성된 태그를 쉽게 변경할 수 있습니다.

참고

참고 자세한 내용은 MSDN 라이브러리의 동적 데이터 설명서를 참조하세요.

ASP.NET 4의 경우 동적 데이터가 향상되어 개발자가 데이터 기반 웹 사이트를 빠르게 빌드할 수 있는 더 많은 권한을 부여할 수 있습니다.

기존 프로젝트에 동적 데이터 사용

.NET Framework 3.5 SP1에 제공된 동적 데이터 기능은 다음과 같은 새로운 기능을 제공합니다.

  • 필드 템플릿 – 데이터 바인딩된 컨트롤에 대한 데이터 형식 기반 템플릿을 제공합니다. 필드 템플릿은 각 필드에 템플릿 필드를 사용하는 것보다 데이터 컨트롤의 모양을 사용자 지정하는 더 간단한 방법을 제공합니다.
  • 유효성 검사 – 동적 데이터를 사용하면 데이터 클래스의 특성을 사용하여 필수 필드, 범위 검사, 형식 검사, 정규식을 사용한 패턴 일치 및 사용자 지정 유효성 검사와 같은 일반적인 시나리오에 대한 유효성 검사를 지정할 수 있습니다. 유효성 검사는 데이터 컨트롤에 의해 적용됩니다.

그러나 이러한 기능에는 다음과 같은 요구 사항이 있습니다.

  • 데이터 액세스 계층은 Entity Framework 또는 LINQ to SQL 기반으로 해야 했습니다.
  • 이러한 기능에 지원되는 유일한 데이터 원본 컨트롤은 EntityDataSource 또는 LinqDataSource 컨트롤이었습니다.
  • 기능을 지원하는 데 필요한 모든 파일을 갖기 위해서는 동적 데이터 또는 동적 데이터 엔터티 템플릿을 사용하여 만든 웹 프로젝트가 필요했습니다.

ASP.NET 4에서 동적 데이터 지원의 주요 목표는 모든 ASP.NET 애플리케이션에 대해 Dynamic Data의 새로운 기능을 사용하도록 설정하는 것입니다. 다음 예제에서는 기존 페이지에서 동적 데이터 기능을 활용할 수 있는 컨트롤에 대한 태그를 보여 줍니다.

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True" 
    DataKeyNames="ProductID" DataSourceID="LinqDataSource1"> 
</asp:GridView> 
<asp:LinqDataSource ID="LinqDataSource1" runat="server" 
    ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True" 
    EnableUpdate="True" TableName="Products"> 

</asp:LinqDataSource>

이러한 컨트롤에 대해 동적 데이터 지원을 사용하도록 설정하려면 페이지의 코드에서 다음 코드를 추가해야 합니다.

GridView1.EnableDynamicData(typeof(Product));

GridView 컨트롤이 편집 모드에 있는 경우 동적 데이터는 입력한 데이터가 적절한 형식인지 자동으로 유효성을 검사합니다. 그렇지 않으면 오류 메시지가 표시됩니다.

이 기능은 삽입 모드의 기본값을 지정할 수 있는 것과 같은 다른 이점도 제공합니다. 동적 데이터가 없으면 필드에 대한 기본값을 구현하려면 이벤트에 연결하고 컨트롤( FindControl 사용)을 찾아 해당 값을 설정해야 합니다. ASP.NET 4에서 EnableDynamicData 호출은 다음 예제와 같이 개체의 모든 필드에 대한 기본값을 전달할 수 있는 두 번째 매개 변수를 지원합니다.

DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });

선언적 DynamicDataManager 컨트롤 구문

DynamicDataManager 컨트롤이 향상되어 코드가 아닌 ASP.NET 대부분의 컨트롤과 마찬가지로 선언적으로 구성할 수 있습니다. DynamicDataManager 컨트롤에 대한 태그는 다음 예제와 같습니다.

<asp:DynamicDataManager ID="DynamicDataManager1" runat="server" 
    AutoLoadForeignKeys="true"> 
  <DataControls> 
    <asp:DataControlReference ControlID="GridView1" /> 
  </DataControls> 

</asp:DynamicDataManager> 
<asp:GridView id="GridView1" runat="server" 
</asp:GridView>

이 태그를 사용하면 DynamicDataManager 컨트롤의 DataControls 섹션에서 참조되는 GridView1 컨트롤에 대한 동적 데이터 동작을 사용할 수 있습니다.

엔터티 템플릿

엔터티 템플릿은 사용자 지정 페이지를 만들 필요 없이 데이터 레이아웃을 사용자 지정하는 새로운 방법을 제공합니다. 페이지 템플릿은 이전 버전의 동적 데이터에서 페이지 템플릿에 사용된 DetailsView 컨트롤 대신 FormView 컨트롤과 DynamicEntity 컨트롤을 사용하여 엔터티 템플릿을 렌더링합니다. 이렇게 하면 동적 데이터에서 렌더링되는 태그를 더 많이 제어할 수 있습니다.

다음 목록에서는 엔터티 템플릿을 포함하는 새 프로젝트 디렉터리 레이아웃을 보여 줍니다.

\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx

디렉터리에는 EntityTemplate 데이터 모델 개체를 표시하는 방법에 대한 템플릿이 포함되어 있습니다. 기본적으로 개체는 템플릿을 사용하여 Default.ascx 렌더링됩니다. 이 템플릿은 ASP.NET 3.5 SP1에서 동적 데이터에서 사용하는 DetailsView 컨트롤에서 만든 태그와 같은 태그를 제공합니다. 다음 예제에서는 컨트롤에 대한 태그를 보여 줍니다 Default.ascx .

<asp:EntityTemplate runat="server" ID="TemplateContainer1"> 
  <ItemTemplate> 
    <tr 
      <td> 
        <asp:Label ID="Label1" runat="server" OnInit="Label_Init" /> 
      </td> 
      <td> 
        <asp:DynamicControl runat="server" OnInit="DynamicControl_Init" /> 
      </td> 
    </tr> 
  </ItemTemplate> 

</asp:EntityTemplate>

기본 템플릿을 편집하여 전체 사이트의 모양과 느낌을 변경할 수 있습니다. 표시, 편집 및 삽입 작업에 대 한 템플릿이 있습니다. 데이터 개체의 이름에 따라 새 템플릿을 추가하여 한 가지 유형의 개체만의 모양과 느낌을 변경할 수 있습니다. 예를 들어 다음 템플릿을 추가할 수 있습니다.

\DynamicData\EntityTemplates\Products.aspx

템플릿에는 다음 태그가 포함될 수 있습니다.

<tr> 
  <td>Name</td> 
  <td><asp:DynamicControl runat="server" DataField="ProductName" /></td> 
  <td>Category</td> 
  <td><asp:DynamicControl runat="server" DataField="Category" /></td> 

</tr>

새 엔터티 템플릿은 새 DynamicEntity 컨트롤을 사용하여 페이지에 표시됩니다. 런타임에 이 컨트롤은 엔터티 템플릿의 내용으로 바뀝니다. 다음 태그는 엔터티 템플릿을 사용하는 페이지 템플릿의 Detail.aspxFormView 컨트롤을 보여 줍니다. 태그에서 DynamicEntity 요소를 확인합니다.

<asp:FormView runat="server" ID="FormView1" 
    DataSourceID="DetailsDataSource" 
    OnItemDeleted="FormView1_ItemDeleted"> 
  <ItemTemplate> 
    <table class="DDDetailsTable" cellpadding="6"> 
      <asp:DynamicEntity runat="server" /> 
      <tr class="td"> 
        <td colspan="2"> 
          <asp:DynamicHyperLink ID="EditHyperLink" runat="server" 
              Action="Edit" Text="Edit" /> 
          <asp:LinkButton ID="DeleteLinkButton" runat="server" 
              CommandName="Delete" 
              CausesValidation="false" 
              OnClientClick='return confirm("Are you sure you want to delete this item?");' 
              Text="Delete" /> 
        </td> 
      </tr> 
    </table> 
  </ItemTemplate> 

</asp:FormView>

URL 및 Email 주소에 대한 새 필드 템플릿

ASP.NET 4에는 및 의 두 가지 새로운 기본 제공 필드 템플릿이 EmailAddress.ascxUrl.ascx도입되었습니다. 이러한 템플릿은 DataType 특성이 있는 EmailAddress 또는 Url로 표시된 필드에 사용됩니다. EmailAddress 개체의 경우 필드는 mailto: 프로토콜을 사용하여 만든 하이퍼링크로 표시됩니다. 사용자가 링크를 클릭하면 사용자의 이메일 클라이언트가 열리고 기본 메시지가 만들어집니다. URL로 형식화된 개체는 일반 하이퍼링크로 표시됩니다.

다음 예제에서는 필드를 표시하는 방법을 보여줍니다.

[DataType(DataType.EmailAddress)] 
public object HomeEmail { get; set; } 

[DataType(DataType.Url)] 
public object Website { get; set; }

동적 데이터는 .NET Framework 3.5 SP1에 추가된 새 라우팅 기능을 사용하여 최종 사용자가 웹 사이트에 액세스할 때 표시되는 URL을 제어합니다. 새 DynamicHyperLink 컨트롤을 사용하면 동적 데이터 사이트의 페이지에 대한 링크를 쉽게 빌드할 수 있습니다. 다음 예제에서는 DynamicHyperLink 컨트롤을 사용하는 방법을 보여줍니다.

<asp:DynamicHyperLink ID="ListHyperLink" runat="server" 
    Action="List" TableName="Products"> 
    Show all products 
</asp:DynamicHyperLink>

이 태그는 파일에 정의된 Global.asax 경로를 기반으로 테이블의 Products 목록 페이지를 가리키는 링크를 만듭니다. 컨트롤은 동적 데이터 페이지의 기반이 되는 기본 테이블 이름을 자동으로 사용합니다.

데이터 모델의 상속 지원

Entity Framework와 LINQ to SQL 모두 데이터 모델에서 상속을 지원합니다. 이 예제는 테이블이 있는 데이터베이스일 InsurancePolicy 수 있습니다. 필드가 같고 HousePolicy 테이블이 포함된 CarPolicy 다음, 더 많은 필드를 InsurancePolicy 추가할 수도 있습니다. 동적 데이터는 데이터 모델의 상속된 개체를 이해하고 상속된 테이블에 대한 스캐폴딩을 지원하도록 수정되었습니다.

다 대 다 관계 지원(Entity Framework만 해당)

Entity Framework는 엔터 티 개체의 컬렉션으로 관계를 노출하여 구현되는 테이블 간의 다대다 관계를 다양하게 지원합니다. ManyToMany_Edit.ascx 다 대 다 관계에 관련된 데이터를 표시하고 편집할 수 있도록 새 ManyToMany.ascx 및 필드 템플릿이 추가되었습니다.

표시 및 지원 열거형을 제어하는 새 특성

DisplayAttribute가 추가되어 필드가 표시되는 방식을 추가로 제어할 수 있습니다. 이전 버전의 Dynamic Data의 DisplayName 특성을 사용하면 필드의 캡션 사용되는 이름을 변경할 수 있습니다. 새 DisplayAttribute 클래스를 사용하면 필드가 표시되는 순서 및 필드를 필터로 사용할지 여부와 같이 필드를 표시하기 위한 더 많은 옵션을 지정할 수 있습니다. 또한 특성은 GridView 컨트롤의 레이블에 사용되는 이름, DetailsView 컨트롤에 사용되는 이름, 필드의 도움말 텍스트 및 필드에 사용되는 워터마크(필드가 텍스트 입력을 허용하는 경우)를 독립적으로 제어합니다.

열거형에 필드를 매핑할 수 있도록 EnumDataTypeAttribute 클래스가 추가되었습니다. 필드에 이 특성을 적용할 때 열거형 형식을 지정합니다. 동적 데이터는 새 Enumeration.ascx 필드 템플릿을 사용하여 열거형 값을 표시하고 편집하기 위한 UI를 만듭니다. 템플릿은 데이터베이스의 값을 열거형의 이름에 매핑합니다.

필터에 대한 향상된 지원

부울 열 및 외래 키 열에 대한 기본 제공 필터와 함께 제공되는 동적 데이터 1.0. 필터를 사용하면 필터가 표시되는지 또는 어떤 순서로 표시되었는지 지정할 수 없습니다. 새 DisplayAttribute 특성은 열이 필터로 표시되는지 여부와 열이 표시되는 순서를 제어할 수 있도록 하여 이러한 문제를 모두 해결합니다.

Web Forms 새로운 기능을 사용하도록 필터링 지원이 다시 _QueryExtender 작성되었습니다. 이렇게 하면 필터를 사용할 데이터 소스 제어에 대한 지식 없이 필터를 만들 수 있습니다. 이러한 확장과 함께 필터도 템플릿 컨트롤로 전환되어 새 필터를 추가할 수 있습니다. 마지막으로 앞에서 언급한 DisplayAttribute 클래스를 사용하면 UIHint 에서 열에 대한 기본 필드 템플릿을 재정의할 수 있는 것과 동일한 방식으로 기본 필터를 재정의할 수 있습니다.

Visual Studio 2010 웹 개발 개선 사항

Visual Studio 2010의 웹 개발은 CSS 호환성을 높이고 HTML 및 ASP.NET 태그 코드 조각과 새로운 동적 IntelliSense JavaScript를 통한 생산성 향상을 위해 향상되었습니다.

향상된 CSS 호환성

Visual Studio 2010의 Visual Web Developer 디자이너가 CSS 2.1 표준 준수를 개선하기 위해 업데이트되었습니다. 디자이너는 HTML 원본의 무결성을 더 잘 유지하며 이전 버전의 Visual Studio보다 더 강력합니다. 내부적으로 렌더링, 레이아웃 및 서비스 기능의 향후 향상을 가능하게 하는 아키텍처 개선 사항도 적용되었습니다.

HTML 및 JavaScript 코드 조각

HTML 편집기에서 IntelliSense는 태그 이름을 자동으로 완성합니다. IntelliSense 코드 조각 기능은 전체 태그 등을 자동으로 완성합니다. Visual Studio 2010에서는 이전 버전의 Visual Studio에서 지원되었던 C# 및 Visual Basic과 함께 JavaScript에 대해 IntelliSense 코드 조각이 지원됩니다.

Visual Studio 2010에는 필수 특성(예: runat="server") 및 태그와 관련된 일반적인 특성(예: ID, DataSourceID, ControlToValidate 및 Text)을 포함하여 일반적인 ASP.NET 및 HTML 태그를 자동으로 완료하는 데 도움이 되는 200개가 넘는 코드 조각이 포함되어 있습니다.

추가 코드 조각을 다운로드하거나 사용자 또는 팀이 일반적인 작업에 사용하는 태그 블록을 캡슐화하는 고유한 코드 조각을 작성할 수 있습니다.

JavaScript IntelliSense 향상된 기능

Visual 2010에서는 JavaScript IntelliSense가 더욱 풍부한 편집 환경을 제공하도록 다시 디자인되었습니다. IntelliSense는 이제 registerNamespace 와 같은 메서드 및 다른 JavaScript 프레임워크에서 사용하는 유사한 기술로 동적으로 생성된 개체를 인식합니다. 스크립트의 큰 라이브러리를 분석하고 처리 지연이 거의 또는 전혀 없는 IntelliSense를 표시하도록 성능이 향상되었습니다. 거의 모든 타사 라이브러리를 지원하고 다양한 코딩 스타일을 지원하기 위해 호환성이 크게 향상되었습니다. 이제 입력할 때 설명서 주석이 구문 분석되고 IntelliSense에서 즉시 활용됩니다.

Visual Studio 2010을 사용하여 웹 애플리케이션 배포

ASP.NET 개발자는 웹 애플리케이션을 배포할 때 다음과 같은 문제가 발생하는 경우가 많습니다.

  • 공유 호스팅 사이트에 배포하려면 속도가 느릴 수 있는 FTP와 같은 기술이 필요합니다. 또한 데이터베이스를 구성하기 위해 SQL 스크립트 실행과 같은 작업을 수동으로 수행해야 하며 가상 디렉터리 폴더를 애플리케이션으로 구성하는 것과 같은 IIS 설정을 변경해야 합니다.
  • 엔터프라이즈 환경에서는 웹 애플리케이션 파일을 배포하는 것 외에도 관리자는 ASP.NET 구성 파일 및 IIS 설정을 자주 수정해야 합니다. 데이터베이스 관리자는 애플리케이션 데이터베이스를 실행하려면 일련의 SQL 스크립트를 실행해야 합니다. 이러한 설치는 노동 집약적이고 완료하는 데 몇 시간이 걸리며 신중하게 문서화되어야 합니다.

Visual Studio 2010에는 이러한 문제를 해결하고 웹 애플리케이션을 원활하게 배포할 수 있는 기술이 포함되어 있습니다. 이러한 기술 중 하나는 IIS 웹 배포 도구(MsDeploy.exe)입니다.

Visual Studio 2010의 웹 배포 기능에는 다음과 같은 주요 영역이 포함됩니다.

  • 웹 패키징
  • Web.config 변환
  • 데이터베이스 배포
  • 웹 애플리케이션에 대한 원클릭 게시

다음 섹션에서는 이러한 기능에 대한 세부 정보를 제공합니다.

웹 패키징

Visual Studio 2010은 MSDeploy 도구를 사용하여 웹 패키지라고 하는 애플리케이션에 대한 압축된(.zip) 파일을 만듭니다. 패키지 파일에는 애플리케이션에 대한 메타데이터와 다음 콘텐츠가 포함되어 있습니다.

  • IIS 설정- 애플리케이션 풀 설정, 오류 페이지 설정 등이 포함됩니다.
  • 웹 페이지, 사용자 컨트롤, 정적 콘텐츠(이미지 및 HTML 파일) 등을 포함하는 실제 웹 콘텐츠입니다.
  • 데이터베이스 스키마 및 데이터를 SQL Server.
  • 보안 인증서, GAC에 설치할 구성 요소, 레지스트리 설정 등

웹 패키지를 모든 서버에 복사한 다음 IIS 관리자를 사용하여 수동으로 설치할 수 있습니다. 또는 자동화된 배포의 경우 명령줄 명령을 사용하거나 배포 API를 사용하여 패키지를 설치할 수 있습니다.

Visual Studio 2010은 기본 제공 MSBuild 작업 및 웹 패키지를 만드는 대상을 제공합니다. 자세한 내용은 MSDN 웹 사이트의 ASP.NET 웹 애플리케이션 프로젝트 배포 개요 및 Vishal Joshi의 블로그에서 웹 패키지를 만들어야 하는 10+ 20가지 이유를 참조하세요.

Web.config 변환

웹 애플리케이션 배포의 경우 Visual Studio 2010에는 개발 설정에서 프로덕션 설정으로 파일을 변환할 수 있는 기능인 XDT(XML 문서 변환Web.config)가 도입되었습니다. 변환 설정은 , web.release.config등이라는 web.debug.config변환 파일에 지정됩니다. (이러한 파일의 이름은 MSBuild 구성과 일치합니다.) 변환 파일에는 배포된 파일에 대해 수행해야 하는 변경 내용만 포함됩니다 Web.config . 간단한 구문을 사용하여 변경 내용을 지정합니다.

다음 예제에서는 릴리스 구성의 배포를 web.release.config 위해 생성될 수 있는 파일의 일부를 보여줍니다. 예제의 Replace 키워드(keyword) 배포 중에 파일의 connectionString 노드가 예제에 Web.config 나열된 값으로 대체되도록 지정합니다.

<connectionStrings xdt:Transform="Replace"> 
  <add name="BlogDB" connectionString="connection string detail]" /> 

</connectionStrings>

자세한 내용은 MSDN 웹 사이트의 웹 애플리케이션 프로젝트 배포에 대한Web.config 변환 구문 및웹 배포: Vishal Joshi의 블로그에서 Web.Config 변환을 참조하세요.

데이터베이스 배포

Visual Studio 2010 배포 패키지에는 SQL Server 데이터베이스에 대한 종속성이 포함될 수 있습니다. 패키지 정의의 일부로 원본 데이터베이스에 대한 연결 문자열 제공합니다. 웹 패키지를 만들 때 Visual Studio 2010은 데이터베이스 스키마 및 선택적으로 데이터에 대한 SQL 스크립트를 만든 다음 패키지에 추가합니다. 사용자 지정 SQL 스크립트를 제공하고 서버에서 실행할 시퀀스를 지정할 수도 있습니다. 배포 시 대상 서버에 적합한 연결 문자열 제공합니다. 그런 다음, 배포 프로세스는 이 연결 문자열 사용하여 데이터베이스 스키마를 만들고 데이터를 추가하는 스크립트를 실행합니다.

또한 원클릭 게시를 사용하여 애플리케이션이 원격 공유 호스팅 사이트에 게시될 때 데이터베이스를 직접 게시하도록 배포를 구성할 수 있습니다. 자세한 내용은 방법: MSDN 웹 사이트에서 웹 애플리케이션 프로젝트를 사용하여 데이터베이스 배포 및 Vishal Joshi의 블로그에서 VS 2010을 사용한 데이터베이스 배포 를 참조하세요.

One-Click 웹 애플리케이션용 게시

Visual Studio 2010을 사용하면 IIS 원격 관리 서비스를 사용하여 웹 애플리케이션을 원격 서버에 게시할 수도 있습니다. 호스팅 계정 또는 테스트 서버 또는 스테이징 서버에 대한 게시 프로필을 만들 수 있습니다. 각 프로필은 적절한 자격 증명을 안전하게 저장할 수 있습니다. 그런 다음 웹 원클릭 게시 도구 모음을 사용하여 한 번의 클릭으로 대상 서버에 배포할 수 있습니다. Visual Studio 2010에서는 MSBuild 명령줄을 사용하여 게시할 수도 있습니다. 이렇게 하면 연속 통합 모델에 게시를 포함하도록 팀 빌드 환경을 구성할 수 있습니다.

자세한 내용은 방법: MSDN 웹 사이트에 One-Click 게시 및 웹 배포를 사용하여 웹 애플리케이션 프로젝트 배포 및 Vishal Joshi의 블로그에서 VS 2010을 사용하여 웹 1 클릭 게시를 참조 하세요. Visual Studio 2010에서 웹 애플리케이션 배포에 대한 비디오 프레젠테이션을 보려면 Vishal Joshi의 블로그에서 VS 2010 for Web Developer Previews 를 참조하세요.

리소스

다음 웹 사이트는 ASP.NET 4 및 Visual Studio 2010에 대한 추가 정보를 제공합니다.

고지 사항

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

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

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

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

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

달리 명시되지 않는 한, 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 이벤트는 가상이며 실제 회사, organization, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연관이 없거나 유추되어야 합니다.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft 및 Windows는 미국 및/또는 기타 국가에서 Microsoft Corporation의 상표이거나 등록된 상표입니다.

여기에 언급된 실제 회사와 제품의 이름은 각각 해당 소유자의 상표일 수 있습니다.