2012-03-14 2 views
-1

우리는 InstallShield를 사용하여 매우 유사한 여러 제품의 설치 프로그램을 빌드합니다. 각 제품은 공급 업체 디렉토리 아래의 고정 디렉토리에 파일을 공유합니다. 우리는 설치 프로그램이 처리해야하는 DLL 지옥 문제가 있습니다.InstallShield로 DLL 지옥을 진단/관리하는 방법은 무엇입니까?

제품 A와 B는 모두 파일 FOO가 있고 디렉토리 D에 설치되어 있다고 가정합니다. FOO는 반드시 DLL 일 필요는 없습니다. 모든 파일이 될 수 있습니다.

FOO의 두 복사본은 동일하며 두 제품을 모두 설치하면 FOO가 D에서 덮어 쓰여지고 모든 것이 정상입니다. 모든 것이 동일 할 때 그것이 작동하는 것처럼 보입니다.

실제로 A와 B는 서로 다른 세대에서 나올 수 있으므로 실제로 A는 FOO 변형 A (FOO_a)를 가지며 B는 변형 FOO_b를 갖습니다. 두 제품이 모두 설치되면 FOO_a 또는 FOO_b 중 하나만 D에 끝나게됩니다. 따라서 잘못된 파일이 있기 때문에 A 또는 B 중 하나가 혼동됩니다.

설치 관리자 (및 InstallShield)에서 예상 한 것은 시스템에 설치된 각 제품 P에 대해 참조 카운터가 설치된 각 파일에 대한 레지스트리 (어딘가)에 보관된다는 것입니다. 따라서 A가 설치되고 FOO (_a)가 배치되면 FOO는 A에 속하는 것으로 표시되고 참조 수는 1로 설정됩니다. B가 FOO_a와 동일한 FOO_b와 함께 설치되면 FOO는 B에도 속한 것으로 표시되어야합니다 , 그리고 증가 된 참조 카운트. B가 설치되어 있고 FOO_b가 FOO_a와 다른 경우 설치 프로그램이 호환되지 않는 파일 FOO가 설치 제안으로 제안되고 설치가 중단되어야한다고 불평 할 것으로 예상됩니다. 제품을 설치 제거 할 때마다 설치된 각 파일에 대한 참조 카운터가 감소되고 참조 파일 수가 0 일 때만 설치된 파일이 제거됩니다.

그건 InstallShield가하는 것처럼 보이지 않습니다. 설치하는 동안 FOO를 대상 디렉토리로 분쇄합니다. 이것은 실제로 DLL 지옥과 같은 것입니다. 이것이 설치 관리자의 의도 된 동작입니까? InstallShield? Windows의?

우리는 InstallShield에서이 문제를 관리하도록 요청했지만 아무것도 찾을 수 없다고 생각했습니다. 나는 이것을 올바르게 구성하기 위해 어디에서 누군가를 찾아야하는지 기뻐할 것입니다. 또는 InstallShield가이를 수행 할 수 없거나하지 않을 것인가? [그렇다면 왜 내가 돈을주는거야?]

+1

InstallScript, Windows Installer를 사용하는 프로젝트 유형은 무엇입니까? 이는 모범 사례와 예상되는 행동에 대한 토론을 설정하는 데 중요합니다. 또한 InstallShield가 돈을 받고 마술처럼 일하는 것에 비난하는 것은 비생산적인 것이라고 생각합니다. 이 문제를 올바르게 해결하려면 몇 가지 생각과 노력이 필요합니다. (나는 XML 파일에 대해 what-ifs로 마음을 날릴 수있다.) –

+0

나는 실제 일하는 사람이 아니기 때문에 나중에 "어떤 유형을 사용하고 있는가"를 수집해야 할 것이다. 나는 InstallShield를 비난하지 않는다; IF에 주목하십시오. 실제로 묻히는 질문은 그것을 할 수있는 방법이 있다고 가정하고, 나는 이것을 InstallShield에 원한다고 설명하는 부분에 대한 확인과 힌트를 요구하고 있습니다. –

+0

이것은 패키지 관리자가 존재하는 이유입니다 ... 바보 같은 Windows는 이전에 주석을 넣으려고 – alternative

답변

1

진정한 해결책을 찾고 있다면 별도의 DLL을 사용하십시오. 이는 간단하고 신뢰할 수 있으며 사실 FOO_a 및 FOO_b에 대해 언급 한 것처럼 쉽게 이야기 할 수 있습니다. 또한 사용자에게 도움이되지 않는 오류 메시지를 피할 수 있습니다.

Windows에는 공유 DLL에 대한 참조 계산 체계가 있지만 규칙 상으로는 신뢰할 수 없습니다. 제거 프로그램에서 공유 구성 요소를 정말로 삭제할지 묻는 메시지가 표시되면 이제 이유를 알 수 있습니다.

+0

내가 말하는 파일은 DLL이 아닙니다. 그것들은 우리 제품이 기대하거나 사용하는 다양한 파일, 텍스트, HTML, 일부 바이너리입니다. 참조 횟수도 그들에게 달려있다. ... Windows *가 가지고 있었습니까, 아니면 여전히 * 가지고 있습니까? DLL 또는 임의 파일에 대해서만? 우리는 설치자를 통제하고 있습니다. 우리를 제외하고는 디렉토리에 뭔가를 설치할 이유가 없습니다. 따라서 동일한 설치 프로그램을 사용하고 참조 횟수를 관리 할 수 ​​있다면 더 이상 관습에 따르지 않습니다. –

+0

참조 계산은 단순히 카운터가있는 레지스트리 항목이었습니다. 혼자서도 똑같은 일을 할 수없는 이유가 없습니다. 그러나 IMHO, 당신은 여전히 ​​공유하기보다는 분리 된 공간에서 더 나을 것입니다. 공유함으로써, 당신은 DLL 지옥의 자신 만의 등가물을 만들 수 있습니다. – jdigital

0

순수 MSI 기반 설치 프로그램을 사용하는 경우 참조 카운팅 작동 방식이 정확하다고 생각합니다. A와 B가 기본 MSI 또는 InstallScript 프로젝트인지 확인하는 데 도움이됩니다. 어쨌든, A와 B 설치 프로젝트의 FOO를 포함하는 구성 요소가 키 파일로 설정되고 Shared 특성이 Yes로 설정되어 있는지 확인합니다. 그것은 참조 카운팅을 올바르게 관리해야합니다.

설치 프로그램을 실행할 때 어떤 일이 발생할지에 관해서는 파일의 버전이 최신 버전이든 아니든 대부분 파일 버전에 따라 달라 지므로 최신 버전의 공유 파일이 있습니다. 마지막으로 변경된 시간 소인. FOO_a와 다른 FOO_b가 포함 된 B 용 설치 프로그램을 작성하는 경우 InstallShield가 A를 깨뜨릴 수 있다는 것을 알 수 없습니다 (잘못되었거나 잘못되었을 수 있음).가능한 한 가지 해결 방법은 사용자 지정 작업을 사용하여 FOO_b가 다른지 확인하고 설치되어있는 경우 설치 초기에 기존 복사본을 만든 다음 프로세스가 끝나면 다시 복사합니다.

+0

Windows 또는 InstallShield가 가질 수있는 형식의 파일에는 버전 번호가 없습니다. 우리는 틀림없이 각 파일의 설치 프로그램에 이러한 버전 번호를 제공 할 수 있지만 "바이너리 파일 이미지는 비 호환 성 테스트와 일치하지 않습니다"라는 메시지만으로도 충분합니다. –

1

사용중인 설치 기술을 알지 못하면 아무도 질문에 대한 답변을 시작할 수 없습니다. InstallShield는 다양한 프레임 워크를 지원하는 제품입니다.

Windows는 DLL 파일의 공유 참조를 추적합니다. (SharedDllCount). Windows Installer (심지어 사용 중이라고 가정)는 Compoent 참조 횟수를 추적합니다.

그러나 Windows Installer를 사용하는 IF 파일을 덮어 쓰기로 결정한 파일 비용 계산 프로세스에는 참조 횟수와 아무런 관련이 없습니다. 참조 횟수는 제거시에 나타납니다. 또한 볼

File Versioning Rules

: 당신을 가정

는 Windows Installer가, 살펴보고 사용하는

What happens if the component rules are broken?

이 *입니다 Windows 설치 및 InstallShield 설치 방법을 처리하기 위해 알고있는 올바르게 구현한다고 가정합니다. 모든 프로그래밍 언어는 의도적으로 오용되거나 남용 될 수 있습니다.

2

FOO의 변형 버전이 적절히 누적되면 (공유 위치에서 작동하는 모든 설치 기술의 핵심) 구성 요소가 공유되는 경우 두 제품 (MSI 인 경우)에서 동일한 GUID를 공유하고 동일한 설치 위치라면 모든 것이 작동 할 것입니다. 그 조건들의 목록이 진실이 아니기 때문에 여러 가지 나쁜 것들이 일어날 수 있고 일어날 것입니다. 일부는 해결 방법이 있으며 일부는 복구 할 수 없습니다.

  • 설치 위치가 다른 경우 두 제품이 다른 이유로 동일한 위치에서 검색되지 않는 한 이러한 사항은 거의 또는 전혀 없습니다.
  • MSI와 GUID가 다르거 나 구성 요소의 내용이 다른 경우 구성 요소 규칙이 잘못되었습니다. 이로 인해 최종 제거시 파일이 제거되지 않거나 예기치 않은 복구 변경 사항 또는 기타 결과 예측이 어려워 질 수 있습니다.
  • 파일의 버전이 적절하지 않으면 다른 파일로 바꿀시기를 알 수 없습니다. 일부 주문에서는 새로운 설치가 이전 버전과 함께 실행됩니다. 다른 파일의 버전이 적절하게 증가하면 MSI에서 파일을 첨부하여이 문제를 완화 할 수 있습니다.
  • 파일이 버전과 관련하여 누적되지 않은 경우 파일의 새 버전이 다른 파일을 손상시킬 수 있습니다. 이 시나리오에서는 공유 위치에 설치하지 마십시오.

하나의 크기는 때로는 조금 혼란 스럽기 때문에 일반적으로 문제 공간은 해결할 수있는 것으로 단순화됩니다. 이 경우 비용은 모든 설치 작성자가 잘 정의 된 동작을 원한다면 몇 가지 규칙을 따라야한다는 것입니다.

1

파일을 공통적으로 사용하지 않으려면 왜 전 세계에서 같은 디렉토리에 배치해야합니까? 차라리 서로 다른 위치에 놓을 것입니다. 이제 FOO_a가 동일한 버전의 여러 프로그램에서 사용되고 있다고 가정하고, 새 프로그램에서 필요로하는 FOO_b와 나중에 추가 될 수있는 다른 FOO_b에 대해 비슷한 이름의 공통 디렉토리를 추가하고 세대 이름 등을 사용하여 이름을 지정하십시오.

+0

실제로 대부분의 경우 파일 *이 공통적이며 많은 파일이 있기 때문에, 별도의 사본을 갖는 것은 무의미한 것으로 보이고 공유 사본을 갖는 것은 공유 디렉토리에서 하나를 볼 수 있다는 것을 의미합니다. 공유 파일이 다른 경우는 거의 없습니다. 그것들이 다르지 않을 때 조각들은 아름답게 겹쳐집니다. 파일이 다를 때 (시간이 지남에 따라 느린 진화), OK를 별도의 디렉토리에 설치하십시오. –

관련 문제