ASP.NET 4.5 및 Visual Studio 2012의 새로운 기능
이 문서에서는 ASP.NET 4.5에서 도입되는 새로운 기능 및 향상된 기능에 대해 설명합니다. 또한 Visual Studio 2012에서 웹 개발을 위해 개선되는 기능도 설명합니다. 이 문서는 원래 2012년 2월 29일에 게시되었습니다.
ASP.NET Core 런타임 및 프레임워크
비동기적으로 HTTP 요청 및 응답 읽기 및 쓰기
ASP.NET 4에서는 HttpRequest.GetBufferlessInputStream 메서드를 사용하여 HTTP 요청 엔터티를 스트림으로 읽는 기능을 도입했습니다. 이 메서드는 요청 엔터티에 대한 스트리밍 액세스를 제공했습니다. 그러나 동기적으로 실행되어 요청 기간 동안 스레드를 연결했습니다.
ASP.NET 4.5는 HTTP 요청 엔터티에서 스트림을 비동기적으로 읽는 기능과 비동기적으로 플러시하는 기능을 지원합니다. 또한 ASP.NET 4.5는 .aspx 페이지 처리기 및 ASP.NET MVC 컨트롤러와 같은 다운스트림 HTTP 처리기와 보다 쉽게 통합할 수 있는 HTTP 요청 엔터티를 두 번 버퍼링하는 기능을 제공합니다.
HttpRequest 처리 개선 사항
HttpRequest.GetBufferlessInputStream에서 ASP.NET 4.5에서 반환된 Stream 참조는 동기 및 비동기 읽기 메서드를 모두 지원합니다. GetBufferlessInputStream에서 반환된 Stream 개체는 이제 BeginRead 및 EndRead 메서드를 모두 구현합니다. 비동기 Stream 메서드를 사용하면 요청 엔터티를 청크 단위로 비동기적으로 읽을 수 있으며, ASP.NET 비동기 읽기 루프의 각 반복 간에 현재 스레드를 해제합니다.
ASP.NET 4.5에서는 요청 엔터티를 버퍼링된 방식으로 읽기 위한 도우미 메서드인 HttpRequest.GetBufferedInputStream도 추가했습니다. 이 새로운 오버로드는 GetBufferlessInputStream과 같이 작동하며 동기 및 비동기 읽기를 모두 지원합니다. 그러나 GetBufferedInputStream 은 다운스트림 모듈 및 처리기가 여전히 요청 엔터티에 액세스할 수 있도록 엔터티 바이트를 ASP.NET 내부 버퍼에 복사합니다. 예를 들어 파이프라인의 일부 업스트림 코드가 GetBufferedInputStream을 사용하여 요청 엔터티를 이미 읽은 경우에도 HttpRequest.Form 또는 HttpRequest.Files를 사용할 수 있습니다. 이렇게 하면 요청(예: 데이터베이스에 대용량 파일 업로드 스트리밍)에 대해 비동기 처리를 수행할 수 있지만 나중에 .aspx 페이지 및 MVC ASP.NET 컨트롤러를 계속 실행할 수 있습니다.
비동기적으로 응답 플러시
클라이언트가 멀리 떨어져 있거나 대역폭 연결이 낮은 경우 HTTP 클라이언트에 응답을 보내는 데 상당한 시간이 걸릴 수 있습니다. 일반적으로 ASP.NET 애플리케이션에서 생성할 때 응답 바이트를 버퍼링합니다. 그런 다음 ASP.NET 요청 처리가 끝날 때 누적된 버퍼의 단일 송신 작업을 수행합니다.
버퍼링된 응답이 큰 경우(예: 대용량 파일을 클라이언트로 스트리밍) 정기적으로 HttpResponse.Flush 를 호출하여 클라이언트에 버퍼링된 출력을 보내고 메모리 사용량을 제어해야 합니다. 그러나 Flush 는 동기 호출이므로 Flush 를 반복적으로 호출하면 잠재적으로 장기 실행 요청 기간 동안 스레드가 계속 사용됩니다.
ASP.NET 4.5는 HttpResponse 클래스의 BeginFlush 및 EndFlush 메서드를 사용하여 비동기적으로 플러시 수행에 대한 지원을 추가합니다. 이러한 메서드를 사용하여 운영 체제 스레드를 연결하지 않고 클라이언트에 데이터를 증분 방식으로 보내는 비동기 모듈 및 비동기 처리기를 만들 수 있습니다. BeginFlush와 EndFlush 호출 사이에 ASP.NET 현재 스레드를 해제합니다. 이렇게 하면 장기 실행 HTTP 다운로드를 지원하기 위해 필요한 활성 스레드의 총 수가 크게 줄어듭니다.
await 및 Task 지원 - 기반 비동기 모듈 및 처리기
.NET Framework 4에서는 작업이라고 하는 비동기 프로그래밍 개념을 도입했습니다. 작업은 System.Threading.Tasks 네임스페이스의 작업 유형 및 관련 형식으로 표시됩니다. .NET Framework 4.5는 Task 개체 작업을 간단하게 만드는 컴파일러 개선 사항으로 이를 기반으로 합니다. .NET Framework 4.5에서 컴파일러에서는 await 및 async라는 두 개의 새로운 키워드를 지원합니다. await 키워드(keyword) 코드 조각이 다른 코드 조각을 비동기적으로 기다려야 함을 나타내는 구문 약어입니다. 비동기 키워드(keyword) 메서드를 작업 기반 비동기 메서드로 표시하는 데 사용할 수 있는 힌트를 나타냅니다.
await, async 및 Task 개체의 조합을 사용하면 .NET 4.5에서 비동기 코드를 훨씬 쉽게 작성할 수 있습니다. ASP.NET 4.5는 새 컴파일러 향상 기능을 사용하여 비동기 HTTP 모듈 및 비동기 HTTP 처리기를 작성할 수 있는 새 API를 사용하여 이러한 간소화를 지원합니다.
비동기 HTTP 모듈
Task 개체를 반환하는 메서드 내에서 비동기 작업을 수행한다고 가정합니다. 다음 코드 예제에서는 Microsoft 홈페이지를 다운로드하기 위해 비동기 호출을 하는 비동기 메서드를 정의합니다. 메서드 서명에서 비동기 키워드(keyword) 사용하고 DownloadStringTaskAsync에 대한 await 호출을 확인합니다.
private async Task
ScrapeHtmlPage(object caller, EventArgs e)
{
WebClient wc = new WebClient();
var result = await wc.DownloadStringTaskAsync("http://www.microsoft.com");
// Do something with the result
}
즉, 작성해야 하는 모든 항목입니다. .NET Framework 다운로드가 완료될 때까지 기다리는 동안 호출 스택 해제를 자동으로 처리하고 다운로드가 완료된 후 호출 스택을 자동으로 복원합니다.
이제 비동기 ASP.NET HTTP 모듈에서 이 비동기 메서드를 사용한다고 가정합니다. ASP.NET 4.5에는 ASP.NET HTTP 파이프라인에서 노출된 이전 비동기 프로그래밍 모델과 작업 기반 비동기 메서드를 통합하는 데 사용할 수 있는 도우미 메서드(EventHandlerTaskAsyncHelper) 및 새 대리자 형식(TaskEventHandler)이 포함되어 있습니다. 이 예제에서는 다음 방법을 보여줍니다.
public void Init(HttpApplication
context)
{
// Wrap the Task-based method so that it can be used with
// the older async programming model.
EventHandlerTaskAsyncHelper helper =
new EventHandlerTaskAsyncHelper(ScrapeHtmlPage);
// The helper object makes it easy to extract Begin/End methods out of
// a method that returns a Task object. The ASP.NET pipeline calls the
// Begin and End methods to start and complete calls on asynchronous
// HTTP modules.
context.AddOnPostAuthorizeRequestAsync(
helper.BeginEventHandler, helper.EndEventHandler);
}
비동기 HTTP 처리기
ASP.NET 비동기 처리기를 작성하는 기존의 방법은 IHttpAsyncHandler 인터페이스를 구현하는 것입니다. ASP.NET 4.5에서는 파생할 수 있는 HttpTaskAsyncHandler 비동기 기본 형식을 도입하여 비동기 처리기를 훨씬 쉽게 작성할 수 있습니다.
HttpTaskAsyncHandler 형식은 추상이며 ProcessRequestAsync 메서드를 재정의해야 합니다. 내부적으로 ASP.NET ProcessRequestAsync의 반환 서명(Task 개체)을 ASP.NET 파이프라인에서 사용하는 이전 비동기 프로그래밍 모델과 통합합니다.
다음 예제에서는 비동기 HTTP 처리기 구현의 일부로 Task 및 await 를 사용하는 방법을 보여줍니다.
public class MyAsyncHandler : HttpTaskAsyncHandler
{
// ...
// ASP.NET automatically takes care of integrating the Task based override
// with the ASP.NET pipeline.
public override async Task ProcessRequestAsync(HttpContext context)
{
WebClient wc = new WebClient();
var result = await
wc.DownloadStringTaskAsync("http://www.microsoft.com");
// Do something with the result
}
}
새 ASP.NET 요청 유효성 검사 기능
기본적으로 ASP.NET 요청 유효성 검사를 수행합니다. 필드, 헤더, 쿠키 등에서 태그 또는 스크립트를 찾는 요청을 검사합니다. 검색된 항목이 있으면 ASP.NET 예외를 throw합니다. 이는 잠재적인 교차 사이트 스크립팅 공격에 대한 첫 번째 방어선 역할을 합니다.
ASP.NET 4.5를 사용하면 유효성이 검사되지 않은 요청 데이터를 선택적으로 쉽게 읽을 수 있습니다. ASP.NET 4.5는 이전에 외부 라이브러리였던 널리 사용되는 AntiXSS 라이브러리도 통합합니다.
개발자는 애플리케이션에 대한 요청 유효성 검사를 선택적으로 해제하는 기능을 자주 요청했습니다. 예를 들어 애플리케이션이 포럼 소프트웨어인 경우 사용자가 HTML 형식의 포럼 게시물 및 의견을 제출하도록 허용할 수 있지만 요청 유효성 검사가 다른 모든 항목을 확인하는지 확인합니다.
ASP.NET 4.5에는 유효성 검사되지 않은 입력을 선택적으로 쉽게 사용할 수 있는 두 가지 기능인 지연된("지연") 요청 유효성 검사 및 유효성 검사되지 않은 요청 데이터에 대한 액세스가 도입되었습니다.
지연("지연") 요청 유효성 검사
ASP.NET 4.5에서는 기본적으로 모든 요청 데이터에 요청 유효성 검사가 적용됩니다. 그러나 실제로 요청 데이터에 액세스할 때까지 요청 유효성 검사를 연기하도록 애플리케이션을 구성할 수 있습니다. (특정 데이터 시나리오에 대한 지연 로드와 같은 용어에 따라 지연 요청 유효성 검사라고도 합니다.) 다음 예제와 같이 httpRUntime 요소에서 requestValidationMode 특성을 4.5로 설정하여 Web.config 파일에서 지연된 유효성 검사를 사용하도록 애플리케이션을 구성할 수 있습니다.
<httpRuntime requestValidationMode="4.5" ... />
요청 유효성 검사 모드가 4.5로 설정된 경우 요청 유효성 검사는 코드가 해당 값에 액세스할 때만 특정 요청 값에 대해서만 트리거됩니다. 예를 들어 코드가 Request.Form["forum_post"]의 값을 가져오면 양식 컬렉션의 해당 요소에 대해서만 요청 유효성 검사가 호출됩니다. Form 컬렉션의 다른 요소 중 어느 것도 유효성을 검사하지 않습니다. 이전 버전의 ASP.NET 컬렉션의 요소에 액세스할 때 전체 요청 컬렉션에 대해 요청 유효성 검사가 트리거되었습니다. 새 동작을 사용하면 다른 부분에 대한 요청 유효성 검사를 트리거하지 않고도 다른 애플리케이션 구성 요소가 다양한 요청 데이터를 더 쉽게 볼 수 있습니다.
유효성이 검사되지 않은 요청에 대한 지원
지연된 요청 유효성 검사만으로는 요청 유효성 검사를 선택적으로 바이패스하는 문제가 해결되지 않습니다. Request.Form["forum_post"]에 대한 호출은 해당 특정 요청 값에 대한 요청 유효성 검사를 계속 트리거합니다. 그러나 해당 필드에 태그를 허용하려고 하므로 유효성 검사를 트리거하지 않고 이 필드에 액세스할 수 있습니다.
이를 허용하기 위해 ASP.NET 4.5는 이제 요청 데이터에 대한 검증되지 않은 액세스를 지원합니다. ASP.NET 4.5에는 HttpRequest 클래스에 유효성이 검사되지 않은 새 컬렉션 속성이 포함되어 있습니다. 이 컬렉션은 Form, QueryString, Cookies 및 Url과 같은 요청 데이터의 모든 공통 값에 대한 액세스를 제공합니다.
포럼 예제를 사용하여 유효성이 검사되지 않은 요청 데이터를 읽을 수 있도록 먼저 새 요청 유효성 검사 모드를 사용하도록 애플리케이션을 구성해야 합니다.
<httpRuntime requestValidationMode="4.5" ...
/>
그런 다음 HttpRequest.Unvalidated 속성을 사용하여 유효성이 검사되지 않은 양식 값을 읽을 수 있습니다.
var s = context.Request.Unvalidated.Form["forum_post"];
경고
보안 - 유효성이 검사되지 않은 요청 데이터를 주의해서 사용합니다. ASP.NET 4.5는 유효성이 검사되지 않은 요청 속성 및 컬렉션을 추가하여 매우 구체적인 검증되지 않은 요청 데이터에 더 쉽게 액세스할 수 있도록 했습니다. 그러나 위험한 텍스트가 사용자에게 렌더링되지 않도록 원시 요청 데이터에 대해 사용자 지정 유효성 검사를 계속 수행해야 합니다.
AntiXSS 라이브러리
Microsoft AntiXSS 라이브러리의 인기로 인해 ASP.NET 4.5는 이제 해당 라이브러리 버전 4.0의 핵심 인코딩 루틴을 통합합니다.
인코딩 루틴은 새 System.Web.Security.AntiXss 네임스페이스의 AntiXssEncoder 형식에 의해 구현됩니다. 형식에 구현된 정적 인코딩 메서드를 호출하여 AntiXssEncoder 형식을 직접 사용할 수 있습니다. 그러나 새로운 XSS 방지 루틴을 사용하는 가장 쉬운 방법은 기본적으로 AntiXssEncoder 클래스를 사용하도록 ASP.NET 애플리케이션을 구성하는 것입니다. 이렇게 하려면 다음 특성을 Web.config 파일에 추가합니다.
<httpRuntime ...
encoderType="System.Web.Security.AntiXss.AntiXssEncoder,System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
encoderType 특성이 AntiXssEncoder 형식을 사용하도록 설정되면 ASP.NET 모든 출력 인코딩이 새 인코딩 루틴을 자동으로 사용합니다.
다음은 ASP.NET 4.5에 통합된 외부 AntiXSS 라이브러리의 부분입니다.
- HtmlEncode, HtmlFormUrlEncode 및 HtmlAttributeEncode
- XmlAttributeEncode 및 XmlEncode
- UrlEncode 및 UrlPathEncode (신규)
- CssEncode
WebSockets 프로토콜 지원
WebSockets 프로토콜은 HTTP를 통해 클라이언트와 서버 간에 안전하고 실시간 양방향 통신을 설정하는 방법을 정의하는 표준 기반 네트워크 프로토콜입니다. Microsoft는 프로토콜을 정의하는 데 도움이 되도록 IETF 및 W3C 표준 본문을 모두 사용했습니다. WebSockets 프로토콜은 모든 클라이언트(브라우저뿐만 아니라)에서 지원되며, Microsoft는 클라이언트 및 모바일 운영 체제 모두에서 WebSockets 프로토콜을 지원하는 상당한 리소스를 투자합니다.
WebSockets 프로토콜을 사용하면 클라이언트와 서버 간에 장기 실행 데이터 전송을 훨씬 쉽게 만들 수 있습니다. 예를 들어 클라이언트와 서버 간에 진정한 장기 실행 연결을 설정할 수 있으므로 채팅 애플리케이션을 작성하는 것이 훨씬 쉽습니다. 소켓의 동작을 시뮬레이션하기 위해 주기적 폴링 또는 HTTP 장기 폴링과 같은 해결 방법을 사용할 필요가 없습니다.
ASP.NET 4.5 및 IIS 8에는 하위 수준 WebSockets 지원이 포함되어 있으므로 ASP.NET 개발자는 WebSockets 개체에서 문자열 및 이진 데이터를 비동기적으로 읽고 쓰는 데 관리되는 API를 사용할 수 있습니다. ASP.NET 4.5의 경우 WebSockets 프로토콜을 사용하기 위한 형식을 포함하는 새 System.Web.WebSockets 네임스페이스가 있습니다.
브라우저 클라이언트는 다음 예제와 같이 ASP.NET 애플리케이션의 URL을 가리키는 DOM WebSocket 개체를 만들어 WebSockets 연결을 설정합니다.
socket = new WebSocket("ws://contoso.com/MyWebSocketApplication.ashx");
모든 종류의 모듈 또는 처리기를 사용하여 ASP.NET WebSockets 엔드포인트를 만들 수 있습니다. 이전 예제에서는 .ashx 파일이 처리기를 만드는 빠른 방법이기 때문에 .ashx 파일이 사용되었습니다.
WebSockets 프로토콜에 따르면 ASP.NET 애플리케이션은 요청을 HTTP GET 요청에서 WebSockets 요청으로 업그레이드해야 함을 표시하여 클라이언트의 WebSockets 요청을 수락합니다. 예를 들면 다음과 같습니다.
HttpContext.Current.AcceptWebSocketRequest(// WebSocket delegate goes here)
AcceptWebSocketRequest 메서드는 ASP.NET 현재 HTTP 요청을 해제한 다음 함수 대리자로 제어를 전송하기 때문에 함수 대리자를 허용합니다. 개념적으로 이 방법은 백그라운드 작업이 수행되는 스레드 시작 대리자를 정의하는 System.Threading.Thread를 사용하는 방법과 유사합니다.
ASP.NET 클라이언트가 WebSockets 핸드셰이크를 성공적으로 완료한 후 ASP.NET 대리자를 호출하고 WebSockets 애플리케이션이 실행을 시작합니다. 다음 코드 예제에서는 ASP.NET 기본 제공 WebSockets 지원을 사용하는 간단한 에코 애플리케이션을 보여 줍니다.
public async Task MyWebSocket(AspNetWebSocketContext context)
{
WebSocket socket = context.WebSocket;
while (true)
{
ArraySegment<byte> buffer = new ArraySegment<byte>(new byte[1024]);
// Asynchronously wait for a message to arrive from a client
WebSocketReceiveResult result =
await socket.ReceiveAsync(buffer, CancellationToken.None);
// If the socket is still open, echo the message back to the client
if (socket.State == WebSocketState.Open)
{
string userMessage = Encoding.UTF8.GetString(buffer.Array, 0,
result.Count);
userMessage = "You sent: " + userMessage + " at " +
DateTime.Now.ToLongTimeString();
buffer = new ArraySegment<byte>(Encoding.UTF8.GetBytes(userMessage));
// Asynchronously send a message to the client
await socket.SendAsync(buffer, WebSocketMessageType.Text,
true, CancellationToken.None);
}
else { break; }
}
}
await 키워드(keyword) 및 비동기 작업 기반 작업에 대한 .NET 4.5 지원은 WebSockets 애플리케이션을 작성하는 데 자연스럽게 적합합니다. 코드 예제에서는 WebSockets 요청이 ASP.NET 내에서 완전히 비동기적으로 실행되는 것을 보여 줍니다. 애플리케이션은 await 소켓을 호출하여 클라이언트에서 메시지를 보낼 때까지 비동기적으로 대기합니다 . ReceiveAsync. 마찬가지로 await 소켓을 호출하여 클라이언트에 비동기 메시지를 보낼 수 있습니다 . SendAsync.
브라우저에서 애플리케이션은 onmessage 함수를 통해 WebSockets 메시지를 받습니다. 브라우저에서 메시지를 보내려면 다음 예제와 같이 WebSocket DOM 형식의 send 메서드를 호출합니다.
// Receive a string message from the server.
socket.onmessage = function(msg)
{
document.getElementById("serverData").innerHTML = msg.data;
};
// Send a string message from the browser.
socket.send(document.getElementById("msgText"));
나중에 WebSockets 애플리케이션에 대해 이 릴리스에 필요한 일부 하위 수준 코딩을 추상화하는 이 기능에 대한 업데이트를 릴리스할 수 있습니다.
묶음 및 축소
번들링을 사용하면 개별 JavaScript 및 CSS 파일을 단일 파일처럼 처리할 수 있는 번들로 결합할 수 있습니다. 축소는 필수가 아닌 공백 및 기타 문자를 제거하여 JavaScript 및 CSS 파일을 압축합니다. 이러한 기능은 Web Forms, ASP.NET MVC 및 웹 페이지에서 작동합니다.
번들은 Bundle 클래스 또는 해당 자식 클래스 중 하나인 ScriptBundle 및 StyleBundle을 사용하여 만들어집니다. 번들의 instance 구성한 후에는 번들을 전역 BundleCollection instance 추가하여 들어오는 요청에 번들을 사용할 수 있게 됩니다. 기본 템플릿에서 번들 구성은 BundleConfig 파일에서 수행됩니다. 이 기본 구성은 템플릿에서 사용하는 모든 핵심 스크립트 및 css 파일에 대한 번들을 만듭니다.
번들은 가능한 몇 가지 도우미 방법 중 하나를 사용하여 보기 내에서 참조됩니다. 디버그 및 릴리스 모드에서 번들에 대해 다른 태그 렌더링을 지원하기 위해 ScriptBundle 및 StyleBundle 클래스에는 도우미 메서드 Render가 있습니다. 디버그 모드에서 Render는 번들에 있는 각 리소스에 대한 태그를 생성합니다. 릴리스 모드에서 Render는 전체 번들에 대해 단일 태그 요소를 생성합니다. 아래와 같이 web.config 컴파일 요소의 디버그 특성을 수정하여 디버그 모드와 릴리스 모드 간에 전환할 수 있습니다.
<system.web>
<compilation targetframework="4.5" debug="true" />
...</system.web>
또한 BundleTable.EnableOptimizations 속성을 통해 직접 최적화를 사용하거나 사용하지 않도록 설정할 수 있습니다.
BundleTable.EnableOptimizations = true;
파일이 번들로 묶이면 먼저 사전순으로 정렬됩니다(솔루션 탐색기 표시되는 방식). 그런 다음 알려진 라이브러리와 사용자 지정 확장(예: jQuery, MooTools 및 Dojo)이 먼저 로드되도록 구성됩니다. 예를 들어 위에 표시된 대로 Scripts 폴더의 번들링에 대한 최종 순서는 다음과 같습니다.
- jquery-1.6.2.js
- jquery-ui.js
- jquery.tools.js
- a.js
또한 CSS 파일은 사전순으로 정렬된 다음 다시 구성되므로 reset.css 및 normalize.css가 다른 파일보다 우선합니다. 위에 표시된 Styles 폴더의 묶음의 마지막 정렬은 다음과 같습니다.
- reset.css
- content.css
- forms.css
- globals.css
- menu.css
- styles.css
웹 호스팅에 대한 성능 향상
.NET Framework 4.5 및 Windows 8에는 웹 서버 워크로드에 대한 성능 향상을 달성하는 데 도움이 되는 기능이 도입되었습니다. 여기에는 시작 시간과 ASP.NET 사용하는 웹 호스팅 사이트의 메모리 공간 모두에서 감소(최대 35%)가 포함됩니다.
주요 성능 요소
이상적으로, 모든 웹 사이트는 다음 요청에 대한 빠른 응답을 보장하기 위해 활성 및 메모리에 있어야합니다, 그것은 올 때마다. 사이트 응답성에 영향을 줄 수 있는 요인은 다음과 같습니다.
- 앱 풀이 재활용된 후 사이트를 다시 시작하는 데 걸리는 시간입니다. 사이트 어셈블리가 더 이상 메모리에 없을 때 사이트에 대한 웹 서버 프로세스를 시작하는 데 걸리는 시간입니다. (플랫폼 어셈블리는 다른 사이트에서 사용되므로 여전히 메모리에 있습니다.) 이 상황을 "콜드 사이트, 웜 프레임워크 시작" 또는 "콜드 사이트 시작"이라고 합니다.
- 사이트에서 차지하는 메모리 양입니다. 이에 대한 용어는 "사이트별 메모리 사용량" 또는 "공유되지 않은 작업 집합"입니다.
새로운 성능 향상은 이러한 두 가지 요인에 중점을 줍니다.
새 성능 기능에 대한 요구 사항
새 기능에 대한 요구 사항은 다음 범주로 나눌 수 있습니다.
- .NET Framework 4에서 실행되는 개선 사항입니다.
- .NET Framework 4.5가 필요하지만 모든 버전의 Windows에서 실행할 수 있는 향상된 기능
- Windows 8에서 실행되는 .NET Framework 4.5에서만 사용할 수 있는 향상된 기능.
사용하도록 설정할 수 있는 각 개선 수준에 따라 성능이 향상됩니다.
.NET Framework 4.5 개선 사항 중 일부는 다른 시나리오에도 적용되는 광범위한 성능 기능을 활용합니다.
공용 어셈블리 공유
요구 사항: .NET Framework 4 및 Visual Studio 11 Developer Preview SDK
서버의 여러 사이트에서 동일한 도우미 어셈블리(예: 시작 키트 또는 샘플 애플리케이션의 어셈블리)를 사용하는 경우가 많습니다. 각 사이트에는 Bin 디렉터리에 이러한 어셈블리의 자체 복사본이 있습니다. 어셈블리의 개체 코드는 동일하지만 물리적으로 분리된 어셈블리이므로 콜드 사이트 시작 중에 각 어셈블리를 개별적으로 읽고 메모리에 별도로 보관해야 합니다.
새로운 인턴 기능은 이러한 비효율성을 해결하고 RAM 요구 사항과 로드 시간을 모두 줄입니다. 인턴을 사용하면 Windows에서 파일 시스템에서 각 어셈블리의 단일 복사본을 유지할 수 있으며 사이트 Bin 폴더의 개별 어셈블리는 단일 복사본에 대한 기호 링크로 바뀝니다. 개별 사이트에 고유한 버전의 어셈블리가 필요한 경우 기호 링크가 새 버전의 어셈블리로 대체되고 해당 사이트만 영향을 받습니다.
기호 링크를 사용하여 어셈블리를 공유하려면 aspnet_intern.exe 라는 새 도구가 필요합니다. 이를 통해 인턴된 어셈블리의 저장소를 만들고 관리할 수 있습니다. Visual Studio 11 Developer Preview SDK의 일부로 제공됩니다. 그러나 최신 업데이트를 설치했다고 가정하면 .NET Framework 4만 설치된 시스템에서 작동합니다.
적격 어셈블리가 모두 인턴되었는지 확인하려면 aspnet_intern.exe 주기적으로 실행합니다(예: 예약된 작업으로 일주일에 한 번). 일반적인 사용은 다음과 같습니다.
aspnet_intern -mode exec -sourcedir
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" -interndir C:\ASPNETCommonAssemblies
모든 옵션을 보려면 인수 없이 도구를 실행합니다.
더 빠른 시작을 위해 다중 코어 JIT 컴파일 사용
요구 사항: .NET Framework 4.5
콜드 사이트 시작의 경우 디스크에서 어셈블리를 읽어야 할 뿐만 아니라 사이트를 JIT 컴파일해야 합니다. 복잡한 사이트의 경우 상당한 지연이 발생할 수 있습니다. .NET Framework 4.5의 새로운 범용 기술은 사용 가능한 프로세서 코어에 JIT 컴파일을 분산하여 이러한 지연을 줄입니다. 그것은 사이트의 이전 출시 동안 수집 된 정보를 사용하여 가능한 한 빨리이 작업을 수행합니다. System.Runtime.ProfileOptimization.StartProfile 메서드에 의해 구현된 이 기능입니다.
여러 코어를 사용하는 JIT 컴파일은 기본적으로 ASP.NET 사용하도록 설정되므로 이 기능을 활용하기 위해 아무 것도 수행할 필요가 없습니다. 이 기능을 사용하지 않도록 설정하려면 Web.config 파일에서 다음 설정을 지정합니다.
<configuration>
<!-- ... -->
<system.web>
<compilation profileGuidedOptimizations="None" />
<!-- ... -->
가비지 수집을 튜닝하여 메모리 최적화
요구 사항: .NET Framework 4.5
사이트가 실행되면 GC(가비지 수집기) 힙을 사용하는 것이 메모리 소비에 중요한 요인이 될 수 있습니다. 가비지 수집기와 마찬가지로 .NET Framework GC는 CPU 시간(컬렉션의 빈도 및 중요도)과 메모리 소비(새 개체, 해제 또는 자유 가능 개체에 사용되는 추가 공간)를 절충합니다. 이전 릴리스에서는 적절한 균형을 달성하도록 GC를 구성하는 방법에 대한 지침을 제공했습니다(예: ASP.NET 2.0/3.5 공유 호스팅 구성 참조).
.NET Framework 4.5의 경우 여러 독립 실행형 설정 대신 이전에 권장된 모든 GC 설정과 사이트별 작업 집합에 대한 추가 성능을 제공하는 새로운 튜닝을 사용하도록 설정하는 워크로드 정의 구성 설정을 사용할 수 있습니다.
GC 메모리 튜닝을 사용하도록 설정하려면 Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config 파일에 다음 설정을 추가합니다.
<configuration>
<!-- ... -->
<runtime>
<performanceScenario value="HighDensityWebHosting" />
<!-- ... -->
(aspnet.config 변경에 대한 이전 지침에 익숙한 경우 이 설정은 이전 설정을 대체합니다. 예를 들어 gcServer, gcConcurrent 등을 설정할 필요가 없습니다. 이전 설정을 제거할 필요가 없습니다.)
웹 애플리케이션에 대한 프리페치
요구 사항: Windows 8에서 실행되는 .NET Framework 4.5
여러 릴리스의 경우 Windows에는 애플리케이션 시작의 디스크 읽기 비용을 줄이는 프리페처 라는 기술이 포함되어 있습니다. 콜드 시작은 주로 클라이언트 애플리케이션의 문제이므로 이 기술은 서버에 필수적인 구성 요소만 포함하는 Windows Server에 포함되지 않았습니다. 이제 프리페치를 최신 버전의 Windows Server에서 사용할 수 있으며, 여기에서 개별 웹 사이트의 시작을 최적화할 수 있습니다.
Windows Server의 경우 프리페처는 기본적으로 사용하도록 설정되지 않습니다. 고밀도 웹 호스팅을 위해 prefetcher를 사용하도록 설정하고 구성하려면 명령줄에서 다음 명령 집합을 실행합니다.
sc config sysmain start=auto
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters" /v EnablePrefetcher /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Prefetcher" /v MaxPrefetchFiles /t REG_DWORD /d 8192 /f
net start sysmain
그런 다음, prefetcher를 ASP.NET 애플리케이션과 통합하려면 Web.config 파일에 다음을 추가합니다.
<configuration>
<!-- ... -->
<system.web>
<compilation enablePrefetchOptimization="true" />
<!-- ... -->
ASP.NET 웹 양식
강력한 형식의 데이터 컨트롤
ASP.NET 4.5에서는 Web Forms 데이터 작업에 대한 몇 가지 개선 사항이 포함되어 있습니다. 첫 번째 개선 사항은 강력한 형식의 데이터 컨트롤입니다. 이전 버전의 ASP.NET Web Forms 컨트롤의 경우 Eval 및 데이터 바인딩 식을 사용하여 데이터 바인딩된 값을 표시합니다.
<ul>
<asp:Repeater runat="server" ID="customers">
<ItemTemplate>
<li>
First Name: <%# Eval("FirstName")%><br />
Last Name: <%# Eval("LastName")%><br />
</li>
</ItemTemplate>
</asp:Repeater>
</ul>
양방향 데이터 바인딩의 경우 Bind:
<asp:FormView runat="server" ID="editCustomer">
<EditItemTemplate>
<div>
<asp:Label runat="server" AssociatedControlID="firstName">
First Name:</asp:Label>
<asp:TextBox ID="firstName" runat="server"
Text='<%#Bind("FirstName") %>' />
</div>
<div>
<asp:Label runat="server" AssociatedControlID="lastName">
First Name:</asp:Label>
<asp:TextBox ID="lastName" runat="server"
Text='<%#
Bind("LastName") %>' />
</div>
<asp:Button runat="server" CommandName="Update"/>
</EditItemTemplate>
</asp:FormView>
런타임에 이러한 호출은 리플렉션을 사용하여 지정된 멤버의 값을 읽은 다음 태그에 결과를 표시합니다. 이 접근 방식을 사용하면 임의의, 공유되지 않은 데이터에 대해 데이터를 쉽게 바인딩할 수 있습니다.
그러나 이와 같은 데이터 바인딩 식은 멤버 이름, 탐색(예: 정의로 이동) 또는 이러한 이름에 대한 컴파일 시간 검사에 대한 IntelliSense와 같은 기능을 지원하지 않습니다.
이 문제를 해결하기 위해 ASP.NET 4.5는 컨트롤이 바인딩된 데이터의 데이터 형식을 선언하는 기능을 추가합니다. 새 ItemType 속성을 사용하여 이 작업을 수행합니다. 이 속성을 설정하면 데이터 바인딩 식의 scope Item 및 BindItem이라는 두 개의 새 형식 변수를 사용할 수 있습니다. 변수는 강력한 형식이므로 Visual Studio 개발 환경의 모든 이점을 얻을 수 있습니다.
양방향 데이터 바인딩 식의 경우 BindItem 변수를 사용합니다.
<asp:FormView runat="server" ID="editCustomer">
<EditItemTemplate>
<div>
<asp:Label runat="server" AssociatedControlID="firstName">
First Name:</asp:Label>
<asp:TextBox ID="firstName" runat="server"
Text='<%#BindItem.FirstName %>' />
</div>
<div>
<asp:Label runat="server" AssociatedControlID="lastName">
First Name:</asp:Label>
<asp:TextBox ID="lastName" runat="server"
Text='<%#BindItem.LastName %>' />
</div>
<asp:Button runat="server" CommandName="Update"/>
</EditItemTemplate>
</asp:FormView>
데이터 바인딩을 지원하는 ASP.NET Web Forms 프레임워크의 대부분의 컨트롤이 ItemType 속성을 지원하도록 업데이트되었습니다.
모델 바인딩
모델 바인딩은 코드 중심 데이터 액세스와 작동하도록 ASP.NET Web Forms 컨트롤에서 데이터 바인딩을 확장합니다. ObjectDataSource 컨트롤과 ASP.NET MVC의 모델 바인딩의 개념을 통합합니다.
데이터 선택
모델 바인딩을 사용하여 데이터를 선택하도록 데이터 컨트롤을 구성하려면 컨트롤의 SelectMethod 속성을 페이지 코드의 메서드 이름으로 설정합니다. 데이터 컨트롤은 페이지 수명 주기에서 적절한 시간에 메서드를 호출하고 반환된 데이터를 자동으로 바인딩합니다. DataBind 메서드를 명시적으로 호출할 필요가 없습니다.
다음 예제에서 GridView 컨트롤은 GetCategories라는 메서드를 사용하도록 구성됩니다.
<asp:GridView ID="categoriesGrid"
runat="server"
ItemType="WebApplication1.Model.Category"
SelectMethod="GetCategories" AutoGenerateColumns="false">
<Columns>
<asp:BoundField DataField="CategoryID" HeaderText="ID" />
<asp:BoundField DataField="CategoryName" HeaderText="Name" />
<asp:BoundField DataField="Description" HeaderText="Description" />
<asp:TemplateField HeaderText="# of Products">
<ItemTemplate><%# Item.Products.Count %></ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>
페이지의 코드에서 GetCategories 메서드를 만듭니다. 간단한 선택 작업의 경우 메서드에 매개 변수가 필요하지 않으며 IEnumerable 또는 IQueryable 개체를 반환해야 합니다. 앞에서 설명한 대로 강력한 형식의 데이터 바인딩 식을 사용하도록 설정하는 새 ItemType 속성이 설정된 경우 이러한 인터페이스의 제네릭 버전(IEnumerable<T> 또는 IQueryable<T>)을 ItemType 속성의 형식과 일치하는 T 매개 변수(예: IQueryable<Category>)와 함께 반환해야 합니다.
다음 예제에서는 GetCategories 메서드에 대한 코드를 보여줍니다. 이 예제에서는 Northwind 샘플 데이터베이스와 함께 Entity Framework Code First 모델을 사용합니다. 이 코드는 쿼리가 Include 메서드를 통해 각 범주에 대한 관련 제품의 세부 정보를 반환하도록 합니다. 이렇게 하면 태그의 TemplateField 요소가 n+1 선택을 요구하지 않고 각 범주의 제품 수를 표시합니다.
public IQueryable<Category>
GetCategories()
{
var db = new Northwind();
return db.Categories.Include(c => c.Products);
}
페이지가 실행되면 GridView 컨트롤은 GetCategories 메서드를 자동으로 호출하고 구성된 필드를 사용하여 반환된 데이터를 렌더링합니다.
select 메서드는 IQueryable 개체를 반환하므로 GridView 컨트롤은 쿼리를 실행하기 전에 추가로 조작할 수 있습니다. 예를 들어 GridView 컨트롤은 반환된 IQueryable 개체를 실행하기 전에 정렬 및 페이징을 위한 쿼리 식을 추가하여 기본 LINQ 공급자가 해당 작업을 수행할 수 있습니다. 이 경우 Entity Framework는 이러한 작업이 데이터베이스에서 수행되도록 합니다.
다음 예제에서는 정렬 및 페이징을 허용하도록 수정된 GridView 컨트롤을 보여줍니다.
<asp:GridView ID="categoriesGrid"
runat="server"
AutoGenerateColumns="false"
AllowSorting="true" AllowPaging="true" PageSize="5"
ItemType="WebApplication1.Model.Category" DataKeyNames="CategoryID"
SelectMethod="GetCategories"
UpdateMethod="UpdateCategory">
<Columns>
<asp:BoundField DataField="CategoryID" HeaderText="ID" SortExpression="CategoryID" />
<asp:BoundField DataField="CategoryName" HeaderText="Name" SortExpression="CategoryName" />
<asp:BoundField DataField="Description" HeaderText="Description" />
<asp:TemplateField HeaderText="# of Products">
<ItemTemplate><%# Item.Products.Count %></ItemTemplate>
</asp:TemplateField>
</Columns>
<EmptyDataTemplate>No categories found with a product count of
<%# minProductsCount.SelectedValue %></EmptyDataTemplate>
</asp:GridView>
이제 페이지가 실행되면 컨트롤은 데이터의 현재 페이지만 표시되고 선택한 열에 따라 정렬되도록 할 수 있습니다.
반환된 데이터를 필터링하려면 매개 변수를 select 메서드에 추가해야 합니다. 이러한 매개 변수는 런타임에 모델 바인딩에 의해 채워지고 데이터를 반환하기 전에 쿼리를 변경하는 데 사용할 수 있습니다.
예를 들어 사용자가 쿼리 문자열에 키워드(keyword) 입력하여 제품을 필터링하도록 하려는 경우를 가정합니다. 메서드에 매개 변수를 추가하고 매개 변수 값을 사용하도록 코드를 업데이트할 수 있습니다.
public IQueryable<Product>
GetProducts(string keyword)
{
IQueryable<Product> query = _db.Products;
if (!String.IsNullOrWhiteSpace(keyword))
{
query = query.Where(p => p.ProductName.Contains(keyword));
}
return query;
}
이 코드에는 키워드(keyword) 대한 값이 제공된 다음 쿼리 결과를 반환하는 경우 Where 식이 포함됩니다.
값 공급자
이전 예제에서는 키워드(keyword) 매개 변수의 값이 어디에서 오는지 구체적으로 설명하지 않았습니다. 이 정보를 나타내기 위해 매개 변수 특성을 사용할 수 있습니다. 이 예제에서는 System.Web.ModelBinding 네임스페이스에 있는 QueryStringAttribute 클래스를 사용할 수 있습니다.
public IQueryable<Product>
GetProducts([QueryString]string keyword)
{
IQueryable<Product> query = _db.Products;
if (!String.IsNullOrWhiteSpace(keyword))
{
query = query.Where(p => p.ProductName.Contains(keyword));
}
return query;
}
이렇게 하면 런타임에 쿼리 문자열의 값을 키워드(keyword) 매개 변수에 바인딩하도록 모델 바인딩에 지시합니다. (이 경우에는 그렇지 않지만 형식 변환 수행이 포함될 수 있습니다.) 값을 제공할 수 없고 형식이 null을 허용하지 않는 경우 예외가 throw됩니다.
이러한 메서드의 값 원본을 값 공급자라고 하며 사용할 값 공급자를 나타내는 매개 변수 특성을 값 공급자 특성이라고 합니다. Web Forms 쿼리 문자열, 쿠키, 양식 값, 컨트롤, 뷰 상태, 세션 상태 및 프로필 속성과 같은 Web Forms 애플리케이션에서 사용자 입력의 모든 일반적인 소스에 대한 값 공급자 및 해당 특성을 포함합니다. 사용자 지정 값 공급자를 작성할 수도 있습니다.
기본적으로 매개 변수 이름은 값 공급자 컬렉션에서 값을 찾기 위한 키로 사용됩니다. 이 예제에서 코드는 키워드(keyword)(예: ~/default.aspx?키워드(keyword) 쿼리 문자열 값을 찾습니다.=chef). 매개 변수 특성에 인수로 전달하여 사용자 지정 키를 지정할 수 있습니다. 예를 들어 q라는 쿼리 문자열 변수의 값을 사용하려면 다음을 수행할 수 있습니다.
public IQueryable<Product>
GetProducts([QueryString("q")]string keyword)
{
IQueryable<Product> query = _db.Products;
if (!String.IsNullOrWhiteSpace(keyword))
{
query = query.Where(p => p.ProductName.Contains(keyword));
}
return query;
}
이 메서드가 페이지의 코드에 있는 경우 사용자는 쿼리 문자열을 사용하여 키워드(keyword) 전달하여 결과를 필터링할 수 있습니다.
모델 바인딩은 값을 읽고, null 값을 확인하고, 적절한 형식으로 변환하려고 시도하고, 변환이 성공했는지 확인하고, 마지막으로 쿼리의 값을 사용하여 직접 코딩해야 하는 많은 작업을 수행합니다. 모델 바인딩으로 인해 코드가 훨씬 줄어들고 애플리케이션 전체에서 기능을 다시 사용할 수 있습니다.
컨트롤의 값으로 필터링
사용자가 드롭다운 목록에서 필터 값을 선택할 수 있도록 예제를 확장하려는 경우를 가정해 보겠습니다. 태그에 다음 드롭다운 목록을 추가하고 SelectMethod 속성을 사용하여 다른 메서드에서 해당 데이터를 가져올 수 있도록 구성합니다.
<asp:Label runat="server" AssociatedControlID="categories"
Text="Select a category to show products for: " />
<asp:DropDownList runat="server" ID="categories"
SelectMethod="GetCategories" AppendDataBoundItems="true"
DataTextField="CategoryName" DataValueField="CategoryID"
AutoPostBack="true">
<asp:ListItem Value="" Text="- all -" />
</asp:DropDownList>
일반적으로 일치하는 제품을 찾을 수 없는 경우 컨트롤이 메시지를 표시하도록 GridView 컨트롤에 EmptyDataTemplate 요소를 추가합니다.
<asp:GridView ID="productsGrid"
runat="server" DataKeyNames="ProductID"
AllowPaging="true" AllowSorting="true" AutoGenerateColumns="false"
SelectMethod="GetProducts" >
<Columns>
<asp:BoundField DataField="ProductID" HeaderText="ID" />
<asp:BoundField DataField="ProductName" HeaderText="Name"
SortExpression="ProductName" />
<asp:BoundField DataField="UnitPrice" HeaderText="Unit Price"
SortExpression="UnitPrice" />
<asp:BoundField DataField="UnitsInStock" HeaderText="# in Stock"
SortExpression="UnitsInStock" />
</Columns>
<EmptyDataTemplate>
No products matching the filter criteria were found</EmptyDataTemplate>
</asp:GridView>
페이지 코드에서 드롭다운 목록에 대한 새 select 메서드를 추가합니다.
public IQueryable<Category>
GetCategories()
{
return _db.Categories;
}
마지막으로 GetProducts select 메서드를 업데이트하여 드롭다운 목록에서 선택한 범주의 ID를 포함하는 새 매개 변수를 사용합니다.
public IQueryable<Product>
GetProducts(
[QueryString("q")] string keyword,
[Control("categories")] int? categoryId)
{
IQueryable<Product> query = _db.Products;
if (!String.IsNullOrWhiteSpace(keyword))
{
query = query.Where(p => p.ProductName.Contains(keyword));
}
if (categoryId.HasValue && categoryId > 0)
{
query = query.Where(p => p.CategoryID == categoryId);
}
return query;
}
이제 페이지가 실행되면 사용자는 드롭다운 목록에서 범주를 선택할 수 있으며 GridView 컨트롤은 필터링된 데이터를 표시하도록 자동으로 다시 바인딩됩니다. 모델 바인딩은 선택한 메서드에 대한 매개 변수 값을 추적하고 포스트백 후 매개 변수 값이 변경되었는지 여부를 감지하기 때문에 가능합니다. 이 경우 모델 바인딩은 연결된 데이터 컨트롤을 강제로 데이터에 다시 바인딩합니다.
HTML 인코딩된 Data-Binding 식
이제 데이터 바인딩 식의 결과를 HTML로 인코딩할 수 있습니다. 콜론 추가(:) 데이터 바인딩 식을 표시하는 %# 접두사 끝에 <다음을 수행합니다.
<asp:TemplateField HeaderText="Name">
<ItemTemplate><%#: Item.Products.Name %></ItemTemplate>
</asp:TemplateField>
눈에 거슬리지 않는 유효성 검사
이제 클라이언트 쪽 유효성 검사 논리에 눈에 거슬리지 않는 JavaScript를 사용하도록 기본 제공 유효성 검사기 컨트롤을 구성할 수 있습니다. 이렇게 하면 페이지 태그에서 인라인으로 렌더링되는 JavaScript의 양이 크게 줄어들고 전체 페이지 크기가 줄어듭니다. 다음과 같은 방법으로 유효성 검사기 컨트롤에 대해 눈에 거슬리지 않는 JavaScript를 구성할 수 있습니다.
Web.config 파일의 <appSettings 요소에 다음 설정을 추가하여 전역적으로 다음 설정을 추가합니다> .
<add name="ValidationSettings:UnobtrusiveValidationMode" value="WebForms" />정적 System.Web.UI.ValidationSettings.UnobtrusiveValidationMode 속성을 UnobtrusiveValidationMode.WebForms (일반적으로 Global.asax 파일의 Application_Start 메서드)로 설정하여 전역적으로 설정합니다.
Page 클래스의 새 UnobtrusiveValidationMode 속성을 UnobtrusiveValidationMode.WebForms 로 설정하여 페이지에 대해 개별적으로 지정 합니다.
HTML5 업데이트
HTML5의 새로운 기능을 활용하기 위해 서버 컨트롤을 Web Forms 몇 가지 개선 사항이 있습니다.
- TextBox 컨트롤의 TextMode 속성이 이메일, 날짜/시간 등과 같은 새로운 HTML5 입력 형식을 지원하도록 업데이트되었습니다.
- FileUpload 컨트롤은 이제 이 HTML5 기능을 지원하는 브라우저에서 여러 파일 업로드를 지원합니다.
- 유효성 검사기 컨트롤은 이제 HTML5 입력 요소의 유효성 검사를 지원합니다.
- URL을 나타내는 특성이 있는 새 HTML5 요소는 이제 runat="server"를 지원합니다. 따라서 ~ 연산자와 같은 URL 경로에서 ASP.NET 규칙을 사용하여 애플리케이션 루트를 나타낼 수 있습니다(예 <: video runat="server" src="~/myVideo.wmv" />).
- UpdatePanel 컨트롤은 HTML5 입력 필드 게시를 지원하도록 수정되었습니다.
ASP.NET MVC 4
이제 ASP.NET MVC 4 베타가 Visual Studio 11 베타에 포함됩니다. ASP.NET MVC는 MVC(Model-View-Controller) 패턴을 활용하여 테스트 가능하고 유지 관리가 가능한 웹 애플리케이션을 개발하기 위한 프레임워크입니다. ASP.NET MVC 4를 사용하면 모바일 웹용 애플리케이션을 쉽게 빌드할 수 있으며 모든 디바이스에 연결할 수 있는 HTTP 서비스를 빌드하는 데 도움이 되는 ASP.NET Web API 포함됩니다. 자세한 내용은 MVC 4 릴리스 정보 ASP.NET 참조하세요.
ASP.NET 웹 페이지 2
새로운 기능에는 다음이 포함되었습니다.
- 새 사이트 및 업데이트된 사이트 서식 파일.
- 유효성 검사 도우미를 사용하여 서버 쪽 및 클라이언트 쪽 유효성 검사를 추가합니다.
- 자산 관리자를 사용하여 스크립트를 등록하는 기능입니다.
- OAuth 및 OpenID를 사용하여 Facebook 및 기타 사이트에서 로그인을 사용하도록 설정합니다.
- 지도 도우미를 사용하여 맵 추가
- 웹 페이지 애플리케이션을 나란히 실행합니다.
- 모바일 디바이스에 대한 렌더링 페이지입니다.
이러한 기능 및 전체 페이지 코드 예제에 대한 자세한 내용은 웹 페이지 2 베타의 주요 기능을 참조하세요.
Visual Web Developer 11 베타
이 섹션에서는 Visual Web Developer 11 Beta 및 Visual Studio 2012 릴리스 후보의 웹 개발 개선 사항에 대한 정보를 제공합니다.
Visual Studio 2010과 Visual Studio 2012 릴리스 후보 간 프로젝트 공유(프로젝트 호환성)
Visual Studio 2012 릴리스 후보까지 최신 버전의 Visual Studio에서 기존 프로젝트를 열고 변환 마법사를 시작했습니다. 이로 인해 프로젝트 및 솔루션의 콘텐츠(자산)를 이전 버전과 호환되지 않는 새 형식으로 업그레이드해야 했습니다. 따라서 변환 후에 이전 버전의 Visual Studio에서 프로젝트를 열 수 없습니다.
많은 고객이 이것이 올바른 접근 방식이 아니라고 말했습니다. Visual Studio 11 베타에서는 이제 Visual Studio 2010 SP1과 프로젝트 및 솔루션 공유를 지원합니다. 즉, Visual Studio 2012 릴리스 후보에서 2010 프로젝트를 여는 경우에도 Visual Studio 2010 SP1에서 프로젝트를 열 수 있습니다.
참고
Visual Studio 2010 SP1과 Visual Studio 2012 릴리스 후보 간에는 몇 가지 유형의 프로젝트를 공유할 수 없습니다. 여기에는 일부 이전 프로젝트(예: ASP.NET MVC 2 프로젝트) 또는 특수 목적의 프로젝트(예: 설치 프로젝트)가 포함됩니다.
Visual Studio 11 베타에서 처음으로 Visual Studio 2010 SP1 웹 프로젝트를 열면 프로젝트 파일에 다음 속성이 추가됩니다.
- FileUpgradeFlags
- UpgradeBackupLocation
- OldToolsVersion
- VisualStudioVersion
- VSToolsPath
FileUpgradeFlags, UpgradeBackupLocation 및 OldToolsVersion은 프로젝트 파일을 업그레이드하는 프로세스에서 사용됩니다. Visual Studio 2010에서 프로젝트 작업에 영향을 주지 않습니다.
VisualStudioVersion은 현재 프로젝트의 Visual Studio 버전을 나타내는 MSBuild 4.5에서 사용하는 새 속성입니다. 이 속성은 MSBuild 4.0(Visual Studio 2010 SP1에서 사용하는 MSBuild 버전)에 존재하지 않았기 때문에 프로젝트 파일에 기본값을 삽입합니다.
VSToolsPath 속성은 MSBuildExtensionsPath32 설정으로 표시되는 경로에서 가져올 올바른 .targets 파일을 결정하는 데 사용됩니다.
가져오기 요소와 관련된 몇 가지 변경 내용도 있습니다. 이러한 변경 내용은 두 버전의 Visual Studio 간의 호환성을 지원하기 위해 필요합니다.
참고
프로젝트가 서로 다른 두 컴퓨터의 Visual Studio 2010 SP1과 Visual Studio 11 베타 간에 공유되고 App_Data 폴더에 로컬 데이터베이스가 포함된 경우 데이터베이스에서 사용하는 SQL Server 버전이 두 컴퓨터에 모두 설치되어 있는지 확인해야 합니다.
ASP.NET 4.5 웹 사이트 템플릿의 구성 변경 내용
Visual Studio 2012 릴리스 후보에서 웹 사이트 템플릿을 사용하여 만든 사이트의 기본 Web.config 파일이 다음과 같이 변경되었습니다.
- 요소
encoderType에서<httpRuntime>특성은 이제 기본적으로 ASP.NET 추가된 AntiXSS 형식을 사용하도록 설정됩니다. 자세한 내용은 AntiXSS 라이브러리를 참조하세요. - 또한 요소
requestValidationMode에서<httpRuntime>특성은 "4.5"로 설정됩니다. 즉, 기본적으로 요청 유효성 검사는 지연된("지연") 유효성 검사를 사용하도록 구성됩니다. 자세한 내용은 새 ASP.NET 요청 유효성 검사 기능을 참조하세요. <modules>섹션의 요소에<system.webServer>특성이runAllManagedModulesForAllRequests없습니다. (기본값은 false입니다.) 즉, SP1로 업데이트되지 않은 IIS 7 버전을 사용하는 경우 새 사이트의 라우팅에 문제가 있을 수 있습니다. 자세한 내용은 ASP.NET 라우팅에 대한 IIS 7의 네이티브 지원을 참조하세요.
이러한 변경 내용은 기존 애플리케이션에 영향을 미치지 않습니다. 그러나 새 템플릿을 사용하여 ASP.NET 4.5용으로 만든 기존 웹 사이트와 새 웹 사이트 간의 동작 차이를 나타낼 수 있습니다.
ASP.NET 라우팅을 위한 IIS 7의 네이티브 지원
이는 ASP.NET 변경된 것이 아니라 SP1 업데이트가 적용되지 않은 IIS 7 버전을 작업하는 경우 영향을 줄 수 있는 새 웹 사이트 프로젝트에 대한 템플릿의 변경입니다.
ASP.NET 라우팅을 지원하기 위해 애플리케이션에 다음 구성 설정을 추가할 수 있습니다.
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<!-- more -->
</modules>
</system.webServer>
</configuration>
runAllManagedModulesForAllRequests가 true이면 URL에 .aspx, .mvc 또는 유사한 확장이 없더라도 와 같은 http://mysite/myapp/home URL이 ASP.NET 이동합니다.
IIS 7에 대한 업데이트는 runAllManagedModulesForAllRequests 설정을 불필요하게 만들고 기본적으로 ASP.NET 라우팅을 지원합니다. (업데이트에 대한 자세한 내용은 Microsoft 지원 문서를 참조하세요. 특정 IIS 7.0 또는 IIS 7.5 처리기가 URL이 마침표로 끝나지 않는 요청을 처리할 수 있도록 하는 업데이트를 사용할 수 있습니다.)
웹 사이트가 IIS 7에서 실행 중이고 IIS가 업데이트된 경우 runAllManagedModulesForAllRequests 를 true로 설정할 필요가 없습니다. 실제로 요청에 불필요한 처리 오버헤드를 추가하므로 true로 설정하는 것은 권장되지 않습니다. 이 설정이 true이면 .htm, .jpg및 기타 정적 파일에 대한 요청을 포함한 모든 요청도 ASP.NET 요청 파이프라인을 통과합니다.
Visual Studio 2012 RC에서 제공되는 템플릿을 사용하여 새 ASP.NET 4.5 웹 사이트를 만드는 경우 웹 사이트의 구성에는 runAllManagedModulesForAllRequests 설정이 포함되지 않습니다. 즉, 기본적으로 설정은 false입니다.
그런 다음 SP1을 설치하지 않고 Windows 7에서 웹 사이트를 실행하는 경우 IIS 7에는 필요한 업데이트가 포함되지 않습니다. 결과적으로 라우팅이 작동하지 않으며 오류가 표시됩니다. 라우팅이 작동하지 않는 문제가 있는 경우 다음 중 하나를 수행할 수 있습니다.
- WINDOWS 7을 SP1로 업데이트합니다. 그러면 IIS 7에 업데이트가 추가됩니다.
- 이전에 나열된 Microsoft 지원 문서에 설명된 업데이트를 설치합니다.
- 해당 웹 사이트의 Web.config 파일에서 runAllManagedModulesForAllRequests 를 true로 설정합니다. 이렇게 하면 요청에 약간의 오버헤드가 추가됩니다.
HTML 편집기
스마트 작업
디자인 보기에서 서버 컨트롤의 복잡한 속성에는 쉽게 설정할 수 있도록 연결된 대화 상자와 마법사가 있는 경우가 많습니다. 예를 들어 특수 대화 상자를 사용하여 데이터 원본을 반복기 컨트롤에 추가하거나 GridView 컨트롤에 열을 추가할 수 있습니다.
그러나 복잡한 속성에 대한 이러한 유형의 UI 도움말은 원본 뷰에서 사용할 수 없습니다. 따라서 Visual Studio 11에는 원본용 스마트 작업 보기가 도입되었습니다. 스마트 작업은 C# 및 Visual Basic 편집기에서 일반적으로 사용되는 기능에 대한 컨텍스트 인식 바로 가기입니다.
ASP.NET Web Forms 컨트롤의 경우 삽입 지점이 요소 내에 있을 때 스마트 태스크가 서버 태그에 작은 문자 모양으로 표시됩니다.
문자 모양을 클릭하거나 Ctrl+를 누르면 스마트 태스크가 확장됩니다. 코드 편집기에서와 마찬가지로 (dot) 그런 다음 디자인 보기의 스마트 작업과 유사한 바로 가기를 표시합니다.
예를 들어 이전 그림의 스마트 태스크는 GridView 작업 옵션을 보여 줍니다. 열 편집을 선택하면 다음 대화 상자가 표시됩니다.
대화 상자를 입력하면 디자인 보기에서 설정할 수 있는 것과 동일한 속성이 설정됩니다. 확인을 클릭하면 컨트롤에 대한 태그가 새 설정으로 업데이트됩니다.
WAI-ARIA 지원
접근성 있는 웹 사이트 작성이 점점 더 중요해지고 있습니다. WAI-ARIA 접근성 표준은 개발자가 액세스 가능한 웹 사이트를 작성하는 방법을 정의합니다. 이 표준은 이제 Visual Studio에서 완전히 지원됩니다.
예를 들어 역할 특성에는 이제 전체 IntelliSense가 있습니다.
WAI-ARIA 표준에는 HTML5 문서에 의미 체계를 추가할 수 있는 aria 접 두사 특성도 도입되었습니다. 또한 Visual Studio는 다음과 같은 aria- 특성을 완벽하게 지원합니다.
새 HTML5 코드 조각
일반적으로 사용되는 HTML5 태그를 더 빠르고 쉽게 작성할 수 있도록 Visual Studio에는 여러 코드 조각이 포함되어 있습니다. 예를 들어 비디오 코드 조각이 있습니다.
코드 조각을 호출하려면 IntelliSense에서 요소를 선택할 때 Tab 키를 두 번 누릅니다.
이렇게 하면 사용자 지정할 수 있는 코드 조각이 생성됩니다.
사용자 컨트롤에 추출
큰 웹 페이지에서 개별 조각을 사용자 컨트롤로 이동하는 것이 좋습니다. 이 형태의 리팩터링은 페이지의 가독성을 높이는 데 도움이 되며 페이지 구조를 간소화할 수 있습니다.
이 작업을 더 쉽게 수행하려면 원본 보기에서 Web Forms 페이지를 편집할 때 페이지의 텍스트를 선택하고 마우스 오른쪽 단추로 클릭한 다음 사용자 컨트롤로 추출을 선택할 수 있습니다.
특성의 코드 너겟에 대한 IntelliSense
Visual Studio는 항상 모든 페이지 또는 컨트롤에서 서버 쪽 코드 너겟에 대한 IntelliSense를 제공했습니다. 이제 Visual Studio에는 HTML 특성의 코드 너겟에 대한 IntelliSense도 포함되어 있습니다.
이렇게 하면 데이터 바인딩 식을 더 쉽게 만들 수 있습니다.
여는 태그 또는 닫는 태그의 이름을 바꿀 때 일치하는 태그의 자동 이름 바꾸기
HTML 요소의 이름을 바꾸는 경우(예: div 태그를 헤더 태그로 변경) 해당 여는 태그 또는 닫는 태그도 실시간으로 변경됩니다.
이렇게 하면 닫는 태그를 변경하거나 잘못된 태그를 변경하는 것을 잊어버린 오류를 방지할 수 있습니다.
이벤트 처리기 생성
이제 Visual Studio에는 이벤트 처리기를 작성하고 수동으로 바인딩하는 데 도움이 되는 기능이 원본 보기에 포함되어 있습니다. 원본 보기에서 이벤트 이름을 편집하는 경우 IntelliSense는 새 이벤트> 만들기를 표시<합니다. 그러면 페이지 코드에 올바른 서명이 있는 이벤트 처리기가 만들어집니다.
기본적으로 이벤트 처리기는 이벤트 처리 메서드의 이름에 컨트롤의 ID를 사용합니다.
결과 이벤트 처리기는 다음과 같습니다(이 경우 C#).
스마트 들여쓰기
빈 HTML 요소 내에 있는 동안 Enter 키를 누르면 편집기에서 삽입 지점을 올바른 위치에 배치합니다.
이 위치에서 Enter 키를 누르면 닫는 태그가 아래로 이동하고 여는 태그와 일치하도록 들여쓰기됩니다. 삽입 지점도 들여쓰기됩니다.
자동 감소 문 완성
이제 Visual Studio의 IntelliSense 목록은 사용자가 입력한 항목에 따라 필터링되므로 관련 옵션만 표시합니다.
IntelliSense는 IntelliSense 목록에 있는 개별 단어의 제목 대/소문자를 기준으로 필터링합니다. 예를 들어 "dl"을 입력하면 dl 및 asp:DataList가 모두 표시됩니다.
이 기능을 사용하면 알려진 요소에 대한 문 완성을 더 빠르게 얻을 수 있습니다.
JavaScript 편집기
Visual Studio 2012 릴리스 후보의 JavaScript 편집기는 완전히 새로운 기능이며 Visual Studio에서 JavaScript를 사용하는 환경을 크게 향상시킵니다.
코드 개요
이제 모든 함수에 대해 개요 영역이 자동으로 만들어져 현재 포커스와 관련이 없는 파일의 일부를 축소할 수 있습니다.
중괄호 일치
삽입 지점을 여는 중괄호 또는 닫는 중괄호에 놓으면 편집기에서 일치하는 중괄호를 강조 표시합니다.
정의로 이동
정의로 이동 명령을 사용하면 함수 또는 변수의 원본으로 이동할 수 있습니다.
ECMAScript5 지원
편집기는 JavaScript 언어를 설명하는 최신 버전의 표준인 ECMAScript5의 새 구문 및 API를 지원합니다.
DOM IntelliSense
querySelector, DOM Storage, 문서 간 메시징 및 캔버스를 비롯한 많은 새로운 HTML5 API를 지원하여 DOM API용 IntelliSense가 개선되었습니다. 이제 DOM IntelliSense는 네이티브 형식 라이브러리 정의가 아닌 단일 간단한 JavaScript 파일에 의해 구동됩니다. 이렇게 하면 쉽게 확장하거나 바꿀 수 있습니다.
VSDOC 서명 오버로드
이제 이 예제와 같이 새 <서명> 요소를 사용하여 JavaScript 함수의 별도 오버로드에 대해 자세한 IntelliSense 주석을 선언할 수 있습니다.
function GetOrSet(key, value) {
/// <signature>
/// <summary>Gets the value</summary>
/// <param name="key" type="String">The key to get the value for</param>
/// <returns type="String" />
/// </signature>
/// <signature>
/// <summary>Sets the value</summary>
/// <param name="key" type="String">The key to set the value for</param>
/// <param name="value" type="String">The value to set</param>
/// <returns type="MyLib" />
/// </signature>
if (value) {
values[key] = value;
return this;
} else {
return values[key];
}
}
암시적 참조
이제 지정된 JavaScript 파일 또는 블록 참조가 있는 파일 목록에 암시적으로 포함되는 중앙 목록에 JavaScript 파일을 추가할 수 있습니다. 즉, 해당 내용에 대한 IntelliSense가 제공됩니다. 예를 들어 jQuery 파일을 파일의 중앙 목록에 추가할 수 있으며, 명시적으로 참조했는지(/// <참조 />) 여부에 관계없이 jQuery 함수에 대한 IntelliSense를 파일의 JavaScript 블록에 가져옵니다.
CSS 편집기
자동 감소 문 완성
이제 CSS에 대한 IntelliSense 목록은 선택한 스키마에서 지원하는 CSS 속성 및 값을 기반으로 필터링합니다.
IntelliSense는 타이틀 사례 검색도 지원합니다.
계층적 들여쓰기
CSS 편집기는 들여쓰기를 사용하여 계층적 규칙을 표시합니다. 그러면 계단식 규칙이 논리적으로 어떻게 구성되는지에 대한 개요가 제공됩니다. 다음 예제에서 선택기 #list 목록의 연속 자식이므로 들여쓰기됩니다.
다음 예제에서는 더 복잡한 상속을 보여줍니다.
규칙 들여쓰기는 부모 규칙에 의해 결정됩니다. 계층적 들여쓰기는 기본적으로 사용하도록 설정되어 있지만 옵션 대화 상자(도구, 메뉴 모음의 옵션)를 사용하지 않도록 설정할 수 있습니다.
CSS 해킹 지원
수백 개의 실제 CSS 파일을 분석하면 CSS 해킹이 매우 일반적이며 이제 Visual Studio에서 가장 널리 사용되는 파일을 지원합니다. 이 지원에는 IntelliSense 및 star(*) 및 밑줄(_) 속성 해킹의 유효성 검사가 포함됩니다.
일반적인 선택기 해킹도 지원되므로 계층적 들여쓰기가 적용된 경우에도 유지됩니다. 인터넷 Explorer 7을 대상으로 하는 데 사용되는 일반적인 선택기 해킹은 선택기 앞에 *:first-child + html을 추가하는 것입니다. 이 규칙을 사용하면 계층적 들여쓰기가 유지됩니다.
공급업체별 스키마(-moz-, -webkit)
CSS3에는 서로 다른 시간에 다른 브라우저에서 구현된 많은 속성이 도입되었습니다. 이전에는 개발자가 공급업체별 구문을 사용하여 특정 브라우저에 대한 코드를 작성해야 했습니다. 이러한 브라우저 관련 속성은 이제 IntelliSense에 포함됩니다.
주석 처리 및 주석 처리 지원
이제 코드 편집기에서 사용하는 것과 동일한 바로 가기를 사용하여 CSS 규칙을 주석 처리하고 주석 처리 해제할 수 있습니다(Ctrl+K, 주석으로는 C, 주석 처리는 Ctrl+K, 주석 처리는 제거).
색 선택기
이전 버전의 Visual Studio에서 색 관련 특성에 대한 IntelliSense는 명명된 색 값의 드롭다운 목록으로 구성되었습니다. 해당 목록은 모든 기능을 갖춘 색 선택기로 대체되었습니다.
색 값을 입력하면 색 선택기가 자동으로 표시되고 이전에 사용한 색 목록과 기본 색상표가 표시됩니다. 마우스 또는 키보드를 사용하여 색을 선택할 수 있습니다.
목록을 전체 색 선택으로 확장할 수 있습니다. 선택기를 사용하면 불투명도 슬라이더를 이동할 때 모든 색을 RGBA로 자동으로 변환하여 알파 채널을 제어할 수 있습니다.
코드 조각
CSS 편집기에서 코드 조각을 사용하면 브라우저 간 스타일을 더 쉽고 빠르게 만들 수 있습니다. 브라우저별 설정이 필요한 많은 CSS3 속성이 이제 코드 조각으로 롤백되었습니다.
CSS 코드 조각은 IntelliSense 목록을 표시하는 기호(@)를 입력하여 고급 시나리오(예: CSS3 미디어 쿼리)를 지원합니다.
값을 선택하고 @media Tab 키를 누르면 CSS 편집기에서 다음 코드 조각을 삽입합니다.
코드 조각과 마찬가지로 고유한 CSS 코드 조각을 만들 수 있습니다.
사용자 지정 지역
코드 편집기에서 이미 사용할 수 있는 명명된 코드 영역은 이제 CSS 편집에 사용할 수 있습니다. 이렇게 하면 관련 스타일 블록을 쉽게 그룹화할 수 있습니다.
영역이 축소되면 영역 이름이 표시됩니다.
페이지 검사기
페이지 검사기 Visual Studio IDE에서 웹 페이지(HTML, Web Forms, ASP.NET MVC 또는 웹 페이지)를 렌더링하고 소스 코드와 결과 출력을 모두 검사할 수 있는 도구입니다. ASP.NET 페이지의 경우 페이지 검사기 브라우저에 렌더링되는 HTML 태그를 생성한 서버 쪽 코드를 확인할 수 있습니다.
페이지 검사기 대한 자세한 내용은 다음 자습서를 참조하세요.
- ASP.NET MVC에서 페이지 검사기 사용
- ASP.NET Web Forms 페이지 검사기 사용
게시
게시 프로필
Visual Studio 2010에서 웹 애플리케이션 프로젝트에 대한 게시 정보는 버전 제어에 저장되지 않으며 다른 사용자와 공유하도록 설계되지 않았습니다. Visual Studio 2012 릴리스 후보에서 게시 프로필의 형식이 변경되었습니다. 팀 아티팩트가 만들어졌으며 이제 MSBuild 기반 빌드에서 쉽게 활용할 수 있습니다. 빌드 구성 정보는 게시 대화 상자에 있으므로 게시하기 전에 빌드 구성을 쉽게 전환할 수 있습니다.
게시 프로필은 PublishProfiles 폴더에 저장됩니다. 폴더의 위치는 사용 중인 프로그래밍 언어에 따라 달라집니다.
- C#: Properties\PublishProfiles
- Visual Basic: My Project\PublishProfiles
각 프로필은 MSBuild 파일입니다. 게시하는 동안 이 파일을 프로젝트의 MSBuild 파일로 가져옵니다. Visual Studio 2010에서 게시 또는 패키지 프로세스를 변경하려면 ProjectName.wpp.targets라는 파일에 사용자 지정을 배치해야 합니다. 여전히 지원되지만 이제 게시 프로필 자체에 사용자 지정을 넣을 수 있습니다. 이렇게 하면 사용자 지정이 해당 프로필에만 사용됩니다.
이제 MSBuild에서 게시 프로필을 활용할 수도 있습니다. 이렇게 하려면 프로젝트를 빌드할 때 다음 명령을 사용합니다.
msbuild.exe project.csproj /t:WebPublish /p:PublishProfile=ProfileName
project.csproj 값은 프로젝트의 경로이고 ProfileName은 게시할 프로필의 이름입니다. 또는 PublishProfile 속성의 프로필 이름을 전달하는 대신 게시 프로필의 전체 경로를 전달할 수 있습니다.
ASP.NET 사전 컴파일 및 병합
웹 애플리케이션 프로젝트의 경우 Visual Studio 2012 릴리스 후보는 프로젝트를 게시하거나 패키지할 때 사이트의 콘텐츠를 미리 컴파일하고 병합할 수 있는 웹 속성 패키지/게시 페이지에 옵션을 추가합니다. 이러한 옵션을 보려면 솔루션 탐색기 프로젝트를 마우스 오른쪽 단추로 클릭하고 속성을 선택한 다음 패키지/웹 게시 속성 페이지를 선택합니다. 다음 그림에서는 게시하기 전에 이 애플리케이션을 미리 컴파일하는 옵션을 보여 줍니다.
이 옵션을 선택하면 Visual Studio는 웹 애플리케이션을 게시하거나 패키지할 때마다 애플리케이션을 미리 컴파일합니다. 사이트를 미리 컴파일하는 방법 또는 어셈블리를 병합하는 방법을 제어하려면 고급 단추를 클릭하여 해당 옵션을 구성합니다.
IIS Express
이제 Visual Studio에서 웹 프로젝트를 테스트하기 위한 기본 웹 서버가 IIS Express. Visual Studio 개발 서버는 개발 중에 로컬 웹 서버에 대한 옵션이지만 IIS Express 이제 권장되는 서버입니다. Visual Studio 11 베타에서 IIS Express 사용하는 환경은 Visual Studio 2010 SP1에서 사용하는 것과 매우 유사합니다.
고지 사항
본 문서는 예비 문서이며, 여기에 설명한 소프트웨어의 최종 상업적 출시 전에 크게 변경될 수 있습니다.
이 문서에 포함된 정보는 게시 날짜 당시 논의된 문제에 대한 Microsoft Corporation의 현재 관점을 나타냅니다. Microsoft는 변화하는 시장 상황에 대응해야 하므로 Microsoft의 약속으로 해석되지 않아야 하며, Microsoft는 게시 날짜 이후 제시된 정보의 정확성을 보증하지 않습니다.
이 백서는 정보 제공만을 목적으로 합니다. Microsoft는 이 문서에 있는 정보에 대한 명시적 또는 묵시적, 법적인 보증을 하지 않습니다.
해당 저작권법을 준수하는 것은 사용자의 책임입니다. 저작권에서의 권리와는 별도로 이 설명서의 어떠한 부분도 Microsoft의 명시적인 서면 승인 없이는 어떠한 형식이나 수단(전기적, 기계적, 복사기에 의한 복사, 디스크 복사 또는 다른 방법) 또는 목적으로도 복제되거나 검색 시스템에 저장 또는 도입되거나 전송될 수 없습니다.
Microsoft는 이 설명서 본안에 관련된 특허권, 상표권, 저작권, 또는 기타 지적 재산권 등을 보유할 수도 있습니다. 서면 사용권 계약에 따라 Microsoft로부터 귀하에게 명시적으로 제공된 권리 이외에, 이 설명서의 제공은 귀하에게 이러한 특허권, 상표권, 저작권 또는 기타 지적 재산권 등에 대한 어떠한 사용권도 허용하지 않습니다.
달리 명시되지 않는 한, 예제 회사, 조직, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 및 이벤트는 가상이며 실제 회사, organization, 제품, 도메인 이름, 전자 메일 주소, 로고, 사람, 장소 또는 이벤트와의 연관이 없거나 유추되어야 합니다.
© 2012 Microsoft Corporation. All rights reserved.
Microsoft 및 Windows는 미국 및/또는 기타 국가에서 Microsoft Corporation의 상표이거나 등록된 상표입니다.
여기에 언급된 실제 회사와 제품의 이름은 각각 해당 소유자의 상표일 수 있습니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기