수안이의 컴퓨터 연구실고수닷넷 - 디버깅전문가님
1.요약
dll hell 을 방지하기 위한 방법 중 한가지로, local 폴더에 dll을 두고 혼자만 쓰는 방법을 들 수 있습니다. 그와 관련하여 재밌는 기능이 한 가지 있네요..
2.본문
예를 들어서, 여러분이 제작한 어플리케이션의 파일 이름이 MyApp.exe 라고 합시다.
MyApp.exe.local 이라는 파일을( 아무 내용없는 ) 하나 만들어서 같은 폴더에 두면, MyApp.exe 내에서 dll을 로드할 때는 같은 폴더의 dll을 먼저 로드하게 됩니다.
중요한 사실은, LoadLibrary() 에 절대 경로를 넘겨주는 경우나 COM 객체를 생성하는 경우라도, 무조건 같은 폴더의 dll을 먼저 로드한다는 점!! :)
--------------------------------------------------------------------------------
이와 관련된 질문이 있어서 검색을 해보았더니 MSDN에 더욱 자세하게 나와 있었습니다.
http://msdn.microsoft.com/library/kor/d ··· side.asp
--------------------------------------------------------------------------------
응용 프로그램의 side-by-side 구성 요소 공유 구현(확장)
David D'Souza, BJ Whalen, Peter Wilson
Microsoft Corporation
1999년 11월
요약: Windows 인증 사양에 설명된 바와 같이 Microsoft#® Windows® 2000 및 Windows 98 Second Edition의 side-by-side 공유 구성 요소 구현을 살펴봅니다. 또한 새로운 side-by-side 구성 요소를 만들고 DLL/COM 리디렉션을 사용하여 동일한 구성 요소의 다른 버전 간 비호환 문제를 처리하는 방법에 대해서도 설명하고, side-by-side 구성 요소를 작성하고 설치하는 방법과 응용 프로그램을 다시 패키지하고 테스트하는 방법에 대한 지침도 제시합니다(14페이지/인쇄 페이지 기준).
소개
간단한 배경 설명
새로운 구성 요소 공유 전략
두 가지 전략 비교
새로운 side-by-side 구성 요소 만들기
side-by-side 구성 요소 작성 지침
side-by-side 구성 요소 설치
DLL/COM 리디렉션
DLL/COM 리디렉션 사용
소개
요즈음의 운영 체제와 응용 프로그램들은 많은 구성 요소들로 구축됩니다. 구성 요소란 다양한 응용 프로그램에서 광범위하게 사용될 수 있는 함수 집합을 제공하는 독립적인 소프트웨어 엔터티를 말합니다. 개별 구성 요소는 여러 응용 프로그램에서 사용되므로 구성 요소 공유는 필수입니다.
전역 구성 요소를 성공적으로 공유하려면 공유된 구성 요소의 기능이 모두 이전 버전의 해당 구성 요소와 같아야 합니다. 그러나 공유 구성 요소가 사용될 모든 구성을 테스트하기란 어려우므로 실제로 이전 버전과의 100% 호환은 불가능합니다. 최신 버전과 이전 버전의 응용 프로그램이 모두 동일한 구성 요소를 사용하게 되므로 시간이 지날수록 이 구성 요소를 수정하고 향상시키는 것은 점점 어렵게 됩니다.
뿐만 아니라 구성 요소의 실제 기능을 정의하는 것도 쉽지 않습니다. 즉, 응용 프로그램이 구성 요소 핵심 기능의 일부로 여겨지지 않은 예기치 않은 부작용에 종속될 수도 있습니다. 예를 들어, 응용 프로그램이 구성 요소의 버그에 종속되어 구성 요소 개발자가 해당 버그를 수정하려고 하는 경우 응용 프로그램이 다운되어 "DLL Hell"이라는 상황이 발생할 수 있습니다. 또한 각 구성 요소를 사용하는 응용 프로그램들의 엄청난 볼륨은 이 문제를 심화시킬 뿐입니다.
이와 같이 이전 버전과의 호환성이 부족함으로 인해 이미 배포된 응용 프로그램을 중단시키거나 새 응용 프로그램의 기능을 손상시키지 않고서는 새 응용 프로그램을 배포할 수 없습니다. 새 응용 프로그램에는 이미 배포된 버전과는 다른 버전의 공유 구성 요소가 필요합니다. Microsoft에서는 응용 프로그램의 안정성을 높이면서 동시에 성공적으로 공유가 이루어질 수 있도록 하기 위해 Windows 2000과 Windows 98 Second Edition에 side-by-side 공유를 도입하여 선택적인 격리를 통해 구성 요소를 공유할 수 있도록 했습니다.
간단한 배경 설명
side-by-side 공유에 대해 자세히 알아보기 전에 몇 가지 배경 정보 및 DLL Hell 문제를 먼저 살펴보도록 합니다.
구성 요소 공유
Windows에서는 처음 등장할 때부터 공유라는 개념을 사용해 왔습니다. 모든 운영 체제에서는 강력하면서도 완벽하게 갖추어진 서비스를 제공하고자 하는 요구와 운영 체제가 설계된 대상 하드웨어의 리소스 제약 조건을 비교 검토해 봅니다. 최근까지만 해도 CPU 사용량과 디스크 공간이 PC 플랫폼에서 아주 제한된 리소스였으므로, 운영 체제와 응용 프로그램 코드를 좁은 공간에 맞추어 넣기 위한 가장 확실한 방법은 가능한 한 많은 코드를 공유하는 것이었습니다. 코드 공유에는 많은 장점이 있지만 그 중에서도 특히 하드웨어 리소스의 사용을 높이고 품질 보증 테스트를 거쳐야 할 부분을 최소화한다는 장점이 있습니다. 코드 공유는 Windows가 성공하게 된 요인 중 하나입니다.
Windows에서는 공유 기능이 코드에만 국한되지는 않습니다. 응용 프로그램 및 구성 요소 상태는 운영 체제 전역에서 레지스트리 상태, 파일 시스템의 응용 프로그램별 데이터 저장소, 전역 네임스페이스를 표시하는 Windows API 등의 형태로 확인할 수 있습니다. 이러한 공유 기능은 여러 소프트웨어 공급업체에서 만든 응용 프로그램들 간에 높은 수준의 상호 운용성을 제공하게 되므로 비용이 절감되고 소프트웨어 효율성이 높아지는 결과를 가져옵니다.
그러나 공유로 인해 문제가 되는 부분도 있습니다. 공유 기능으로 인해 응용 프로그램들이 상호 의존하게 되면서 응용 프로그램이 손상될 수도 있습니다. 즉, 한 구성 요소를 변경하면 다른 구성 요소에 예기치 않은 영향을 미칠 수도 있습니다. 일반적으로 응용 프로그램은 공유 구성 요소의 특정 버전에 의존하게 됩니다. 다른 응용 프로그램이 해당 공유 구성 요소의 업그레이드 또는 다운그레이드 버전과 함께 설치되는 경우 이러한 변경으로 인해 먼저 사용하던 응용 프로그램에 문제가 발생할 수 있습니다. 심한 경우에는 제대로 실행되던 응용 프로그램이 이상하게 작동하기 시작하거나 다운되기까지 합니다. 바로 이러한 경우를 대개 "DLL Hell"이라고 합니다.
격리
시스템에서 공유에 반대되는 개념이 바로 격리입니다. 모든 리소스와 코드를 응용 프로그램에 정적으로 바인딩하여 해당 응용 프로그램을 격리할 수 있습니다. 그러나 COM 또는 전역으로 저장된 다른 시스템 리소스를 사용하는 요즈음의 응용 프로그램의 경우에는 완벽한 격리가 불가능합니다.
응용 프로그램의 손상을 줄일 수 있는 방법 중 하나는 응용 프로그램과 구성 요소를 선택적으로 격리하는 것입니다. 이 시나리오에서는 응용 프로그램들이 모두 같은 구성 요소에 액세스하지만 해당 구성 요소의 여러 버전을 사용할 수 있습니다. 따라서 구성 요소 작성자는 언제든지 기능을 향상시키고 버그를 수정하면서 구성 요소의 새 버전을 만들 수 있고, 고객은 특정 응용 프로그램에 맞는 버전을 선택할 수 있습니다. 이는 자동차 부품 매장에 가서 1984년형 Chevy의 연료 펌프를 구입하는 것과 같습니다. 즉, 시간이 지나면서 다른 모델용 펌프와 나란히 판매되는 해당 모델용 펌프를 보게 됩니다. 구성 요소와 관련하여 중요한 것은 각 응용 프로그램에 해당하는 버전은 제공하고 다른 버전들은 서로 격리하는 것입니다. 또한, 리디렉션을 사용하면 현재 배포되어 있거나 앞으로 배포될 다른 버전들에 관계 없이 특정 응용 프로그램에 맞는 구성 요소 버전을 사용하도록 응용 프로그램을 구성할 수 있습니다.
Side-by-Side 공유
Microsoft Windows 2000과 Windows 98 Second Edition에서는 격리 사용을 권장하기 위한 일환으로 선택적 격리를 사용하여 DLL Hell을 최소화하는 side-by-side 공유라는 새로운 형태의 구성 요소 공유 기능을 도입하였습니다. side-by-side 공유를 사용하면 동일한 구성 요소(COM 또는 Win32®)의 여러 버전을 서로 다른 프로세스에서 동시에 실행할 수 있습니다. 그러면 응용 프로그램에서는 해당 응용 프로그램에 맞게 설계되고 테스트된 특정 버전의 구성 요소를 사용할 수 있습니다. 이 때 다른 응용 프로그램에서 동일한 구성 요소의 다른 버전을 필요로 하더라도 문제가 되지 않습니다. 따라서 개발자들은 시스템의 다른 응용 프로그램들에 관계 없이 자신의 응용 프로그램에 사용할 구성 요소의 버전을 지정할 수 있으므로 더욱 안정성 있는 응용 프로그램을 빌드 및 배포할 수 있습니다.
새로운 구성 요소 공유 전략
Windows 2000과 Windows 98 Second Edition의 side-by-side 공유는 다음 두 가지 전략을 따릅니다.
- side-by-side 구성 요소 만들기 개발자는 구성 요소의 여러 버전이 동시에 실행되도록 지원하는 새 구성 요소를 만듭니다. 이러한 새 구성 요소를 사용하는 사용자들은 이제 컴퓨터에 설치되어 있는 다른 버전들에 관계 없이 이 구성 요소들이 빌드 및 설치된 버전을 사용할 수 있습니다.
- DLL/COM 리디렉션 개발자와 관리자는 기존 응용 프로그램과 구성 요소를 다시 패키지하여 필요한 버전의 공유 구성 요소가 해당 응용 프로그램에 한정되어 다른 버전들과 함께 작용하도록 합니다.
side-by-side 구성 요소는 새로 만들어진 것이건 재구성된 기존 응용 프로그램의 일부이건 간에 모든 상황에서 지원되는 것은 아닙니다.
- 구성 요소가 다른 컨테이너 응용 프로그램 내로 호스트되는 도중 side-by-side 구성 요소를 만드는 경우가 대부분입니다. 예를 들어, Microsoft Visual Basic® 또는 Visual C++®로 작성된 데스크톱 Windows 응용 프로그램에서 컨트롤을 사용하려는 경우 바로 이러한 컨트롤들이 side-by-side 설계의 좋은 예가 됩니다. IIS 서버 컨텍스트 또는 MTS 서버에서는 side-by-side 구성 요소를 사용하지 않는 것이 좋습니다.
- DLL/COM 리디렉션이 주로 사용되는 경우는 새로운 클라이언트 응용 프로그램을 여러 개의 다른 응용 프로그램을 이미 지원하는 컴퓨터에 배포하려는 경우 또는 새로운 클라이언트 응용 프로그램이 다른 응용 프로그램 설치로 공유 구성 요소가 변경될 때 좀더 유연하게 반응해야 할 때입니다. IIS 서버 컨텍스트(Web 응용 프로그램) 또는 MTS/COM+1.0 서버에서는 DLL/COM 리디렉션을 사용하면 안 됩니다. Microsoft는 앞으로 이러한 상황에 대해 격리를 지정하는 다른 솔루션을 개발할 계획입니다. 리디렉션되지 않은 구성 요소는 이러한 환경에서 평소와 같이 지원됩니다.
참고 DLL/COM 리디렉션은 기존 응용 프로그램과 구성 요소가 배포될 때 응용 프로그램 충돌을 해결하는 데 중점을 둡니다. 새로운 응용 프로그램이나 새로운 구성 요소를 개발할 때에는 본질적으로 격리된 side-by-side 구성 요소를 개발하는 것이 가장 좋은 전략입니다.
두 가지 전략 비교
다음 표에서는 두 가지 방식, 즉 DLL/COM 리디렉션과 side-by-side(SxS) 구성 요소 만들기를 비교하여 상황에 따라 적합한 방식을 선택하는 데 도움이 되는 지침을 제공합니다.
표 1. Side-by-Side 전략 비교
| 특성 | SxS 구성 요소 | DLL/COM 리디렉션 |
|---|---|---|
| 가장 중점을 두고 있는 사항은 무엇입니까? | 이후 버전에서 구성 요소가 "이전 버전과 호환되지 않게" 하는 변경 사항이 발생해도 영향을 받지 않는 강력한 새 구성 요소를 작성하는 것입니다. | 호환되지 않는 공유 DLL을 설치하는 다른 응용 프로그램에서 발생하는 문제로부터 기존 응용 프로그램을 보호하는 것입니다. |
| 구성 요소의 특정 버전이 이 버전을 사용하는 응용 프로그램에 격리되어 있습니까? | 예. SxS 구성 요소는 이들을 사용하는 응용 프로그램에 항상 격리된 상태로 배포되어야 합니다. | 예. DLL/COM 리디렉션을 사용하는 응용 프로그램에서는 시스템의 다른 곳에 어떤 버전이 설치되어 있는지에 관계 없이 해당 응용 프로그램 디렉터리에 설치된 모든 공유 구성 요소의 버전을 사용합니다. |
| 새 코드 또는 기존 코드에 대한 변경이 필요합니까? | 예. SxS 구성 요소를 작성하거나 기존 구성 요소를 SxS로 만들려면 최소한 COM 등록 코드를 변경하여 상대 경로를 통한 액세스를 허용해야 합니다. SxS 실행 버전들 간에 전역 상태가 제대로 처리되는지 확인하기 위해 추가적인 코딩 변경이 필요할 수도 있습니다. | 아니오. DLL/COM 리디렉션을 사용하면 코드를 변경하거나 다시 컴파일하지 않고도 SxS를 설치하고 실행하도록 응용 프로그램을 다시 구성할 수 있습니다. 따라서 관리자는 응용 프로그램의 소스 코드에 액세스하지 않고도 응용 프로그램을 다시 구성하여 DLL Hell 문제를 처리할 수 있습니다. |
| 해당 전략을 모든 상황에서 사용할 수 있습니까? | 예. SxS 구성 요소는 SxS를 설치하고 실행할 수 있도록 설계 및 코딩되었습니다. 따라서 설계와 개발, 테스트가 적절히 이루어진 SxS 구성 요소와 이 구성 요소를 사용하는 응용 프로그램에서는 DLL Hell과 관련된 문제가 발생하지 않습니다. | 아니오. DLL/COM 리디렉션을 사용하면 코드를 변경할 필요가 없습니다. 기존 응용 프로그램과 구성 요소는 여러 개의 버전이 동시에 실행될 수 있어야 한다는 요구 사항을 기준으로 설계되지 않은 경우가 많습니다. 경험에 비추어 보면 대부분의 경우 기존 응용 프로그램과 구성 요소에서 SxS를 실행할 수 있지만 특정 상황에 대해서는 테스트를 통해 이를 확인해야 합니다(격리할 구성 요소 선택 참조). |
경험에 의한 일반적인 방법은 다음과 같습니다.
- DLL Hell 문제로 인해 기존 응용 프로그램 배포가 되지 않는 경우 DLL/COM 리디렉션을 사용하여 충돌하는 구성 요소를 격리합니다. 이 옵션을 좀더 자세히 이해하려면 아래 시나리오를 참조하십시오.
- 새로운 응용 프로그램을 작성할 때 DLL Hell 문제를 막을 수 있도록 설계하고 개발하려면 side-by-side 구성 요소를 개발합니다.
새로운 Side-by-Side 구성 요소 만들기
side-by-side 공유를 하려면 새로운 응용 프로그램을 만들 때 개발자가 side-by-side 구성 요소를 작성해야 합니다. side-by-side 구성 요소는 시스템 디렉터리가 아닌 응용 프로그램 디렉터리 또는 그 하위 디렉터리에 설치된다는 점을 제외하고는 일반 COM 또는 Win32 구성 요소와 다를 바가 없습니다. 이 구성 요소는 특정 응용 프로그램에 격리되며 모든 응용 프로그램 걸쳐 전역 공유가 이루어지지는 않습니다.
따라서 동일한 구성 요소의 다른 버전이 다른 곳에 설치되어 있는 상태에서 다른 응용 프로그램 디렉터리에 구성 요소를 안전하게 side-by-side로 설치할 수 있습니다. 시스템 상의 다른 응용 프로그램에서 다른 버전이 필요하여 설치하더라도 현재 응용 프로그램에는 영향을 주지 않습니다. 두 응용 프로그램이 모두 구성 요소의 해당 버전을 각각 사용하여 실행됩니다.
또 다른 응용 프로그램에서 새 버전의 구성 요소를 시스템에 설치하는 경우에도 해당 구성 요소의 현재 버전은 현재 응용 프로그램 디렉터리에 설치되어 있으므로 전혀 영향 받지 않고 그대로 유지됩니다. 현재 응용 프로그램은 응용 프로그램과 함께 제공되었던 동일한 버전의 구성 요소를 그대로 계속 사용하게 되고 다른 응용 프로그램은 해당 버전을 사용하게 됩니다. 두 가지 버전이 동시에 모두 운영 체제에 로드될 수 있습니다.
마찬가지로 side-by-side 구성 요소는 이를 설치한 응용 프로그램에 "한정되어" 있으므로 해당 응용 프로그램 설치 제거 프로그램에서도 항상 side-by-side 구성 요소를 안전하게 제거할 수 있습니다. 즉, 다른 응용 프로그램은 개인 구성 요소에 종속될 수 없습니다.
참고 Windows 2000과 Windows 98 Second Edition에서는 모두 side-by-side 공유를 지원합니다. 그 이전 버전의 Windows 운영 체제에서는 side-by-side 공유가 지원되지 않지만, 이 시스템에서는 side-by-side DLL(다음 단원의 지침에 따라 작성된 DLL)을 시스템 디렉터리에 설치할 수 있습니다. DLL을 시스템 디렉터리에 설치하면 이전 버전과 호환되는 전역 공유 방식으로 실행됩니다. 사용할 공유 기술을 결정하려면 응용 프로그램에서 운영 체제 버전을 동적으로 확인할 수 있어야 합니다.
DLL/COM 리디렉션 사용
DLL/COM 리디렉션을 사용하면 개발자나 관리자가 기존 구성 요소를 작성 및 배포 중인 응용 프로그램에 선택적으로 격리할 수 있습니다. 이 단원에서는 DLL/COM 리디렉션을 활성화하는 방법과 격리할 구성 요소를 선택하는 방법에 대해 설명합니다.
DLL/COM 리디렉션 활성화
DLL/COM 리디렉션은 ".local" 파일이 존재하면 응용 프로그램별로 활성화됩니다. ".local" 파일은 응용 프로그램의 .exe 파일과 같은 디렉터리에 있는 빈 파일로서 이름 끝에 ".local"이 추가된 응용 프로그램의 .exe 파일과 같은 이름을 사용합니다.
예를 들어, "myapp.exe"라는 응용 프로그램에 대해 DLL/COM 리디렉션을 활성화하려면 myapp.exe가 설치되어 있는 디렉터리에 "myapp.exe.local"이라는 빈 파일을 만듭니다.
DLL/COM 리디렉션이 일단 활성화되면 응용 프로그램에서 DLL이나 OCX를 로드할 때마다 Windows에서는 먼저 응용 프로그램의 .exe 파일이 설치되어 있는 디렉터리에서 DLL이나 OCX를 찾습니다. 응용 프로그램의 .exe 파일이 설치되어 있는 디렉터리에 DLL이나 OCX의 버전이 있으면 응용 프로그램에서는 응용 프로그램이나 레지스트리에 지정된 디렉터리 경로와 상관 없이 이를 사용합니다. 응용 프로그램의 .exe 파일이 설치되어 있는 디렉터리에 DLL이나 OCX의 버전이 없으면 기본 검색 경로나 서버 경로가 사용됩니다.
격리할 구성 요소 선택
DLL/COM 리디렉션을 사용하면 컴퓨터에 설치된 응용 프로그램에서 동일한 구성 요소의 여러 버전을 필요로 하는 경우 기존 구성 요소를 격리할 수 있습니다. DLL/COM 리디렉션이 일단 활성화되면 Windows 바인딩 동작이 변경되므로 구성 요소에 대한 코드를 변경할 필요가 없습니다.
그러나 지금까지는 구성 요소의 여러 버전을 side-by-side로 실행하는 것이 설계 작업에서 고려되지 않았습니다. 따라서 구성 요소를 side-by-side로 쉽게 설치, 즉 공유 위치에 설치하고 하나 이상의 응용 프로그램에 격리할 수는 있어도 해당 구성 요소가 side-by-side로 실행되지 않을 수 있습니다. 이는 일부 구성 요소들이 컴퓨터에는 항상 한 가지 버전의 구성 요소만 있을 것이라는 가정 하에 레지스트리에 저장된 설정과 같은 전역 상태를 사용하기 때문입니다. 뿐만 아니라 구성 요소는 필요한 다른 리소스를 찾을 때 자신이 설치되어 있는 특정 디렉터리에 대해 가정할 수 있습니다.
이와 같은 이유로 자체에 설치되어 있고 구성 요소가 격리된 다른 응용 프로그램의 컨텍스트에도 설치되어 있는 격리된 구성 요소를 사용하는 응용 프로그램을 반드시 테스트해야 합니다. 경험상 대부분의 경우에는 일반 공유 구성 요소를 side-by-side로 실행할 수 있지만 일부 경우에서는 다음 응용 프로그램을 실행하기 전에 응용 프로그램 하나를 닫아야 하는 경우도 있습니다.
격리할 구성 요소를 선택할 때에는 다음 지침을 따라야 합니다.
- 대부분의 .sys, .dll, .exe, .ocx 파일을 포함하여 Windows 2000과 함께 제공되는 시스템 파일 보호에서 보호하는 파일은 격리하지 마십시오.
- 현재 운영 체제에는 side-by-side 강화 기능이 없으므로 특히 공유가 이루어질 수 있는 영역에서 side-by-side 기능이 가능한지 확인하기 위해 모든 응용 프로그램을 테스트해야 합니다.
- 구성 요소는 이제 임의의 위치에 지정된 응용 프로그램 디렉터리에 들어 있으므로 구성 요소에 대한 변경 사항을 신속하게 반영할 수 없습니다. 관리자는 구성 요소를 수정해야 할 위치를 모두 알아야 합니다.
시나리오 I: ActiveX 컨트롤을 응용 프로그램에 한정
이 시나리오에서는 새 응용 프로그램에서 현재 배포된 응용 프로그램에 필요한 버전과는 다른 Visual Basic으로 작성된 ActiveX 컨트롤 버전을 사용하므로 관리자가 새 응용 프로그램을 배포할 수 없습니다.
시간이 지나면 버그 수정과 ActiveX 컨트롤에 대한 수정으로 의미의 차이가 생기므로 이 컨트롤을 사용하는 응용 프로그램에서는 테스트할 때 사용한 버전을 사용하지 않으면 문제가 생깁니다. 관리자는 ActiveX 컨트롤의 여러 가지 버전을 이를 사용하는 다른 응용 프로그램과 함께 실행하여 ActiveX 컨트롤이 변경될 때 영향을 받는 응용 프로그램을 모두 수정하고 다시 테스트하지 않아도 되도록 할 수 있어야 합니다.
관리자는 새로운 응용 프로그램에서 정확한 버전의 ActiveX 컨트롤을 사용하도록 할 수 있으며, 새로운 응용 프로그램의 설치를 다음과 같이 수정하여 기존 응용 프로그램 구성이 변경되지 않도록 할 수 있습니다.
- ActiveX 컨트롤의 새로운 버전을 응용 프로그램의 .exe 파일이 있는 디렉터리에 설치합니다.
- 이 응용 프로그램이 실행될 때마다 응용 프로그램의 .exe 파일이 있는 디렉터리에서 ActiveX 컨트롤이 로드되어야 함을 지정하는 .local 파일을 응용 프로그램의 .exe 파일이 있는 디렉터리에 설치합니다.
시나리오 II: Win32 DLL을 응용 프로그램에 한정
이 시나리오에서는 관리자가 새 응용 프로그램이 배포된 후 기존 응용 프로그램 실행이 중지된 것을 알게 됩니다. 즉, 관리자는 공유 구성 요소가 수정되어 이전 버전과의 호환성을 지원하지 않는 새로운 버전의 공유 구성 요소가 만들어짐으로써 문제가 발생했음을 확인할 수 있습니다.
관리자는 다음 단계를 수행하여 응용 프로그램을 수정할 수 있습니다.
- 이전 버전의 공유 DLL을 기존 응용 프로그램의 .exe 파일이 있는 디렉터리에 설치합니다.
- 기존 응용 프로그램의 .exe 파일이 있는 디렉터리에 .local 파일을 만듭니다. .local 파일은 응용 프로그램이 실행될 때 응용 프로그램의 .exe 파일이 있는 디렉터리에서 DLL이 로드되도록 지정합니다.
격리된 COM 서버 설치 시 고려 사항
DLL/COM 리디렉션은 DLL 또는 OCX 파일을 해당 응용 프로그램 전용의 새 위치에 설치하는 방식으로 수행됩니다. 그러나 COM 서버에 연결된 다른 시스템 상태는 격리되지 않는데 이것은 COM 서버 격리에 몇 가지 특별한 의미를 부여합니다.
격리된 COM 서버를 설치할 때에는 다른 응용 프로그램 등에 의해 구성 요소의 임의의 버전이 컴퓨터에 이미 설치되어 있는지, InprocServer 파일 위치가 격리된 구성 요소의 새 위치로 덮어쓰여지지 않았는지를 확인해야 합니다. 격리된 COM 서버에서는 런타임에 InprocServer 파일 위치가 무시되지만, DLL/COM 리디렉션을 사용하지 않는 기존 응용 프로그램에서는 InprocServer 파일 위치가 이전에 설치된 COM 서버 위치를 계속 지정하고 있어야 합니다. 이것이 의미하는 바는 다음과 같습니다.
- 격리된 COM 서버를 설치할 때 임의의 COM 서버 버전이 컴퓨터에 이미 설치되어 있는 경우 격리된 COM 서버를 설치 시점에 등록하면 안 됩니다.
반대로, 격리된 COM 서버 버전이 컴퓨터에 설치되어 있지 않은 경우에는 등록해야 합니다. COM 서버가 응용 프로그램에 격리되고, 응용 프로그램의 .exe 디렉터리에 설치된 다음, 해당 구성 요소를 필요로 하는 격리되지 않은 응용 프로그램이 나중에 설치되는 경우 이러한 문제 상황이 발생합니다. 이 경우 격리된 응용 프로그램을 제거하면 격리된 COM 구성 요소가 공유 파일처럼 처리되지 않으므로 다른 응용 프로그램이 손상됩니다. 이것이 의미하는 바는 다음과 같습니다.
- 격리된 COM 서버를 설치할 때 COM 서버 버전이 컴퓨터에 설치되어 있지 않은 경우 DLL 또는 OCX 파일을 응용 프로그램의 .exe 디렉터리와 시스템 디렉터리(또는 다른 공유 위치)에 모두 복사하고 해당 복사본을 시스템 디렉터리(또는 다른 공유 위치)에 등록합니다.
일부 응용 프로그램에서 버전을 공유하기도 하고 다른 버전은 그 밖의 응용 프로그램에 한정되어 있기도 한 기존 구성 요소의 경우, 경험상 다음과 같은 방법을 사용할 수 있습니다. 공유 구성 요소의 격리된 버전을 사용하는 응용 프로그램을 설치한 후 구성 요소의 공유 버전과 격리 버전이 모두 설치되었는지, 공유 버전이 등록되었는지를 확인합니다. 이렇게 하면 설치 제거 관리자에서 다른 응용 프로그램을 손상시키지 않으면서 격리된 버전을 제거할 수 있습니다.
- 어플리케이션 모드에서 인자값 처리 (0)2006/12/01
- Watch 창에서 함수 실행하기 (0)2006/12/01
- 로컬 폴더에 있는 dll 사용하게 만들기 (0)2006/12/01
- VB로 작성한 DLL을 VC에서 호출하는 방법 (0)2006/12/01
- Safe TerminateProcess() (1)2006/11/29
Leave your greetings.