안녕하세요. 이번에 새롭게 팀원이된 박세식이라고 합니다. 많이 부족해서 컴터앞에 앉아 이렇게 자판을 두드리고 있는 시간에도 떨림이 멈추질 않네요-_-; 앞으로 잘 부탁드리겠습니다.(따스~한 피드백 아시죠^^;)  
자~ 그럼. ASP.NET MVC에 대해 알아보도록 하겠습니다.

첫번째 시간으로 ASP.NET MVC vs ASP.NET WEB FORM 에 대해 글을 써보도록 하겠습니다. 제 포스트는 ASP.NET MVC에 관한 글입니다.^^; 그래서 이 둘의 대결구도라기 보다는 웸폼의 문제점을 짚어보고 MVC에 좋은 점에 대해서 글을 써 나가려고 합니다.


ASP.NET WEB FORM의 문제점?

ASP.NET WEB FORM은 ASP.NET 개발의 전통적인 스타일이고, 큰 스케일의 웹사이트를 좀더 간단하게 만들게 해주는 기술입니다. 웹폼은 드래그 앤 드랍으로 컨트롤들을 ASP.NET 페이지에 추가하고 그것들에 맞는 코드를 작성합니다. 이러한 개발방식이 개발자들의 마음을 끄는거죠. 그!러!나! 웹폼은,

● 관계가 분리되어 있지 않습니다. UI와 코드가 섞여있죠--;
● 자동적으로 테스트하는 것이 쉽지 않습니다. 런타임 시작없이 테스트하기가 어렵죠. 이는 실행환경을 쭉~ 돌면서 테스트할 수 밖에 없다는 겁니다-_-;
● 상태정보를 저장하려면 각 서버페이지의 상태를 뷰스테이트라고 하는 히든 필드값으로 클라이언트 페이지에 저장합니다.

하지만, 웹폼 개발에서의 특징인 뷰스테이트와 포스트백은 축복이자 파멸의 원인이됩니다. 뷰스테이트는 클라이언트와 서버간의 오고가는 데이터들의 상태를 히든 필드로 구성하고 있는 메커니즘으로, 이것의 크기는 무지막지하게 커질 수 있습니다. 매번 호출시 이 거대한 데이터가송수신된다니 끔찍스럽죠-_-; 특히 페이지에 데이터그리드나 그리드뷰와 같은 서버컨트롤이 포함되어있다면 한페이지 한페이지 넘길때마다 응답지연의 원인이 되어 사용자들을 기다림에 지치게 만드는거죠 OTL;; 또한 포스트백은 매번 액션에 의한 트리거로서 발생이됩니다. 그 거대한 데이터(뷰스테이트)를 어떤 액션만 취하게 되면 다시 그리게 되는거죠. 이 뷰스테이트에 대해 좀더 알아보죠.


뷰스테이트(View State)란?

뷰스테이트는 포스트백시 웸폼의 상태의 변화를 유지시켜주는 기술입니다. 일반적으로 __VIEWSTATE라는 이름의 히든 필드로 웹페이지에 위치합니다. 이 히든값은 수십 킬로바이트씩 쉽게 커질 수 있습니다. 이 뷰스테이트는 사용자가 웹 페이지를 포스트백 할 때 천천히 불려지고(다운로드), 그 히든 값의 내용을 웹 요청시에 포스트해서 요청 시간을 길어지게 합니다. ASP.NET 웹 페이지의 요청이 올 때 정확하게 무슨 일이 일어나는지를 알려면 ASP.NET 페이지의 생명주기(Life Cycle)을 알아봐야 하는데요. 잠깐 간단하게만 알아보도록 하죠^^;(어째~ 이야기가 점점 옆으로 새네요.. 언제 제자리로 돌아올지는 생각하지 말아주세요-_-;)


Asp.Net Page Life Cycle

매번 ASP.NET 웹 페이지에 의해 서버에 요청이 오면 첫째로 웹 서버는 ASP.NET 엔진으로 요청을 넘깁니다. ASP.NET 엔진은 웹 페이지의 올바른 파일 접근을 확인하는 여러 단계로 구성된 파이프라인을 통해서 사용자의 세션 정보를 얻습니다. 파이프라인의 끝에서는 요청된 웹 페이지에 상응하는 클래스를 인스턴스화하고 ProcessRequest() 메쏘드를 호출합니다. ASP.NET 페이지의 생명주기는 ProcessRequest() 를 통해서 시작됩니다. 이 메쏘드는 페이지의 컨트롤 단계를 준비합니다. 그 다음으로, 페이지와 서버는 ASP.NET 웹 페이지에 필요한 여러 단계를 하나씩 단계별로 밟게 됩니다. 이 단계들에는 뷰스테이트를 관리하고, 포스트백 이벤트를 처리하고, HTML 페이지를 렌더링하는 것들이 포함되어 있습니다.


그림 1. 페이지 생명 주기의 이벤트들
출처 : http://msdn.microsoft.com/en-us/library/ms972976.aspx

다시 뷰스테이트로 돌아와서 정리하자면, 세상에 공짜는 없습니다.(비용이 든다는거죠) 여기 뷰스테이트도 예외일 수는 없습니다^^; ASP.NET 페이지가 요청될 때마다 뷰스테이트는 두가지 성능에 관련되는 일을 합니다. 첫째는, 모든 페이지를 방문할 때 뷰스테이트는 해당 컨트롤 계층의 모든 컨트롤의 뷰스테이트를 모아서 베이스 64 인코딩으로 시리얼라이즈합니다. 여기서 생성된 스트링이 __VIEWSTATE에 값인거죠^^

반대로, 포스트백시에는 뷰스테이트를 읽엇 저장된 뷰스테이트 데이터로 디시리얼라이즈하고 컨트롤 계층구조에 있는 적절한 컨트롤러로 업데이트합니다. 두번째로, 뷰스테이트는 클라이언트가 다운로드 받아야할 웹페이지의 크기를 증가시킵니다. 원래 보여질 페이지의 데이터와는 또다른 데이터인거죠. 뷰스테이트 크기가 큰 페이지는 이 뷰스테이트의 크기가 수십 킬로바이트가 됩니다.  이것을 다운받기 위해 또 수 초나 수 분의 시간을 할애해야합니다.(이게~ 뭔가요-_-;) 또, 포스트백시에도 뷰스테이트를 웹 서버로 보내야하고, 그것 때문에 포스트백 요청시간이 증가하는 거죠.


ASP.NET MVC 알아보기

ASP.NET MVC는 모델, 뷰 그리고 컨트롤러로의 3개의 파트로 분리되어 구현됩니다.


그림 2. MVC Framework
출처 : http://dotnetslackers.com/articles/aspnet/KiggBuildingADiggCloneWithASPNETMVC1.aspx

● 뷰(View) 는 애플리케이션의 UI를 담당하고, 이는 단지 컨트롤러에 의해 애플리케이션의 데이터로 채워질 HTML 템플릿에 지나지 않습니다.
● 모델(Model) 은 UI를 렌더링하는 뷰가 사용할 애플리케이션의 객체, 즉 애플리케이션의 데이터의 비즈니스 로직을 구현합니다.
● 컨트롤러(Controller) 는 사용자 입력과 상호작용하는 응답을 핸들링합니다. 웹 요청은 컨트롤러에 의해 핸들링되고, 요청된 URL의 표현될 뷰와 적절한 데이터(모델 객체)를 결정합니다.


ASP.NET MVC의 요청 흐름도

ASP.NET MVC 애플리케이션은 웹폼과 같이 주소창에 입력된 URL이 해당서버의 디스크에 있는 페이지(파일)을 찾는것이 아닌 컨트롤러를 통한 뷰를 호출하게 됩니다. URL은 컨트롤로와 매핑이 되고 컨트롤러는 뷰를 리턴해주는 식이죠. 다음의 그림을 보시면


그림 3. 요청 흐름도
출처 : http://dotnetslackers.com/articles/aspnet/KiggBuildingADiggCloneWithASPNETMVC1.aspx

처음 사용자 요청(URL)이 들어오면 Routing Rule 에 의해 컨트롤러를 매핑시킵니다. Routing Rule 은 ASP.NET MVC 프로젝트를 생성하면 Global.asax에 정의되어 있는데요. 제 블로그에 컨트롤러를 설명하면서 Global.asax에 대해 간략하게 설명한 부분이 있는데요 참고하시기 바랍니다. 여기서도 간단히 설명드리자면, 주소는 {controller}/{action}/{id} 이런식으로 들어오게됩니다. 특정 컨트롤러의 특정 액션메쏘드의 파라미터로 id를 넘겨준다는 룰이죠. (액션메쏘드는 컨트롤러 클래스에서 public으로 제공되는 메쏘드를 가리킵니다.)

다시, 컨트롤러는 뷰에 넘겨줄 데이터를 만들 모델을 선택합니다. 선택된 모델객체는 뷰에 넘겨줄 데이터(ViewData)를 만들고, 컨트롤러가 이를 뷰에 넘겨줍니다. 마지막으로 뷰는 HTML로 렌더링해서 사용자에게 보여줌으로 하나의 흐름이 흘러가는 거죠^^;

그래서 ASP.NET MVC의 장점은?

● 모델, 뷰, 컨트롤러로 명확하게 관계과 분리되어 있어 복잡한 애플리케이션 로직을 관리하기 쉽게 해줍니다. 이로 인해 각 개발자는 MVC 패턴의 분리된 컴포넌트를 각자 개발할 수 있습니다. 페이지 단위로 되어 있는 웸폼은 비하인드 코드에서 로직을 담당하게 되는데요. 다른 두개의 페이지에서 비슷한 작업을 하게 된다해도 하나의 작업으로 사용하기가 어렵다는 거죠^^; 특정 페이지의 이벤트가 그 페이지의 비하인드 코드를 호출하기 때문에 같은 작업을 해도 저처럼 잘 모르는 사람들은 저희에게 무한한 능력(?)을 심어주는 카피 앤 페이스트 작업을 거쳐야한다는 겁니다.

● 유닛테스팅을 쉽게해줍니다. 이 유닛테스트도 M,V,C 가 각각 깔끔하게 분리되어 있어주기 때문에 가능한거죠^^; 추후에 유닛테스트가 과연 얼마나 쉬운지 알아보는 시간을 갖도록 하겠습니다.

● MVC 모델은 뷰스테이트와 포스트백을 사용하지 않습니다. 그래서, MVC는 일반적으로 웹폼에 비해 페이지 사이즈가 작습니다. 폼의 히든 필드인 뷰스테이트 데이터와 같은 불필요한 데이터가 없기 때문이죠.

● 웸폼 모델에서의 URL이 서버의 존재하는 파일을 직접 요청하는 것 대신에 REST 방식의 URL을 사용하여 URL을 간단하게 해주고, 기억하기 쉽게 해주고, SEO의 도움을 줍니다.


● jQuery나 ExtJS와 같은 클라이언트단 자바스크립트 프레임워크와 쉽게 통합할 수 있습니다.


마무리요

사실, 웸폼과 MVC를 비교해서 꼭 이것이 더 좋으니까 이것만 사용해야지가 아닙니다. 각 프로젝트의 특성에 맞게 선택하는 거죠. (다시한번 말씀드리지만 이 포스트는 ASP.NET MVC에 관한 글입니다--;) 성능을 따지지 않고 빠른 개발을 원한다면 웹폼을 선택하는 것이 좋을 것 같고, 유닛테스팅과 성능에 중점을 두겠다 싶으면 MVC쪽을 선택해봄이 좋겠다는 거죠. 다음 포스트에는 예제를 통해서 ASP.NET MVC와 인사를 나눠보는 시간을 갖도록 하겠습니다^^


참고자료 :
http://msdn.microsoft.com/en-us/library/ms972976.aspx
http://dotnetslackers.com/articles/aspnet/KiggBuildingADiggCloneWithASPNETMVC1.aspx
http://msdn.microsoft.com/en-us/magazine/dd942833.aspx
http://www.techbubbles.com/aspnet/aspnet-mvc-and-web-forms/
http://www.taeyo.net/lecture/NET/AspNet35_pre02.asp
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx

다음의 소스코드로 시작해 봅시다.


어 이거 뭔가요. 뭔가 익숙한 것 같으면서도 이상한 코드입니다.

대충 보아하니 화면에 "Hello, 世界" 를 출력하는 프로그램 같은데 Console::WriteLine() 같은 걸 보자니 Visual C++ 에서 Managed Code 프로그래밍 하는 것 같기도 하고, call, pop 이런 것들을 보니까 어셈블리어 같기도 합니다. 야~~ 21세기에 컴퓨터 개론에서나 보던 스택 PUSH, POP 신경쓰면서 화면에 저런거 찍어야 겠나 싶기도 하네요.

그런데 또 다시 생각해보면 사람이 보긴 답답해도 속도만 빨라졌지 여전히 좀 멍청한 CPU가 알아먹기는 좀 쉬울 것 같다는 생각이 들기도 합니다. 

네 저 코드는 .NET하면 누구나 들어봤을만한 IL (Intermediate Language) 코드라고 하는 것이라고 하네요. .NET Framework 기반의 환경에서 프로그래밍을 하게 되면 어떤 언어로 프로그래밍을 하던 .NET을 지원하는 모든 컴파일러는 지금까지 많이 봐오던 기계어로 컴파일을 하는 것이 아니라 MSIL이라는 코드로 컴파일을 합니다.

자. 일단 코드를 만들어 봤으니 실행을 시켜봐야죠. IL코드는 뭘로 컴파일을 해야 하나요. MSDN을 디벼보니 ilasm.exe 라는 .NET Framework의 도구를 이용해 컴파일을 할 수 있다고 합니다.

그러면 Visual Studio 2010에서 제공하는 CMD를 열고 해당 소스를 컴파일 해봅니다. (시작 -> 프로그램 -> Microsoft Visual Studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010) 을 이용하면 됩니다.)



컴파일 하면 exe 실행파일이 생성이 되고 그 실행파일을 실행하니까 Hello, 世界 찍힙니다! 코드대로 Press Enter to continue 나오고 거기서 아무 키나 누르면 프로그램 실행이 종료됩니다.

(당연한거지만) 유니코드 지원 잘 되는군요. 보통 Hello World를 찍는데 Hello 世界 라고 글로벌하게(?) 찍은 이유는 얼마전 구글에서 공개한 Go 언어의 소개 프로그램이 Hello 世界 였거든요. 그게 괜히 멋져보여서 따라해 봤습니다. ㅎㅎ


명색이 프로그래머인데 첫인사는 코드로 해야 하지 않겠나. 싶어서 이렇게 너저분하게 인사를 해봤네요. 앞으로 CLR에 대해서 공부하면서 공부한 내용을 나름대로 정리해서 이런식으로 공유를 해 볼 생각입니다. 같이 공부하는 입장이라 이래저래 시행착오도 많을테고 실수도 분명히 있을테지만 앞으로 잘 부탁드립니다. _(_ _)_

CLR은 Common Language Runtime의 약자로 우리말로 번역하니 [공용 언어 런타임] 이라고 번역이 되네요. [공용 언어]는 우리말인데 [런타임]은 왜 런타임인가. 도대체 런타임이 뭔가요?

IT용어사전을 찾아보니 런타임에 대한 내용이 다음과 같이 나와 있습니다.


아. 프로그램을 실행하는데 필요한 소프트웨어 모듈을 말한답니다. 그렇다면 CLR은 공용 언어를 실행하는데 필요한 소프트웨어 모듈. 정도가 되는건가요?

위키도 한번 뒤져봤습니다.


아 맞네요. 우리가 오늘부터 공부하고자 하는 CLR이라는 놈은 바로 IL을 실행가능하게 해주는 놈입니다. .NET Framework 기반의 모든 언어들은 언어를 가리지 않고 각자의 컴파일러에 의해 IL이라는 언어로 컴파일이 되고 CLR에 의해 IL기반의 코드들이 실제로 실행이 되게 되는 것이네요.

대충 CLR이 어떤 일을 한다는 것을 알게 되었습니다. 그렇다면 왜 CLR이라는 걸 만들었는지 CLR의 주변엔 또 어떤 것들이 있는지 주욱- 한번 훑어봐야지 앞으로 진도 나가는데 어려움이 없겠지요.

후아-
오늘은 여기까지 하죠!

 

VS 2010의 IDE를 어제 설명했다면. 오늘은. ^^ 네 2번째 IDE 소개이지 변화 입니다. 이번에 이야기 할 내용은 IDE에 적용한 기술과 그 기술을 이용한 활용 편이라고 생각하시면 될것 같습니다.(활용은 여러분 마음입니다.~ ㅠ.ㅠ)

 

다들 아실겁니다. 아시죠?/ WPF ~

Windows Presentation Foundation 의 약자이며, 이제 딱딱한 윈도우는 가라~ 새로운 이쁘장하게 또는 멋있게~ 또는 진짜 진짜~ 짱 멋있게 다른 한마디로 이게 윈도우야? 오~~ 하는 말이 나올 정도로 윈도우를 멋있게 만들 수 있는 하나의 기술(?) 이죠. 많은 전문가 분들도 있고 커뮤니티도 있습니다.(전 처음에 이것을 김태영 MVP님이 하시는 세미나에서 봤습니다. ^^ 참 오래전이였죠  ㅎㅎ) 이 WPF를 꺼낸 이유가 당근 있습니다. 우리가 VS 2010 또는 옛 VS 를  실행하게 되면 어떤 화면이 나오는지 아시는지요?

 

개발자 1 : 난 걍 빈화면 왜? 뜨는게 넘 느려서….

개발자 2 : 난 마지막 프로젝트 왜? 하던일 마저 해야지

………

등등 많이 있습니다.

 

일을 하기 위해선 우리는 TFS나 Source Safe에 연결하여 Source를 가져오고 어쪄고 하고 내가 오늘 해야할 일이 무엇인지 등등.. 여러 윈도우 또는 VS의 IDE에 필요한 것을 표시하는 등등을 합니다. 저는 팀 프로젝트를 하고 있다고 가정하고 돈 많이 많이 주는 회사(희망사항입니다. 전 백수 입니다 ㅠㅠ 어디 절 찾아주는 회사도 엄고 ㅠ.ㅠ)에서 일하고 있으며, TFS와 연결하여 내가 오늘 해야할 일을 확인하고, Outlook을 열고 메일을 확인 후 TFS에서의 결과를 보든등.. 여러 창을 봐야하는.. ㅠ.ㅠ 일을 합니다.(절대 가정입니다.. 하나의 예입니다.. - 사실 요즘 VS 2008 에서 그러구 있습니다 ㅠ.ㅠ)

VS 2010에서는 이것을 한방에 해결 할수 있습니다. 어떻게?

 

VS 2010의 첫 화면이 어떠시나요?  바로 이런 화면 아닌가요?

 

 

이 화면이은 어떻게 만들어 졌을까요? 이게바로 WPF만든 화면입니다. 이 화면을 우리가 바꿀수 있다면?

앞에서 이야기 한 내용,

 

1. Outlook 에서 온 TFS 메일 내용 확인 또는 RSS 보기

2. Groupware 에서의 공지사항 보기

3. TFS의 작업 내용 보기

 

등 개발에 필요한 공지사항이나 회사 주요 공지사항을 한눈에 보고 메일중에서 TFS나 개발에 필요한 메일을 읽을 수 있거나 RSS 로 첫 화면에서 볼 수 있다면 어떨까요? 이런 이야기는 사실 올 초에 건대에서 한 세미나에서 제가 잠시 데모와 함께 이야기를 했었습니다. 이런 화면을 변경할 때 필요한 기술은 별도로 원하지 않습니다. 바로 WPF를 알고 있고 이미 WPF를 한다면 이미 시작 화면을 여러분의 마음에 드시는 것을 변경할 수 있습니다.(헉 뭐 이리 거창한지 사실 이것은 정말 정말 .. 예입니다.^^)

옛날에도 VS IDE를 변경하거나 하는 기술은 있었지만, WPF로 첫 화면을 이미 여러 분들이 알고 있는 기술로 변경할 수 있으므로 별도의 기술이나 교육을 받지 않아도 된다는 것입니다.

 

이미 Beta 1이나 CTP 버전에서 이 사이트의 엄준일 MVP님의 사이트에도 있으며 영문으로는

http://blogs.msdn.com/vsxteam/archive/2009/05/20/visual-studio-2010-beta-1-start-page-customization.aspx

이 곳에 가시면 옛날 버전으로 나와 있습니다. 이것을 이야기 하자고 하는것이 아니라 VS 2010 Beta 2에서도 되냐고 말씀하시면.. 네 되곘죵? ㅎㅎ 그런데 조금 다릅니다 어떻게? 위의 블로그 Beta1일 경우이고 이제 Beta 2 에서는 조금 다릅니다.

 

 

 

위치는 특별하지 않습니다. 옛날 그대로 C:\Program Files(x86)\Microsoft Visual Studio 10.0\Common7\IDE\StartPages\en이라는 곳에 있습니다. X64 버전의 윈도우에 VS 2010 을 설치 하셨다 하여도 이 위치는 그대로 입니다. 엣날에는 제가 아마 이곳을 복사하여 VS 2010 폴더에 저장하는 등등 일을 했는데 이제는 하지 않습니다. 바로 VS 2010을 보시면.. 메뉴에서

   Tools  -> Options -> Environment 에서 Startup을 찾습니다.

 

그 다음 Customize Start Page :  항목을

 

VS 2010를 설치하셨다면 "내 문서" 에서 "Visual Studio 2010" 폴더에서 "StartPages" 보실 수 있습니다. 이 곳으로 가시면 VS 2010 의 시작화면을 담당하는 xaml 과 프로젝트 파일이 있습니다.

 

 

 

 

 

사실 전 이미 StartPages.xaml 파일을 이미 백업해 두고 있습니다. ^^ 엣날에는 이게 없어서 복사하고 어쪄구 했는데 이제는 복사고 뭐고 VS 2010 beta2 에서는 프로젝트 파일과 xaml 파일이 이미 들어 있습니다. 이 프로젝트 파일을 열어보면.. 다음과 같은 화면입니다.

 

 

네 바로 WPF로 만든 시작페이지를 보실 수 있습니다. 이것을 변경하면 어떻게 될까요? 네 변경해 보겠습니다.

어떻게 내 마음대로 변경합니다. ㅎㅎ 그렇지만 몇가지 제한이 있습니다. 보시면 cs파일이 없습니다.(넵 WPF 찰스 아찌 책이 생각납니다.. 서점에서 4시간 조금 넘게 쭈구리고 앉아서 정신 없이 봤던..  이 아찌 책은 다 텍스트야 ㅠ.ㅠ)

그래서 제한이 조금 있습니다. 어떤것? 잘 보시면 "vs:" 으로 시작하는데 이곳에서 작업을 할때는 vs:으로 지원하는 녀석들을 써야 하는 것입니다.(그럼 다른 방법은???  ㅡ.ㅡ 정식 블로그 입니다.. 이해를..)

 

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

 

이곳에 가보시면 어떻게 만들어야 하는지가 나오는데.. 이 부분은 추후 시간 되면 제 블로그에 "내 맘대로 번역"이라는 주제로 함 번역과 함께 쏙쏙들이 알아볼까 합니다.(정말 할수 있을지는 ㅠ.ㅠ)

그래서 어찌 됐든. 이제 코딩합니다.

Vs: 하면 바로  다음과 같은 선택화면이 나옵니다.

 

이곳의 녀석을 이용해서 코딩하는데 일단 ImageButton으로 해보겠습니다. 왜나면? 일단 URL을 가져보는 녀석으로 함 해보려구요 ^^ 물론 WPF의 도구를 가져와도 되긴 합니다. 그래서 WPF의 달력 컨트롤과 VS: 이용한 간단한 이미지 버튼을 함 만들어봤습니다.

 

이렇게 WPF 코딩을 하면..

 

 

결과는 이렇습니다. ^^ 그럼 저장하고 Build 하면.

 

시작화면이 변경이 됩니다. 그 다음 VS:ImageButton에서 Command 을 이용해서 VS2010.net 이로 이동하도록 했습니다. 날짜가 아닌 이미지 버튼을 클릭하면 ^^ VSTS2010.net으로이동합니다.

간단히 변경을 했지만 몇가지 주의 사항과 제 결론입니다. (제 사견 입니다. ^^ MSDN 영문 자료를 참고하시길^^)

 

 1. VS: 을 이용하여 코딩한다.

 2. WPF를 이용할 수 있지만 Event는 다르게 해야한다.

 3. VS 2010의 IDE나 환경을 변경하려면 MEF를 하면 더 좋다

 4. 절대 StartPages.xaml을 백업한다 (왜? 혹시 모르니까요 ^^)

 5. 만약 백업도 하지 않았다면  앞에서 설명한 VS설치 폴더의 StartPages 폴더의 StartPages.xaml를 이용하여 복원할 수 있다.

 

 

위의 주의사항인 1번을 잘 확인하시고 MSDN 사이트를 참고하여 여러분의 시작화면을 변경을 해보시는 것도 좋습니다.

사실 앞에서 이야기한 것을 하기 위하여는 조금 더 공부를 해야하므로.. 그것은 다른 기회에 해보구요. ^^

(정말 "내 맘대로 번역"을 ^^ 함 생각중입니다. MSDN에서 제가 필요한 부분에 대하서만요 ㅎ ㅎㅎㅎ  )

 

Beta1에서는 복사하고 어떻게 했지만 이제 Beta2 부터는 시작페이지 프로젝트를 바로 열기를 하여 수정하여 저장하면 된다는 것입니다. 이게 Beta1하고의 차이점 입니다.

 

그럼 오늘은 여기 가지 하고 다음은 ^^ 언어별 IDE 를 조금 알아보겠습니다.