.NET 애플리케이션 개발 팁 18가지 #4

Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

예전 Voice of .NETXPERT 2003 행사 때, 저희 회사의 김유철 책임이 발표했던 내용인 '아무도 가르쳐 주지 않는 .NET 애플리케이션 개발 Tips 18가지'를 정리해서 올립니다.

네번째로 ASP.NET 관련 팁 8가지 중 먼저 4가지를 올립니다.

Tip 8. 네트워크 드라이브에 있는 ASPX 실행하기

웹 서버가 여러 대 있는 경우, 웹 애플리케이션이 업데이트 되었을 때 이것을 각 웹 서버에 일일이 배포하는 일은 상당히 귀찮은 작업입니다. 별도의 배포 시스템(예 : AppCenter)을 사용하여 Rolling 업그레이드를 하는 것이 정석적입니다만, 어떤 회사에서는 배포 대상 파일을 한 곳(SAN과 같은 통합 스토리지, 파일 서버의 공유 폴더 등)에만 두고 이를 네트워크 드라이브로 공유해서 사용하는 경우도 있습니다. 이 경우, 공유된 경로에만 업데이트를 해주면 모든 웹 서버에 반영되므로 최소한 배포에 있어서는 훨씬 간편해 집니다.

우선 네트워크 경로로 IIS 홈 디렉터리를 설정하는 것은 쉽습니다.

문제는 ASP의 경우에는 별다른 문제가 없는데, ASP.NET의 경우, 위 그림과 같은 Parser 오류가 발생하게 됩니다. 무엇이 문제일까요?

바로 .NET Framework의 런타임 보안 정책과 관련된 문제입니다. ASP.NET이 ASPX 및 코드 비하인드 DLL을 처리하려면 FullTrust 권한이 필요합니다. 그런데, .NET Framework는 네트워크 드라이브, 즉 로컬 인트라넷에 대해서는 기본적으로 FullTrust를 하지 않기 때문에 이러한 문제가 발생하게 되는 것입니다.

해결책은 위의 글 중에 답이 있습니다. 런타임 보안 정책에서 로컬 인트라넷의 권한을 FullTrust로 변경해주면 됩니다.

 

Tip 9. 애플리케이션 간에 aspx, ascx 공유하기

예를 들어, 다음과 같이 동일 웹 애플리케이션 내에 있지 않는(즉, 다른 웹 애플리케이션에 속한) 웹 사용자 정의 컨트롤(*.ascx)을 페이지에서 사용하려고 하면, 다음과 같은 파서 오류가 발생되게 됩니다.

이 문제를 해결하려면, 다음과 같은 단계로 작업을 수행합니다.

1. 공유할 웹 애플리케이션을 동일한 물리적 위치로 지정합니다. 아래는 app1과 app2가 appshared를 공유할 경우입니다. (오타 수정 : 표에서 App1/control이 아니라 App1/appshared가 되어야 합니다)

 

2. 공유할 웹 애플리케이션(appshared)의 응용 프로그램 속성을 제거합니다.

3. 공유할 웹 애플리케이션(appshared)의 web.config, Global.asax를 제거합니다.

4. 이제 각 애플리케이션(App1, App2)의 페이지에서는 사용할 ASCX를 다음과 같이 지정합니다.

<%@ Register … Src="appshared/shareusercontrol.ascx" %>

Tip 10. 코드 비하인드의 긴급 수정

다음과 같은 시나리오를 가정해 보겠습니다.

ASP.NET 애플리케이션을 개발해서 개발 PC(또는 개발 서버)에 있던 내용을 실 서버에 배포했는데, 서버 관리자가 갑자기 긴급하게 수정해야 할 사항이 발견했습니다. 그런데 공교롭게도 이 내용은 매우 사소한 것이긴 한데, 코드 비하인드 클래스에 정의되어 있는 내용이라서 소스 파일을 수정해서 DLL을 재컴파일하여 올리지 않는 한 문제를 수정할 수 없는 상황이 되었습니다.

그런데, 이미 개발자는 퇴근을 했고, 관리자는 비주얼 스튜디오와 같은 개발 도구를 설치하지 않은 상황입니다. 비주얼 스튜디오가 있다고 하더라도 관리자는 사용법을 잘 알지 못합니다.

이러한 경우에 긴급하게 조치를 할 수 있는 방법이 없을까요?

우선 이 방법은 서버에 배포를 할 때, ASPX와 코드 비하인드 소스 파일(.aspx.cs 또는 .aspx.vb)이 같이 배포되어 있는 상황에서만 가능합니다. 또는 수정하려는 ASPX에 해당하는 코드 비하인드 소스 파일을 가지고 있어야 합니다.

이런 조건이 성립되어 있다고 가정하고, 긴급 조치 절차는 다음과 같습니다.

1. 수정할 .aspx의 코드 비하인드 소스 파일(.aspx.cs)를 편집기 등에서 열고, 문제점을 수정합니다.

2. 위의 코드 비하인드 클래스 이름을 임시로 변경합니다. 예를 들어 ProductList라면 ProductList_1 등으로 변경합니다.

3. 수정할 .aspx에서 <% @Page .. %> 내에서 CodeBehind를 Src로 바꾸고, Inherits 내의 클래스 이름을 1에서 변경한 이름으로 바꿉니다.

    <% @Page CodeBehind="productlist.aspx.cs" Inherits="Northwind.ProductList" %>

    <% @Page Src="productlist.aspx.cs" Inherits="Northwind.ProductList_1" %>

일단 이렇게 하면, 긴급 수정을 할 수 있게 됩니다. 그러나, 어디까지나 이 방법은 긴급 상황에서 사용할 수 있는 임시 방편일 뿐입니다. 정상적인 수정/업데이트의 경우에는 절대로 이 방법을 사용하지 않아야 합니다.

긴급 수정을 한 이후에는 개발자에게 해당 사항을 통지해주고, 문제점을 수정해서 컴파일된 버전으로 새로 업데이트를 하도록 합니다. 최소한 컴파일된 DLL을 업데이트해야 하고, 임시로 수정한 ASPX를 다시 원래로 돌려놓아야 한다는 것에 유의하십시오.

Tip 11. Postback 간 스크롤 위치 고정

웹 폼 페이지를 스크롤해서 내린 상태에서, 포스트 백이 일어나면 스크롤 위치가 다시 맨 상단으로 돌아가버리는 단점이 있습니다.

이 문제를 해결하기 위한 방법은 크게 3가지가 있습니다.

첫째, SmartNavigation을 사용하는 방법입니다. 다음과 같이 page directive에 SmartNavigation을 true로 지정해 줍니다.

<%@ Page ... SmartNavigation="true" %>

이 방법은 가장 간편하긴 하지만, 페이지 내에서 클라이언트 스크립트를 사용하는 경우 Smart Navigation의 스크립트와 충돌하여 문제가 발생할 수 있습니다.

둘째, 다음과 같이 URL 뒤에 컨트롤ID를 앵커로 지정합니다.

http://localhost/.../....aspx#DataGrid1:_ctl72:_ctl0

위 코드는 DataGrid1의 72번째 줄을 기준으로 스크롤을 하게 됩니다.

셋째, 클라이언트 스크립트의 scrollIntoView를 사용합니다.

<scirpt> document.all('DataGrid1').rows[72].scrollIntoView(true) </script>

해결은 가능은 하지만, 보다시피 깔끔한 방법은 없네요. ^^

 

다음번엔 나머지 ASP.NET 팁 4가지를 올리겠습니다.