ClientProfile? 

.Net Framework를 이용한 어플리케이션 배포시 문제가 되는 .Net Framework 설치를 쉽게 하고자 MS에서 .Net 3.5 SP1부터 도입한것으로 클라이언트 프로그램에서 필요한 부분만을 자동으로 다운로드 및 설치를 해준다.

문제는 .net framework 4.0client profile 프로젝트는 .Net 2.0으로 만들어진 동적라이브러리를 인식하는데 문제가 발생한다.

따라서 참조 추가 후 log4net 을 사용하려해도 인식하지 못하고 아래와 같은 오류가 발생한다.

The type or namespace name ‘log4net’ could not be found (are you missing a using directive or an assembly reference?)

이런 상황에서는, target framework을 .Net framework 4.0으로 변경하면 해결..!

참조 싸이트 

http://msdn.microsoft.com/en-us/library/cc656912(VS.100).aspx

http://blog.naver.com/saltynut?Redirect=Log&logNo=120068738007

Classic pipeline mode is the standard processing mode used with IIS6.0.

If a managed web application runs in an application pool with classic mode, IIS processes the requests in an application pool by using separate processing pipelines for IIS and ISAPI.

This means that requests for ASP.NET applications are processed in mulitple stages like this :

  1 The incoming HTTP request is received through the IIS core.

  2 The request is processed through ISAPI

  3 The request is processed through ASP.NET

  4 The request passes back through ISAPI

  5 The request passes back through the IIS core where the HTTP response finally is delivered.

Intergrated pipeline mode is a dynamic processing mode that can be used with IIS7.0

If a managed Web application runs in an application pool with integrated mode, IIS processes the request in an application pool by using an intergrated processing pipeline for IIS and ASP.NET

This means that requests for ASP.NET applications are processed directly like this :

  1 The incoming HTTP request is received through the IIS core and ASP.NET

  2 The appropriate handler execeutes the request and delivers the HTTP response.

Form an administrator perspective, applications running in classic pipeline mode can appear to be less responsive than their integrated counterparts.

From an application developer perspective, classic pipeline mode has two key limitations.

First, services provided by ASP.NET modules and applications are not available to non-ASP.NET requests

Second, ASP.NETmodules are unable to affect certain parts of IIS request processing that occurred before and after the ASP.NET execution path.

With an integrated pipeline, all native IIS modules an managed modules can process incomming requests at any stage. 

This enables services provided by managed modules to be used for requests to pages created using static content, ASP.NET, PHP, and more.

Direct integration makes it possible for developers to write custom authentication modules, to create modules that modify request headers before other components process the request, and more.

When woring with the integrated pipeline mode, it is important to keep in mind that in this mode ASP.NET does not rely on the ISAPI or ISAPI Extension modules.

Because of this, the running of an integrated ASP.NET application is not affected by the ISAPI CGI restriction list.

The ISAPI CGI restriction list applies only to ISAPI and CGI applications(which includes ASP.NET classic applications).

For integrated mode to work properly, you must specify handler mappings for all custom file types.

Further, many applications written for classic pipeline mode will need to be migrated to run properly in integrated pipeline mode.

The good news is that the Configuration Validation module, included as a part of the server core, can automatically detect an application that requires migration and return an error message starting that the application must be migrated.

You can migrate application by using Appcmd.exe(general-purpose IIS command -line administration tool)

Any migration error reported by IIS typically contains the necessary command for migrating the application.

To use this command to migrate an application automatically, right-click the command-prompticon and choose Run As Administrator.

You then can migrate an application manually, by running the following command at the elevated cmmmand pompt.

 appcmd migrate config AppPath

where AppPath is the virtual path of the application .

The virtual path contains the name of the associated Web site and applications.

For example, if an application named SalesApp was Configured on the Defulat Web Site and needed to be migrated,

you could do this by running the following command

 appcmd migrate config ""efault Web Site/SalesApp"

When AppCmd finishes migrating the application, the application will run in both classic and integrated modes

원문 : http://blog.naver.com/kbk9879?Redirect=Log&logNo=120137136990

엑셀을 업로드할때 숫자와 문자를 병행하여 입력할때가 종종있다.

이번에 회사에서 일을 하다가 평소에 숫자값으로 들어가다가 갑자기 문자값도 들어갈 수 있다고

하여 별생각이 없었는데..

업로드할때 문자값이 나오지 않은 것이다..ㄷㄷㄷ

구글링을 통해 확인결과..

ODBC에서 엑셀내용을 저장할때 1~8번째 행을 확인하여 그 FIELD값이 전부 숫자일경우 8번째 행

이후의 값이 문자이면 모두 NULL값으로 처리가 된단다..ㄷㄷㄷ

결국 해결책을 찾을려고 다시 구글링을 하였는데 다들 IMEX=1 이렇게 하면 된다고 한다..

하지만 난 이미 적용시켰는데도 불구하고 되지 않고 있으니..

나의 ODBC connect부분이다.

string strProvider = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" + strFilePath + "; Extended Properties=\"Excel 8.0;HDR=yes;IMEX=1\"";

oleDBCon = new OleDbConnection(strProvider);

......이로써 구글링으로 해결책을 찾는데 3시간이나 보냈다가..

어느 PDF로 찾은 결과..레지스트리에 있는 TypeGuessRows의 값을 수정하면 된다는 글을

보게 되었다..

TypeGuessRows의 default값이 8로 되어 있는 것을 확인할 수 있는데..

이 값으로 ImportMixedTypes에 정의되어진 type으로 정해진단다..

결국 TypeGuessRows의 값을 늘리고 다시 업로드를 해보니 잘된다..

TypeGuessRows의 값을 늘릴때의 부작용에 대해서는 아직 확인을 못하고 있어서..우선

이렇게 적용시켜놓고 추후에 문제가 발생하면 확인해봐야겠다..ㅠㅠ

[해당 레지스트리가 존재하는 위치]

WINDOWS XP

HKEY-LOCAL-MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel

WINDOWS SERVER 2008(64비트)

HKEY-LOCAL-MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Excel

원문 : http://www.aspnet-video.com/ASPNetVideo/documentation/tutorials/?help=ASPNetVideo_Tutorial_HTML_Alternative

How To Add HTML Alternative Content

ASPNetVideo generates your HTML Alternative directly in your ASPX Webform. It allows you to render other WebControls and components within your HTML Alternative, as you would within an ASP.NET Panel object.

In all instances, the ASPNetVideo WebControl renders HTML Alternative Content beside the video markup.  If the user's browser is capable of displaying the video content, the video is displayed over the alternative content on the web page.  This technique is beneficial because:

• It provides a viable alternative for website users with no appropriate Video Plugin.
• It gives alternative content for accessibility.
• It provides extra content which search engines can read and spider.

1.  Key Concepts

The HTML Alternative content is always rendered.  It is placed within an HTML element, whose ID attribute matches that of the ASPNetVideo WebControl instance. Where the video plugin is available to the user - The video object is written over this content.

The HTML alternative is set using either the smart tags in the designer view, or by hand in the code view (see below).

To test and debug your HTML alternative - you can set the component's Enabledproperty to false.  This will render only the HTML alternative and not the Video content.

2.  Set HTML Alternative Content using the Designer

If you wish to edit your HTML Alternative using the designer, click on the Smart Tagbutton (looks like a play button on the top right corner of the control).  You should see something similar to the following:

Then, click on "Edit Templates" and the following should appear:

At this point, you can drag and drop or type content directly into this content window, as shown here:

3.  Set HTML Alternative Content using Source Code

If you wish to add your HTML Alternative content using ASPX source code, go to the code view.  First, add a set of "HTMLAlternativeTemplate" tags within your ASPNetVideo tags.  Then place your alternative content within these new tags, as shown below:

원문  : http://osskorea.tistory.com/133

http://tuvianblog.com/2011/07/07/how-to-create-thumbnail-image-in-asp-netc-or-resize-the-image-before-upload-in-asp-netc/

How to create thumbnail image in ASP.Net/C# OR resize the image before upload in ASP.Net/C#

How to reduce the size of image before uploaded to the server in ASP.Net/C#

 <asp:Panel runat="server">
<asp:FileUpload ID="fileupload1" runat="server" />
<asp:Button ID="btnsave" runat="server" Text="Upload" OnClick="btnsave_Click" />
</div>
<div>
<asp:DataList ID="dtlist" runat="server" RepeatColumns="3" CellPadding="5">
<ItemTemplate>
<asp:Image ID="Image1" ImageUrl='<%# Bind("Name", "~/Images1/{0}") %>' runat="server" />
<br />
<asp:HyperLink ID="HyperLink1" Text='<%# Bind("Name") %>'
NavigateUrl='<%# Bind("Name", "~/Images1/{0}") %>'
runat="server" />
</ItemTemplate>
<ItemStyle BorderColor="Brown" BorderStyle="dotted" BorderWidth="3px"
HorizontalAlign="Center"
VerticalAlign="Bottom" />
</asp:DataList>
</asp:Panel>

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
BindDataList();
}
}
protected void BindDataList()
{
DirectoryInfo dir = new DirectoryInfo(MapPath("Images1"));
FileInfo[] files = dir.GetFiles();
ArrayList listItems = new ArrayList();
foreach (FileInfo info in files)
{
listItems.Add(info);
}
dtlist.DataSource = listItems;
dtlist.DataBind();
}
protected void btnsave_Click(object sender, EventArgs e)
{
string filename = Path.GetFileName(fileupload1.PostedFile.FileName);
string targetPath = Server.MapPath("Images1/" + filename);
Stream strm = fileupload1.PostedFile.InputStream;
var targetFile = targetPath;
//Based on scalefactor image size will vary
GenerateThumbnails(0.5, strm, targetFile);
BindDataList();
}
private void GenerateThumbnails(double scaleFactor, Stream sourcePath,
string targetPath)
{
using (var image = Image.FromStream(sourcePath))
{
// can given width of image as we want
var newWidth = (int)(image.Width * scaleFactor); 
// can given height of image as we want
var newHeight = (int)(image.Height * scaleFactor);
var thumbnailImg = new Bitmap(newWidth, newHeight);
var thumbGraph = Graphics.FromImage(thumbnailImg);
thumbGraph.CompositingQuality = CompositingQuality.HighQuality;
thumbGraph.SmoothingMode = SmoothingMode.HighQuality;
thumbGraph.InterpolationMode = InterpolationMode.HighQualityBicubic;
var imageRectangle = new Rectangle(0, 0, newWidth, newHeight);
thumbGraph.DrawImage(image, imageRectangle);
thumbnailImg.Save(targetPath, image.RawFormat);
}           
}
 

원문 : http://msdn.microsoft.com/ko-kr/library/bb398986(d=printer).aspx

HTTP 처리기 및 HTTP 모듈 개요

ASP.NET HTTP 처리기는 ASP.NET 웹 응용 프로그램에 대해 이루어진 요청의 응답으로 실행되는 프로세스(일반적으로 "끝점"이라고 함)입니다. 가장 일반적인 처리기는 .aspx 파일을 처리하는 ASP.NET 페이지 처리기입니다. 사용자가 .aspx 파일을 요청하면 페이지에서 페이지 처리기를 통해 요청이 처리됩니다. 사용자 지정 출력을 브라우저로 렌더링하는 고유한 HTTP 처리기를 만들 수 있습니다.

HTTP 모듈은 응용 프로그램에 대한 모든 요청에 따라 호출되는 어셈블리입니다. HTTP 모듈은 ASP.NET 요청 파이프라인의 일부로 호출되며 요청의 사용 기간 동안 모든 이벤트에 액세스할 수 있습니다. 따라서 HTTP 모듈을 사용하면 들어오는 요청과 나가는 요청을 검사하고 요청에 따라 작업을 수행할 수 있습니다.

이 항목의 내용은 다음과 같습니다.

• 시나리오

• HTTP 처리기 및 HTTP 모듈 기능

• Background

• 코드 예제

• 클래스 참조

시나리오

---

사용자 지정 HTTP 처리기는 일반적으로 다음과 같이 사용합니다.

• RSS 피드   웹 사이트에 대한 RSS 피드를 만들려면 RSS 형식 XML을 내보내는 처리기를 만들 수 있습니다. 그런 다음 .rss 등의 파일 확장명을 사용자 지정 처리기에 바인딩할 수 있습니다. 사용자가 .rss로 끝나는 사이트를 요청하면 ASP.NET은 이 처리기를 호출하여 요청을 처리합니다.

• 이미지 서버   웹 응용 프로그램에서 다양한 크기의 이미지를 사용하려는 경우 사용자 지정 처리기를 작성하여 이미지 크기를 조정하고, 처리기 응답을 통해 사용자에게 보낼 수 있습니다.

HTTP 모듈은 일반적으로 다음과 같이 사용합니다.

• 보안   들어오는 요청을 검사할 수 있기 때문에 HTTP 모듈에서는 요청된 페이지, XML 웹 서비스 또는 처리기를 호출하기 전에 사용자 지정 인증이나 다른 보안 검사를 수행할 수 있습니다. 통합 모드에서 실행되는 IIS(인터넷 정보 서비스) 7.0의 경우에는 폼 인증을 응용 프로그램의 모든 콘텐츠 형식으로 확장할 수 있습니다.

• 통계와 로깅   HTTP 모듈은 모든 요청에서 호출되기 때문에 개별 페이지 대신 중앙 집중식 모듈에 요청 통계와 로그 정보를 수집할 수 있습니다.

• 사용자 지정 머리글 또는 바닥글   보내는 응답을 수정할 수 있기 때문에 사용자 지정 머리글 정보 같은 내용을 모든 페이지나 XML 웹 서비스 응답에 삽입할 수 있습니다.

맨 위로 이동

기능

---

HTTP 처리기 및 모듈 기능은 다음과 같습니다.

• IHttpHandler¹ 및 IHttpModule² 인터페이스는 처리기와 모듈을 개발하기 위한 시작점입니다.

• IHttpAsyncHandler³ 인터페이스는 비동기 처리기를 개발하기 위한 시작점입니다.

• 사용자 지정 처리기 및 모듈 소스 코드는 응용 프로그램의 App_Code 폴더에 배치하거나, 컴파일 후 응용 프로그램의 Bin 폴더에 배치할 수 있습니다.

• IIS 6.0용으로 개발된 처리기 및 모듈은 IIS 7.0에서도 거의 변경하지 않고 사용할 수 있습니다. 자세한 내용은 ASP.NET 응용 프로그램을 IIS 6.0에서 IIS 7.0으로 이동⁴을 참조하십시오.

• 모듈은 다양한 요청 파이프라인 알림을 구독할 수 있습니다. 모듈은 HttpApplication⁵ 개체 이벤트의 알림을 수신할 수 있습니다.

• IIS 7.0에서 요청 파이프라인은 웹 서버 요청 파이프라인과 통합됩니다. HTTP 모듈은 ASP.NET 요청뿐 아니라 웹 서버에 대한 모든 요청에 사용할 수 있습니다.

맨 위로 이동

Background

---

HTTP 처리기

ASP.NET HTTP 처리기는 ASP.NET 웹 응용 프로그램에 대해 이루어진 요청의 응답으로 실행되는 프로세스입니다. 가장 일반적인 처리기는 .aspx 파일을 처리하는 ASP.NET 페이지 처리기입니다. 사용자가 .aspx 파일을 요청하면 페이지 처리기를 통해 요청이 처리됩니다.

ASP.NET 페이지 처리기는 단일 형식의 처리기입니다. ASP.NET에는 .asmx 파일을 위한 웹 서비스 처리기와 같은 몇 가지 다른 기본 제공 처리기가 포함되어 있습니다.

ASP.NET의 기본 제공 HTTP 처리기

ASP.NET은 파일 확장명에 따라 HTTP 요청을 HTTP 처리기로 매핑합니다. 각 HTTP 처리기는 응용 프로그램 내에서 개별 HTTP URL 또는 URL 확장 그룹을 처리할 수 있습니다. ASP.NET에는 다음 표에 나열된 몇 가지 기본 제공 HTTP 처리기가 포함됩니다.

처리기	설명
ASP.NET 페이지 처리기(*.aspx)	모든 ASP.NET 페이지의 기본 HTTP 처리기
웹 서비스 처리기(*.asmx)	ASP.NET에서 .asmx 파일로 생성된 웹 서비스 페이지의 기본 HTTP 처리기
제네릭 웹 처리기(*.ashx)	@ WebHandler6 지시문이 포함되어 있고 UI가 없는 모든 웹 처리기에 대한 기본 HTTP 처리기
추적 처리기(trace.axd)	현재 페이지 추적 정보를 표시하는 처리기. 자세한 내용은 방법: 추적 뷰어로 ASP.NET 추적 정보 보기7를 참조하십시오.

사용자 지정 HTTP 처리기 만들기

사용자 지정 HTTP 처리기를 만들려면 IHttpHandler¹ 인터페이스를 구현하는 클래스를 만들어 동기 처리기를 만듭니다. 또한 IHttpAsyncHandler³를 구현하여 비동기 처리기를 만들 수도 있습니다. 두 처리기 인터페이스 모두 IsReusable⁸ 속성과 ProcessRequest⁹ 메서드를 구현해야 합니다. IsReusable⁸ 속성은IHttpHandlerFactory¹⁰ 개체(실제로 해당 처리기를 호출하는 개체)가 처리기를 풀에 집어넣어 성능 향상을 위해 다시 사용할 수 있는지 여부를 지정합니다.처리기를 풀링할 수 없으면 팩터리에서는 처리기가 필요할 때마다 새 처리기 인스턴스를 만들어야 합니다.

ProcessRequest⁹ 메서드는 개별 HTTP 요청을 처리합니다. 이 메서드에서는 처리기에 대한 출력을 생성하는 코드를 작성합니다.

HTTP 처리기는 응용 프로그램 컨텍스트에 액세스할 수 있습니다. 여기에는 요청하는 사용자의 ID(알고 있는 경우), 응용 프로그램의 상태 및 세션 정보가 포함됩니다. HTTP 처리기가 요청되면 ASP.NET은 적절한 처리기의 ProcessRequest⁹ 메서드를 호출합니다. 처리기의 ProcessRequest⁹ 메서드에 작성하는 코드에서 응답을 만들고, 요청하는 브라우저로 응답이 다시 보내집니다.

파일 확장명 매핑

클래스 파일을 HTTP 처리기로 만드는 경우 처리기는 IIS 및 ASP.NET에 이미 매핑되어 있는 모든 파일 확장명에 응답할 수 있습니다. 예를 들어 RSS 피드를 생성하기 위해 HTTP 처리기를 만드는 경우 처리기를 .rss 파일 확장명에 매핑할 수 있습니다. ASP.NET에서 사용자 지정 파일 확장명에 사용할 처리기를 인식하도록 하려면 IIS에서 해당 확장명을 ASP.NET에 매핑해야 합니다. 그런 다음 응용 프로그램에서 확장명을 사용자 지정 처리기에 매핑해야 합니다.

기본적으로 ASP.NET은 파일 확장명 .ashx를 HTTP 처리기에 매핑합니다. 클래스 파일에 @ WebHandler⁶ 지시문을 추가하는 경우 ASP.NET에서는 .ashx 파일 확장명을 기본 HTTP 처리기에 자동으로 매핑합니다. 이는 @ Page¹¹ 지시문이 사용될 때 ASP.NET에서 .aspx 파일 확장명을 ASP.NET 페이지 처리기에 매핑하는 방식과 비슷합니다. 따라서 파일 확장명이 .ashx인 HTTP 처리기 클래스를 만들면, 이 처리기는 IIS와 ASP.NET에 자동으로 등록됩니다.

처리기에 대한 사용자 지정 파일 확장명을 만드는 경우 해당 확장명을 IIS와 ASP.NET에 명시적으로 등록해야 합니다. .ashx 파일 확장명을 사용하지 않으면 처리기를 서로 다른 확장명 매핑에 다시 사용할 수 있는 이점이 있습니다. 예를 들어 한 응용 프로그램에서는 사용자 지정 처리기가 .rss로 끝나는 요청에 응답할 수 있고, 다른 응용 프로그램에서는 .feed로 끝나는 요청에 응답할 수 있습니다. 또 다른 예로, 동일한 응용 프로그램에서 처리기를 두 파일 확장명에 매핑하고 확장명에 따라 다르게 응답할 수도 있습니다.

처리기의 사용자 지정 파일 확장명을 등록하는 절차는 IIS 7.0과 이전 버전의 IIS에서 각각 다릅니다. 자세한 내용은 방법: HTTP 처리기 등록¹² 및 방법: IIS에서 HTTP 처리기 확장 구성¹³을 참조하십시오.

비동기 및 동기 HTTP 처리기

HTTP 처리기는 동기 또는 비동기일 수 있습니다. 동기 처리기는 호출되고 나면 해당 HTTP 요청의 처리를 완료할 때까지 반환되지 않습니다. 비동기 처리기는 사용자에게 응답을 보내는 것과는 별도로 프로세스를 실행합니다. 실행 시간이 긴 응용 프로그램 프로세스가 시작되었지만, 사용자가 서버로부터 응답을 받기 위해 프로세스가 완료될 때까지 기다릴 필요가 없는 경우에는 비동기 처리기가 유용합니다.

비동기 HTTP 처리기를 사용하면 원격 서버에 대한 메서드 호출 등과 같은 외부 프로세스를 시작할 수 있습니다. 처리기는 외부 프로세스가 완료되기를 기다리지 않고 계속 처리할 수 있습니다. 비동기 HTTP 처리기를 처리하는 동안 ASP.NET에서는 일반적으로 외부 프로세스에 사용될 스레드를 처리기가 외부 프로세스에서 콜백을 받을 때까지 스레드 풀에 다시 넣습니다. 이렇게 하면 제한된 개수의 스레드만 동시에 실행되므로 스레드 차단을 방지하고 성능을 향상시킬 수 있습니다. 외부 프로세스에 의존하는 동기 HTTP 처리기를 여러 사용자가 요청하는 경우, 많은 스레드가 차단되어 외부 프로세스가 끝날 때까지 기다리기 때문에 운영 체제의 스레드가 빨리 부족해질 수 있습니다.

비동기 처리기를 만드는 경우 IHttpAsyncHandler³ 인터페이스를 구현해야 합니다. 개별 HTTP 요청을 처리하는 비동기 호출을 시작하려면BeginProcessRequest¹⁴ 메서드도 구현해야 합니다. 또한 프로세스가 끝나면 EndProcessRequest¹⁵ 메서드를 구현하여 정리 코드를 실행해야 합니다.

사용자 지정 IHttpHandlerFactory 클래스

IHttpHandlerFactory¹⁰ 클래스는 요청을 수신하고 적합한 HTTP 처리기로 요청을 전달하는 역할을 담당합니다. IHttpHandlerFactory¹⁰ 인터페이스를 구현하는 클래스를 만들어 사용자 지정 HTTP 처리기 팩터리를 만들 수 있습니다. 사용자 지정 처리기 팩터리는 런타임 조건에 따라 다른 처리기를 만들어 HTTP 요청이 처리되는 방식을 좀 더 세밀하게 제어할 수 있습니다. 예를 들어, 사용자 지정 HTTP 처리기 팩터리를 사용하면 HTTP 요청 메서드가 PUT인 경우의 파일 형식에 대한 HTTP 처리기를 인스턴스화하고, 메서드가 GET인 경우의 파일 형식에 대한 또 다른 HTTP 처리기를 인스턴스화할 수 있습니다.

처리기 팩터리에 대해 사용자 지정 확장을 등록하려면 처리기에 대한 사용자 지정 확장 등록을 위한 단계를 따르십시오. 처리기 팩터리를 만들고 등록하는 방법에 대한 예제를 보려면 연습: HTTP 처리기 팩터리 만들기 및 등록¹⁶를 참조하십시오.

HTTP 모듈

HTTP 모듈은 응용 프로그램에 대한 모든 요청에 따라 호출되는 어셈블리입니다. HTTP 모듈은 요청 파이프라인의 일부로 호출되며 요청의 사용 기간 동안 모든 이벤트에 액세스할 수 있습니다. 따라서 HTTP 모듈을 사용하면 들어오는 요청을 검사하고 요청에 따라 작업을 수행할 수 있습니다. 또한 나가는 응답을 검사하고 수정할 수도 있습니다.

IIS 6.0에서는 ASP.NET 요청 파이프라인이 웹 서버 요청 파이프라인과 분리됩니다. IIS 7.0에서는 ASP.NET 요청 파이프라인과 웹 서버 요청 파이프라인이 공통 요청 파이프라인으로 통합될 수 있습니다. IIS 7.0에서는 이를 통합 모드라고 합니다. 통합 파이프라인에는 ASP.NET 개발자를 위한 다양한 이점이 있습니다. 예를 들어 통합 파이프라인을 사용하면 요청이 ASP.NET 리소스를 위한 것이 아니어도 관리 코드 모듈에서 모든 요청에 대해 파이프라인 알림을 수신할 수 있습니다. 하지만 원하는 경우에는 클래식 모드에서 IIS 7.0을 실행하여 IIS 6.0에서 실행되는 ASP.NET을 에뮬레이트할 수 있습니다. 자세한 내용은 IIS 7.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁷를 참조하십시오.

ASP.NET HTTP 모듈은 모든 요청에 대해 호출된다는 점에서 ISAPI 필터와 유사합니다. 그러나 관리 코드로 작성되며 ASP.NET 응용 프로그램의 수명 주기와 완전히 통합됩니다. 사용자 지정 모듈 소스 코드는 응용 프로그램의 App_Code 폴더에 배치하거나, 응용 프로그램의 Bin 폴더에서 사용자 지정 모듈을 어셈블리로 컴파일할 수 있습니다.

ASP.NET에서는 폼 인증, 캐싱, 세션 상태, 클라이언트 스크립트 서비스 등의 다양한 응용 프로그램 기능을 구현하기 위해 모듈을 사용합니다. 각각의 경우에 해당 서비스가 활성화되어 있으면 모듈이 요청의 일부로 호출되어 단일 페이지 요청 범위 이외의 작업을 수행합니다. 모듈은 응용 프로그램 이벤트를 사용할 수 있으며 Global.asax 파일에서 처리할 수 있는 이벤트를 발생시킬 수도 있습니다. 응용 프로그램 이벤트에 대한 자세한 내용은 IIS 5.0 및 6.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁸ 및 IIS 7.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁷를 참조하십시오.

참고
HTTP 모듈은 HTTP 처리기와 다릅니다. HTTP 처리기는 파일 확장명 또는 파일 확장명 패밀리에 의해 식별되는 요청에 대해 응답을 반환합니다. 이와 반대로 HTTP 모듈은 모든 요청 및 응답에 대해 생성되며, 요청 파이프라인의 이벤트 알림을 구독하고 등록된 이벤트 처리기에서 코드를 실행할 수 있도록 합니다. 모듈이 사용되는 작업은 응용 프로그램 및 해당 응용 프로그램의 모든 리소스 요청에 대해 일반적입니다.

HTTP 모듈 작동 방식

요청 파이프라인에서 알림을 수신하려면 모듈을 등록해야 합니다. HTTP 모듈을 등록하는 가장 일반적인 방법은 응용 프로그램의 Web.config 파일에서 수행하는 것입니다. IIS 7.0에서는 통합 요청 파이프라인을 사용하여 모듈을 IIS 관리자 및 Appcmd.exe 명령줄 도구 등과 같은 다른 방식을 통해 등록할 수도 있습니다. 자세한 내용은 Configuring Handler Mappings in IIS 7.0¹⁹ 및 Start Appcmd.exe²⁰를 참조하십시오.

ASP.NET에서 응용 프로그램을 나타내는 HttpApplication⁵ 클래스 인스턴스를 만들 때 등록된 모든 모듈의 인스턴스가 만들어집니다. 모듈을 만들 때는 해당Init²¹ 메서드가 호출되며 모듈이 자체적으로 초기화됩니다. 자세한 내용은 IIS 5.0 및 6.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁸ 및 ASP.NET IIS 7.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁷를 참조하십시오.

모듈의 Init²¹ 메서드에서 사용자는 BeginRequest²² 또는 EndRequest²³와 같은 여러 응용 프로그램 이벤트를 모듈의 메서드에 바인딩하여 이러한 이벤트를 구독할 수 있습니다.

참고
IIS 7.0 통합 파이프라인에서 작동하는 모듈의 경우에는 Init21 메서드에서 이벤트 처리기를 등록해야 합니다.

응용 프로그램 이벤트가 발생하면 모듈의 해당 메서드가 호출됩니다. 메서드는 인증 검사나 로깅 요청 정보와 같은 필요한 논리를 수행할 수 있습니다. 이벤트 처리 중에 모듈은 현재 요청의 Context²⁴ 속성에 액세스할 수 있습니다. 따라서 요청을 다른 페이지로 리디렉션하거나 요청을 수정하거나 기타 다른 요청 조작을 수행할 수 있습니다. 예를 들어 모듈에서 인증을 검사하는 경우 모듈은 자격 증명이 잘못되어 있으면 로그인이나 오류 페이지로 리디렉션할 수 있습니다.그렇지 않은 경우 모듈의 이벤트 처리기가 실행을 완료하면 ASP.NET에서는 파이프라인에서 다음 프로세스를 호출합니다. 이는 또 다른 모듈이거나 요청에 대한 적절한 HTTP 처리기(예: .aspx 파일)일 수 있습니다.

HTTP 모듈과 Global.asax 파일

사용자는 응용 프로그램의 Global.asax 파일에서 모듈의 여러 기능을 구현하여 응용 프로그램 이벤트에 응답할 수 있습니다. 하지만 모듈은 캡슐화되고, 한 번만 만들면 여러 응용 프로그램에서 사용할 수 있다는 점에서 Global.asax 파일에 비해 장점이 있습니다. 모듈을 전역 어셈블리 캐시에 추가하고 Machine.config 파일에 등록하면 여러 응용 프로그램에서 모듈을 다시 사용할 수 있습니다. 자세한 내용은 전역 어셈블리 캐시²⁵를 참조하십시오.

참고
IIS 7.0에서 통합 파이프라인을 사용하면 관리되는 모듈에서 ASP.NET 리소스에 대한 요청뿐 아니라 모든 요청에 대해 파이프라인 알림을 구독할 수 있습니다. Global.asax 파일의 이벤트 처리기는 응용 프로그램에서 리소스에 대한 요청이 발생하는 동안 알림에 대해서만 호출됩니다. 통합 모드의 사용자 모듈 범위는 응용 프로그램의 요청에 대해서만 이벤트 알림을 수신하도록 명시적으로 제한될 수 있습니다. 그렇지 않으면 사용자 지정 모듈에서 응용 프로그램의 모든 요청에 대해 이벤트 알림을 수신하게 됩니다. modules 섹션에 대한 add 요소의 precondition 특성이 "managedHandler"로 설정되어 있으면 모듈의 범위가 애플리케이션으로 제한됩니다.

Global.asax 파일을 사용할 경우에는 Session_Start 및 Session_End 등의 다른 등록된 이벤트를 처리할 수 있다는 장점이 있습니다. 또한 Global.asax 파일을 사용하면 응용 프로그램 전체에서 사용할 수 있는 전역 개체를 인스턴스화할 수 있습니다.

다음 조건을 충족하고 응용 프로그램 이벤트에 의존하는 코드를 만들어야 할 때는 항상 모듈을 사용해야 합니다.

• 다른 응용 프로그램에서 모듈을 다시 사용하려는 경우

• Global.asax 파일에 복잡한 코드를 넣지 않으려는 경우

• 모듈이 파이프라인의 모든 요청에 적용되는 경우(IIS 7.0 통합 모드에만 해당)

응용 프로그램 이벤트에 의존하는 코드를 만들어야 하고 이를 응용 프로그램 간에 다시 사용할 필요가 없는 경우에는 항상 Global.asax 파일에 코드를 추가해야 합니다. 또한 Session_Start 등의 모듈에서 사용할 수 없는 이벤트를 구독해야 하는 경우에도 Global.asax 파일을 사용할 수 있습니다.

HTTP 모듈 만들기

HTTP 모듈을 작성하는 일반적인 프로세스는 다음과 같습니다.

• IHttpModule² 인터페이스를 구현하는 클래스를 만듭니다.

• Init²¹ 메서드에 대한 처리기를 작성합니다. 초기화 메서드는 모듈을 초기화하고 필요한 응용 프로그램 이벤트를 구독합니다. 예를 들어 응답에 항목을 추가하려는 경우 EndRequest²³ 이벤트를 구독할 수 있습니다. 사용자 지정 인증 논리를 수행하려는 경우에는 AuthenticateRequest²⁶ 이벤트를 구독할 수 있습니다. 응용 프로그램 이벤트에 대한 자세한 내용은 IIS 5.0 및 6.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁸를 참조하십시오.

• 구독한 이벤트에 대한 코드를 작성합니다.

• 모듈에 정리가 필요한 경우에는 선택적으로 Dispose²⁷ 메서드를 구현합니다.

• Web.config 파일에 모듈을 등록합니다. 자세한 내용은 연습: 사용자 지정 HTTP 모듈 만들기 및 등록²⁸를 참조하십시오.

IIS 6.0 또는 이전 버전에서 실행되는 응용 프로그램에서 IIS 7.0에서 실행되는 응용 프로그램으로 모듈을 이동하는 방법에 대한 자세한 내용은 ASP.NET 응용 프로그램을 IIS 6.0에서 IIS 7.0으로 이동⁴을 참조하십시오.

맨 위로 이동

코드 예제

---

퀵 스타트

HTTP Handlers and Factories²⁹

방법 및 연습 항목

방법: HTTP 처리기 등록¹²

방법: IIS에서 HTTP 처리기 확장 구성¹³

연습: 동기 HTTP 처리기 만들기³⁰

연습: 비동기 HTTP 처리기 만들기³¹

연습: HTTP 처리기 팩터리 만들기 및 등록¹⁶

연습: 사용자 지정 HTTP 모듈 만들기 및 등록²⁸

맨 위로 이동

클래스 참조

---

다음 표에서는 HTTP 모듈 및 HTTP 처리기와 관련된 핵심 서버 클래스를 보여 줍니다.

클래스	설명
IHttpModule2	인터페이스를 구현한 다음 모듈을 Web.config 파일에 등록하여 사용자 지정 HTTP 모듈을 만드는 데 사용합니다.
IHttpHandler1	인터페이스를 구현하는 클래스를 만들어 사용자 지정 동기 HTTP 처리기를 만드는 데 사용합니다.
IHttpAsyncHandler3	인터페이스를 구현하는 클래스를 만들어 사용자 지정 비동기 HTTP 처리기를 만드는 데 사용합니다.

맨 위로 이동

참고 항목

---

참조

맨 위로 이동

개념

IIS 5.0 및 6.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁸

IIS 7.0의 ASP.NET 응용 프로그램 수명 주기 개요¹⁷

I encountered the "Error executing child request" error on my page as well and followed all the instructions in this thread but no luck. So I used Reflector to see what was going on, found the Server.Execute mentioned earlier in this thread and then debugged into the .NET source code to see what was going wrong and I think I've found the cause of my error. 

As mentioned everywhere you have to add the following handler to the configuration of your web app: 

 <add name="ChartImageHandler" preCondition="integratedMode" verb="GET,HEAD"path="ChartImg.axd" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35" />

In my case the chart is on the second tab of a Telerik RadMultiPage which uses postbacks. When I open the second tab the chart is loaded and the Server.Execute to ChartImg.axd is called. When you use Server.Execute, the http verb used for the parent request is also used for the child request. Since I'm doing a postback the verb will be POST which -as you can see in the "verb" attribute in the configuration setting above- is not allowed so it throws an error. So the simple change you have to make to get the chart to work is to add "POST" to the allowed verbs:

 <add name="ChartImageHandler" preCondition="integratedMode" verb="GET,HEAD,POST"path="ChartImg.axd" type="System.Web.UI.DataVisualization.Charting.ChartHttpHandler, System.Web.DataVisualization, Version=3.5.0.0, Culture=neutral,PublicKeyToken=31bf3856ad364e35" />

This would also explain why the chart control won't work on anything but the first page of an asp:wizard control or any other page where the EnsureInitialized check is done in a postback. 

I've seen this error message on many forums without a satisfactory fix being offered, so I'm guessing it's pretty common. As far as I can tell, the Server.Execute call to ChartImg.axd is only done to ensure the handler is configured correctly. It's kind of ironic that this check is the cause of so many errors. I think it's a case of code trying to be too smart for it's own good. 

원문 : http://social.msdn.microsoft.com/Forums/en-US/MSWinWebChart/thread/1dc4b352-c9a5-49dc-8f35-9b176509faa1/

The system.web section is for configuring IIS 6.0, while the system.webserver version is used to configure IIS 7.0. IIS 7.0 includes a new ASP.NET pipeline and some configuration differences, hence the extra config sections.

However...

If you're running IIS 7.0 in integrated mode only, you shouldn't need to add the handlers to both sections. Adding it to system.web as well is a fallback for IIS 7.0 operating in classic mode, unless I'm mistaken. I've not done extensive testing on this.

See http://msdn.microsoft.com/en-us/library/bb763179.aspx for

http://stackoverflow.com/questions/355261/whats-the-difference-between-system-web-and-system-webserver