Parasite’s WebSite

출처 : http://blog.naver.com/lunaccy/140064159847

* 커뮤니티 (한국)
http://osxdev.org/
http://iphoneos.co.kr/

* 블로그 (한국)
Lingo * http://nabiri.tistory.com/
http://wangsy.com/blog/
Jenix http://jinhyung.org/ 코코아 프로그래밍
http://i-dreaming.com/ 예제로 시작하는 아이폰 개발
http://kr.code4mac.net/
http://han9kin.doesntexist.com/
http://maccrazy.tistory.com/
http://redleaf.tistory.com/
http://allmac.tistory.com/
http://goya.pe.kr/
http://cocoadev.co.kr/
http://blog.naver.com/eungyoda
http://oedalpha.springnote.com/

* 아이폰 어플 제작소 (한국)
http://xevious7.com/ FreshWater Aquarium
http://vanillabreeze.com/ Maneki Neko, Crack LCD, Ruler Deluxe, Hypnotized!, iSurprise
http://orclab.com/ iPuzzle, Touch up
http://blog.naver.com/whatisid/ Big Day
http://orchardparty.com/ The GoStop
http://krazyeom.wordpress.com/ Crocodile Dentist
http://imagebakery.tv/iphone/ The Thumb
http://aiart.tistory.com/ Janggi - Korean Chess
http://leopardmac.tistory.com/ Kimchi Recipe
http://cre8ive.tistory.com/ Bounced
http://clearday.tistory.com/ Hard Game, Sakura Clock
http://daummobile.tistory.com/ Daum tvPot
http://sociag.com/ Valentine Flowers
http://onlinegamer.co.kr/ iConductor
http://kkapps.wordpress.com/ GoStop
http://nemustech.com/ iHappyDays
http://alonesworld.blogspot.com/ Love Gauge
http://arouse.cafe24.com/tc/ Brave Prince
http://i-bocom.com/ MyCents
http://zigzix.com/ Zemote
http://iphone.com2us.com/
http://appstore.dreamwiz.com/
http://neohelp.sayclub.com/sayclub/ (IE 전용)
http://iphone_eng.daolsoft.com/
http://www.cbs.co.kr/event/08/radioIpod/
http://truemobile.com/

* 서적
꿈, 희망=아이폰 개발=맥 개발? 코코아부록.pdf http://blog.insightbook.co.kr/107
예제로 시작하는 아이폰 개발 http://acornpub.co.kr/book/iphone-appdev

World
* 아이폰 어플 제작소
http://illusionlabs.com/ Sway, Touchgrind, Labyrinth, iPint

* 개발자 블로그
Jeff Lamarche http://iphonedevelopment.blogspot.com/
Matt Gallagher http://cocoawithlove.com/
Bill Dudney http://bill.dudney.net/roller/objc/
Erica Sadun http://ericasadun.com/

* 커뮤니티
Stack Overflow http://stackoverflow.com/questions/tagged/iphone
iPhone Developers on Twitter http://is.gd/hlhV

* 개발 스토리
에단 니콜라스 iShoot http://www.ebuzz.co.kr/content/buzz_view.html?m_id=0211&cat_id=&uid=78925&page=2

* 리소스
스탠포드 강의 http://www.stanford.edu/class/cs193p/cgi-bin/index.php
http://appsamuck.com/blog/index.php/2008/10/28/the-really-big-list-of-iphone-sdk-development-links/

Development

출처 : http://www.zdnet.co.kr/itbiz/column/anchor/goodhyun/0,39030292,39161841,00.htm
2007년 우리네 개발자의 자화상은 유난히 수척하고 우울하다. 연이어 터져 나오는 개발자 처우에 대한 보도와 칼럼들은 IT를 이공계 기피의 공식 상징으로 만들어 버렸다. 이런…… 별로 낭만적이지 않다.

어느덧 개발자의 후생(厚生)은 나의 최우선 관심사가 되어 버렸다.

우리는 누구나 자기가 좋아하는 일을 하는 삶을 꿈꾸고, 또 그 일이 사회에 가져다 주는 가치에 걸맞은 대가를 받기를 바란다. 낭만적 인생의 얼개란 의외로 단순하다. 그렇다면 개발자들은 적어도 자기가 좋아하는 일이 무언지 안다는 면에서는 행복한 이들이다. ‘알고리즘의 오르가즘’, 즉 내 논리가 증명될 때의 기쁨에 끌려 이 바닥에 들어 왔기 때문이다. 허나 이 ‘손맛’ 누구나 맛볼 수는 있지만, 그 대가는 천차만별이다. 스톡옵션과 인센티브 덕에 벤츠를 모는 프로그래머도 있지만, 그 동갑내기는 소위 말하는 SI 막장의 트러블 프로젝트 속에서 요구분석조차 제대로 되지 않은 시스템을 무한 반복적으로 수정하고 있기도 하다. 전자는 한 사람의 개발자가 세상을 흔들 가치의 원천임을 증명한 셈이지만, 동시에 후자는 정부가 정한 단가표로 조달 가능한 부품에 불과함을 증명하고 있다.

이 차이의 원인은 어디에 있을까? 운이라고 말하면 성의 없는 대답이지만, 노력 탓이라고 말하는 것도 잔인한 기만이다. 지금 개발자들이 겪는 우울은 이 격차에 대한 울분이라기보다, 후자에서 전자로 이어지는 연속된 흐름이 발견되지 않는 구조적 모순에 있다. 닮고 싶은 롤모델도 없고, 괴로운 나날을 지킬 비전도 없다. 그도 그럴 만 하다. 안타깝게도 우리 주위에는 기술의 힘에 의해 기업의 지속 가능성(Sustainability)를 확보한 곳은 찾기 힘들다. 대신 기묘한 다단계의 착취 구조의 잉여 축적으로 지속 가능성을 근근이 유지하는 곳만 즐비하다. 가치를 발휘할 대상을 찾지 못하는 이들이 가치를 발휘할 리 없다. 악순환이다. 그렇기에 대부분의 경우 자기책임론은 무책임한 말이다.

어떻게 하면 좋을까? 가치를 둘러싼 사회의 문제란 결국 경제적 문제다. 그리고 경제적 부조리의 대부분은 수요와 공급의 구조 변화에서 온다. 우리는 이 구조를 간과해 왔다. 이를 알아차린 혹자는 의사나 변호사처럼 이익을 대변할 길드를 형성해야 한다고 말하고, 또 다른 이는 구조적 문제를 해소할 ‘당’을 만들어야 한다고 농담 같은 진담을 해 오기도 한다. 공급자의 입장에서 공급을 조절하는 구조를 꿈꾸는 기초적 반항심이다.

그러나 이는 더 본질적 문제를 간과하고 있다. 그 것은 ‘업’, 즉 프랙티스(practice)라는 개념이 완성되는 과정이다. 의사도 변호사도 모두 구조적 절차, 예컨대 선별 과정과 자성 절차를 통해 자신들의 업을 정의하게끔 하고 그 정의에 맞는 수행을 하도록 스스로를 단련하고 있다. 이 것이 구조의 힘이다.

우리는 스스로를 개발자라고 말하지만, 이는 그냥 운동선수라고 말해 버리는 것과 마찬가지의 뭉툭한 묶음이다. IT라는 산업 역시 산업으로서의 스포츠 전체와 같아서, 어떠한 종목을 선택할지에 따라 이 산업에 참여한 신인의 미래는 크게 달라진다. 인기, 비인기 여부, 그리고 프로 리그의 존재 여부, 여기에 자신의 적성 및 특기, 비전이 더해져서 스포츠인으로서의 인생은 구조 안에서 만들어 지는 것이다.

이 적응과 선택이 합리적이고 타당한 분기점과 분배구조를 통해 거쳐 가면서 누구는 맨유의 일원으로 또 누구는 마포구 조기축구회의 일원으로 각각 나름의 땀을 흘리게 된다. 이 것이 성숙된 구조를 지닌 산업의 일원에게 주어진 낭만성이다. 가장 인간적이며 원초적인 파이팅 정신을 스포츠에서 찾게 되는 이유는 어쩌면 이 절차적 투명성 덕일지 모른다. 스포츠는 이를 가능하게 하는 구조를 완성했다. 고대 그리스 시절부터.

우리네 IT에게 결여된 것은 이러한 구조다. 우리는 왜 훌륭한 선수가 되지 못하냐는 질책은 있었지만, 어떠한 종목을 선택하는 것이 바람직한지 귀띔을 듣지 못했다. 그런 일을 태릉선수촌을 만든 정부에 기대해 보면 좋겠지만, IT에게 주어진 정책은 축구가 인기니까 6개월 과정으로 축구 선수를 배출하자는 근시안적인 방책뿐이었다. 그 덕에 98년에 엔터프라이즈 자바를 처음 하던 시절에 받던 ‘선생님’ 대우가, 불과 10년도 안돼 단순 노무직의 신세가 되어 버린다. 더 아이러니한 것은 10년 동안 아무리 훌륭한 축구 스킬을 쌓았어도 이를 알아 주는 이는 없고, 넘치는 축구 선수 지망생 속에 스트라이커는 묻혀 버린다. 오늘 아침 조기축구회에 처음 나온 이도 박지성도 모두 똑같은 과기처 단가표를 받아 든다. 그나마 다행히 박지성은 특급일 것이다.

더 큰 문제는 야구 선수마저 축구를 해야 하는 상황이다. 유난히 획일적인 사회 덕인지 모르지만, 어느 한 기술이 선택되면 업계 전체에 그 쏠림 현상은 무지막지하고, 여기에는 일종의 종교적 교조주의까지 가세한다. 눈치 보듯 동종 업계의 흐름을 뛰어 넘지 않는 RFP로 발주가 나고, 어느 누구도 새로운 것을 시도하지 않은 채 그저 그런 시스템이 계속 완성된다. 그리고 IT는 점점 새로운 것을 기피하며 혁신과 거리가 멀어진다.

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가.

어쩌면 국가나 정부의 정책이 밸런스를 맞추는 일은 애초에 무리일지 모른다. IT에서 일어나는 대부분의 변화는 정책 수행이나 입안 주체가 지닌 능력이나 태도의 문제나 차원을 넘어 초국가적 IT 트렌드의 결과이기 때문이니까. 그러나 아무리 글로벌화로 평평한 세계가 되어도 여전히 국가의 경계가 주는 문화적 경제적 사회적 기회의 차이는 지대하기에, 지렛대가 되어야 할 정책의 몫은 여전하다. 한 국가의 스포츠 정책이 생활 체육보다 엘리트 체육에 치중하는 이유도 이 차이의 가시적 해소를 위함이다. 왜 오프쇼어가 존재하는지, 왜 전세계의 IT 시스템이 여전히 미국발 플랫폼에 의존하고 있는지를 기억해 보자. 아무리 세계가 평평해져도 물리적 IT강국과 그 가치의 흐름은 존재한다.

한국 내에도 IT에 특화된 수많은 공공 단체들이 있지만 이에 대한 심도 깊은 고찰이 어디에서 이루어지고 있는 지 궁금하다. 예컨대 국가가 나서서 오픈소스를 이야기하지만, 오픈소스가 국내 개발자의 전체적 후생에 어떠한 영향을 미치는지 설명책임이 없다. 정책자 들은 오픈소스가 우리의 미래라고는 하지만, 우리에게는 아직 북구나 북미에서처럼 오픈소스 커미터로 활동하는 일에 대한 직업적 환경이 형성되지 못했다. 글로벌 벤더가 북구나 북미에서처럼 이들을 한국에서 고용하지도 않고, 또 그렇지 않더라도 돈을 받지 않고 연구에 몰두할 수 있는 사회적 안전망을 국가나 학계가 갖추어 주지 않는다. ‘스캔디나비안 객체 지향 학풍’, ‘핀란드의 기나긴 겨울’과 같은 은유적 여유조차 없는 우리에게 오픈소스는 ‘소프트웨어는 거저’라는 잘못된 인식의 획득뿐이고, 그 결과 세계에 기여는 안 하면서 가져다 쓰기만 하는 기형적 오픈소스 문화만 남게 되었다. 구조적 문제의 일례다.

도대체 무엇이 우리의 미래인가? IT 강국이라고 공염불은 하지만 그 실체는 없고, 참여자는 좌절하고 있다. 좋아서 시작은 했지만, 어떻게 하면 가치를 발휘할 수 있는지 알려 주지 않는다. 축구 선수는 늘어났지만 클럽이 없다. 운이 좋아 프로 축구단에 소속되면 다행이지만, 일부 개인에게 돌아간 이 요행을 산업 전체에 바랄 수는 없다. 그렇다면 야구가 있음을 알려야 한다. 올림픽을 열어야 한다. 세계 선수권에 나가야 한다. 새로운 종목에 도전해야 한다. 여자 양궁을 찾아야 한다. 쇼트 트랙을 찾아내야만 한다.

업계에 참여하는 개개인 모두가 IT의 미래를 날카롭게 읽어 내어 그 길을 내달리고 또 시장까지 열어 줄 수 있는 성과물을 만들어 주기를 바란다면 이는 욕심이다. 우리는 지금껏 그 욕심 속에서 자책해 왔다. 개인이 내달릴 수 있는 구조가 없는 곳에서, 개인이 움직여 주지 않는다 해봐야 아무 일도 일어나지 않는다.

다행히 구조의 왜곡을 먼저 읽어 내는 이들은 분명 존재한다. 그들은 기업인일수도, 마케터일수도, 에반젤리스트일수도, 블로거일수도, 정책가일수도, 혹은 이 글을 읽는 여러분 일수도 있다. 이 업계의 이 사회의 구조를 바꾸는 일, 우리의 몫이다. 구조 개혁은 어쩌면 길을 먼저 읽어 낸 이들의 책임이다. 미래란 그들이 뜯어 고칠 이 구조의 결과인 것이다. 개인은 구조의 영향을 받지만, 그 구조를 만드는 것은 개인이라는 사실. 이 것이 우리가 지닌 가장 큰 희망이기도 하다. @

Development

구글 그룹스 쓰레드

위의 구글 뉴스 그룹에서 찾은것으로.. 알고 보니 간단한데.. -_-;;

이것때문에 윈도우까지 새로 밀뻔 했다..

레지스트리에서, Visual Studio 관련 부분의 이름을 변경하거나, 삭제하여 프로그램이 실행될때 다시 레지스트리를 쓰게 만들어서 해결….

Development

출처 : 김명신의 즐거운 하루 블로그 

사실 Vista 는 정식출시 이전부터 ActvieX Control의 보안문제로 도마에 올랐었습니다.혹자는 “ActiveX Control을 쓰지말라는 이야기냐?” 라고 까지 물어보지만  조금 더 세심하게 살펴볼 필요가 있습니다.특히나 많은 분들은 IE7에서의 변경사항과 Vista에서의 IE7을 혼돈하여 이야기 하는 경우가 많기 때문에 이에 대해서도 조금 자세히 알아볼 필요가 있습니다.
IE 7의 새로운 기능에 대해서는 microsoft 사이트를 통해서 쉽게 확인하실 수 있습니다.
이렇게 처음으로 IE7의 새로운 기능을 이야기하는 이유는 앞으로의 내용이 IE7의 새로운 기능에 대해서 이야기를 할 것이 아니기 때문입니다.
Windows 2003 혹은 Windows XP 사용자를 위한 ActiveX Component를 개발하는 측면에서는 크게 달라진 것이 없습니다. 물론 세세하게 들어가면 몇몇 warning 창이 새로 생기고, 수행여부를 사용자에게 물어보기도 하고, ActiveX Component을 사용하지 못하도록 할 수도 있고 등등 이것저것 많습니다만 이건 순전히 사용자 측면이고 개발자들은 기존의 규칙을 잘 따르기만 하면 큰 문제는 생기지 않습니다. 이러한 환경에서는 여전히 ActiveX Component의 관리자의 권한을 얻을 수 있습니다.
이제는 Vista로 가볼 차례입니다. 가장 먼저 변경된 사항은 Vista IE 7에만 존재하는 보호모드(protected mode) 입니다. UAC와 관련된 내용을 일부 확인하셨다면 Administrators 그룹에 포함된 사용자라 하더라도 권한상승창을 통하지 않고는 관리자 권한으로 프로세스를 수행할 수 없다는 것 즈음을 아시고 계시리라 생각합니다. 그런데 보호모드란 녀석은 UAC보다 더 지독합니다. 왠만하면 아무것도 못하게 합니다.
이전의 OS에서는 아무런 제약없이 했던 파일쓰기나 레지스트리 추가/수정, 다른 서버로 연결하기 등은 모두 제한됩니다. 그래서 만일 관리자 권한이 필요한 작업을 수행하려면, ActiveX Component를 2개 만들어서 하나는 보호모드로 수행중인 iexplore.exe 프로세스 안에서 수행되게 놔두고 나머지 한녀석은 dllhost.exe라는 surrogate process가 hosting하도록 구성해야 합니다. 물론 이 과정에서 dllhost.exe는 관리자 권한을 가지고 수행될 수 있도록 조치를 해 두어야 합니다. 이 내용은 다음에 알아보기로 합시다. 사실 이러한 내용들은 모두 기존의 ActiveX 가 Vista에서도 정상적으로 동작하려면 어떻게 해야하는가에 대한 호환성과 관련된 내용입니다.
오늘 확인할 내용은 IE7에서 새로이 제공하는 함수인데 다 접어두고 구체적인 내용을 가지고 접근해 봅시다. 먼저 ActiveX Component내에서 IE가 현재 보호모드에서 수행중인지의 여부를 어떻게 확인하면 좋을까요? msdn에 새로 추가된 Internet Explorer 7 관련 API 목록을 살펴보면 바로 그 내용을 확인할 수 있습니다.
HRESULT IEIsProtectedModeProcess(BOOL *pbResult);
위 함수를 이용하면 ActiveX를 hosting하고 있는 현재의 IE process가 보호모드에서 돌고 있는지의 여부를 확인할 수 있습니다. 이 함수가 만일 FALSE를 반환하면 우리는 매우 happy합니다. 왜냐하면 위에서 말씀드린바와 같이 별 제약없이 모든 기능을 수행할 수 있을테니까요.
두번째로 알아볼 내용은, 저장가능한 Folder위치나 레지스트리 위치를 찾아내는 함수들입니다. 앞서 보호모드에서는 파일쓰기, 레지스트리 추가/수정 등이 제한된다고 했습니다만 다행히도 완전히 이런 기능이 불가능한 것만은 아닙니다. 앞으로 알아볼 특별한 위치에 대해서는 IE7이 보호모드에서 수행되고 있고, IE 프로세스 내부로 로딩된 ActiveX라 하더라도 쓰기가 가능합니다. (사실 IE7이 보호모드에서 수행된다 하더라도 여전히 temporary internet files 폴더 등에 파일을 저장하고 있지 않습니까?)
먼저 레지스트리상에 쓰기 가능 영역은 어떻게 얻어올 수 있을까요?
HRESULT IEGetWriteableHKCU(HKEY *phKey );
위 함수가 도움이 됩니다. 레지스트리상에 쓰기 가능영역은 HKEY_CURRENT_USER 이하에 위치하게 되고, 이곳의 위치를 알기 위해서는 위 함수를 반드시 이용해야 합니다 HKEY를 가져오게 되면, 그 다음은 레지스트리 관련 함수를 그대로 이용하면 되겠지요. 물론 이 함수에 의해서 획득된 HKEY에 대해서도 반드시 RegCloseKey() 함수로 close해주어야 함은 물론입니다.
다음은 로컬파일시스템 상에 쓸 수 있는 영역을 획득하는 방법에 대해서 알아봅시다. 위의 레지스트리의 예와 그다지 틀리지 않습니다.
HRESULT IEGetWriteableFolderPath(GUID clsidFolderID, LPWSTR *lppwstrPath );
첫번째 인자로 줄 수 있는 내용은, KnownFolders.h 파일에 정의된 내용중 하나가 올 수 있습니다만, 반환값을 확인하여 실제 접근이 가능한지 확인하여야 합니다. FOLDERID_InternetCache, FOLDERID_Cookies, FOLDERID_History, FOLDERID_LocalAppDataLow 을 지정할 수 있습니다. 주의할 것은 두번째 인자로 반환된 LPWSTR * 값은 추후 CoTaksMemFree()로 해제되어야 한다는 것입니다.
그외에도 몇가지 추가적인 함수들이 있는데, 목록만을 써보면 다음과 같습니다.
IECancelSaveFile
IEGetWriteableFolderPath : 앞서 알아본 함수
IEGetWriteableHKCU : 앞서 알아본 함수
IEIsProtectedModeProcess : 앞서알아본함수
IEIsProtectedModeURL
IELaunchURL
IESaveFile
IEShowSaveFileDialog
이에 대한 사용 예제는 Introduction to the Protected Mode API 를 통해 sample도 확인해 보시기 바랍니다.
결론적으로 Vista IE7 이 보호모드로 수행된다 하더라도, 제한적이긴 하지만 여전히 파일쓰기와 레지스트리 I/O 가능합니다. 따라서 ActiveX Component를 작성하실 때, 파일 I/O나 레지스트리 I/O가 필요하다고 해서 무조건 관리자 권한으로의 권한상승을 시도할 것이 아니라, 허용된 범위 내에서 동작하도록 ActiveX Component를 개발할 수 있는지의 여부를 먼저 확인하시기 바랍니다.

Development

출처 : 김명신의 즐거운 하루 블로그 

Administrators 권한이 있는 경우에만 정상적으로 수행될 수 있는 어플리케이션을 만들기 위해서는 manifest를 이용하여 ‘이 프로그램을 수행하기 위해서는 반드시 권한상승이 필요하다’는 정보를 실행파일에 포함시킬 필요가 있습니다.
물론, 오른마우스를 클릭해서 “관리자 권한으로 실행” 으로 어플리케이션을 수행하거나, ‘속성’에서 ‘관리자 권한으로 이 프로그램 실행’을 선택할 수도 있겠지만, 사용자에게 이렇게 어플리케이션을 수행할 것을 강요하는 것은 매우 어려운 일이기 때문에, 실행파일 자체에 ‘이 어플리케이션은 반드시 Administrators permission이 필요하다’ 라는 정보를 추가하여, 자동적으로 권한상승 창이 뜰 수 있도록 하는 것은 매우 중요합니다. 그런데 Visual Studio 2005 조차도 이러한 정보를 단숨에 실행파일에 추가하는 손쉬운 방법을 제공하지는 않습니다. (1. 아래 내용을 보면 아시겠지만 그렇다고 매우 복잡한것도 아닙니다. 2. 한편으로 보면 이는 매우 당연합니다. Visual Studio 2005가 Vista보다 미리 출시되었을 뿐더러 이러한 manifest를 추가하는 것은 단순히 특수한 type의 resource를 추가하는 것 이상의 동작이 아니기 때문입니다.) 게다가 managed code를 개발하느냐 혹은 C/C++와 같이 native code를 개발하느냐에 따라 그 방법이 서로 상이하기 때문에 조금은 혼돈스러울 수 있습니다.
앞서 말한 이러한 제약사항(본 어플리케이션은 반드시 Administrators 권한이 필요하다와 같은)은 manifest 라는 파일에 기록되게 되며, manifest 파일들은 실행파일에 추가(embedding)될 수 있습니다. manifest 파일의 일반적인 구조는 다음과 같습니다. 이 파일은 ‘실행파일명.exe.manifest’ 라는 파일로 저장하는 것이 좋습니다. ‘MyApp.exe’가 실행파일명이라면 ‘MyApp.exe.manifest’로 저장하시면 됩니다.

이제 실질적인 3가지 절차를 알아 봅시다. 
 
1. ‘Step by Step’ 방법
 
먼저 ‘실행파일명.rc’ 라는 이름의 빈파일을 만듭니다. ‘MyApp.rc’와 같이 만들면 됩니다. 아래와
같은 내용을 적습니다. 

#define RT_MANIFEST 24
#define APP_MANIFEST 1
APP_MANIFEST RT_MANIFEST MyApp.exe.manifest

위 의미는 RT_MANIFEST 형 resource로 APP_MANIFEST 라는 이름의 identifier를 “MyApp.exe.manifest” 라는 내용을 정의한다라는 의미입니다.(manifest 형 resource 구분자의 값은 항상 1로 정의하는 것이 좋습니다.
(참고적으로 파일내에 RT_MANIFEST 를 정의하는 대신 #include 를 포함시키는 것도 좋은 방법입니다. 하지만 이 경우 winuser.h 파일의 위치를 정의하기 위하여 추가적인 명령들을 설정해야할 수 있습니다. 또한 MyApp.exe.manifest 파일을 rc 파일과 분리된 파일로 두지 않고 rc 파일내에 쓸 수도 있습니다.)
이제 rc 파일을 컴파일하여 res 파일을 만듭니다. 컴파일 하는 방법은 다음과 같은 두가지 방법 중 한가지를 사용하면 됩니다.
command line prompt 에서 rc.exe /r MyApp.rc 를 입력합니다.
Visual Studio 2005 내에서 project properties를 선택하고 Build Event Tab의 Pre-Build event에 다음을 입력합니다.
“$(DevEnvDir)..\..\SDK\v2.0\bin\rc.exe” /r “$(ProjectDir)$(TargetName).rc”
(rc.exe 파일의 위치는 적절히 수정되어야할 수 있습니다.)
이제 컴파일된 resource를 실행파일에 추가하기 위한 절차를 수행합니다. 다음과 같은 2가지 방법이 있을 수 있습니다.
Visual Studio 2005나 MsBuild를 이용하는 방법
MyApp.csproj 파일을 열어서 볼드체로 표시된 내용을 다음과 같이 추가합니다.

…
MyApp.res
…
command line을 이용하여 컴파일 하는 방법
csc /win32res:MyApp.res MyApp.cs
vjc /win32res:MyApp.res MyApp.jsl
vbc /win32resource:MyApp.res MyApp.vb
 
2. mt.exe를 활용하는 방법
 
mt.exe 를 이용하면 이미 생성된 실행파일에 manifest 파일을 embedding할 수 있습니다. mt.exe를 활용하는 방법에도 2가지 방법이 있을 수 있습니다.
command prompt를 이용하여 다음과 같이 입력합니다.
mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;#1
여기서 #1 은 manfest 파일에 대한 resource identifier를 1로 정의한다는 의미입니다.
Visual Studio 2005 내에서 project properties를 선택하고 Build Event Tab의 Post-Build event에 다음을 입력합니다.
“$(DevEnvDir)..\..\VC\bin\mt.exe” -manifest “$(ProjectDir)$(TargetName).exe.manifest”  -outputresource:”$(TargetDir)$(TargetFileName)”;#1
 
3. Manifest Tool을 이용하는 방법
 
Visual Studio 2005를 이용하여 C++ 어플리케이션을 개발하고 있다면, 좀 더 손쉽게 manifest 파일을 embedding할 수 있습니다.
project properties를 선택하고 Configuration Properties->Manifest Tool을 선택한 후, Input and Output을 선택합니다. Additional Manifest Files 에 ‘MyApp.exe.manifest’ 와 같이 manifest 파일명을 입력하면 됩니다.
 
결론
이러한 3가지 방법중에 각각 선호하는 방법을 선택하면 되겠습니다만, 2번 방법을 이용하는 것이 가장 간단하면서도, managed/native의 구분없이 사용할 수 있으므로 가장 적절하지 않을까 생각됩니다.
 
다음 Link를 참고하십시오.
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment
.Net Security Blog : Adding a UAC Manifest to Managed Code
The Moth: Vista: User Account Control
How To: Tell Vista’s UAC What Privelege Level Your App Requires 

Development