msi를 사용하여 설치하려는 dll을 몇 가지 있습니다.vsdraCOM은 코드베이스 경로가 빌드 경로를 가리 키도록합니다.
테스트 환경에서 우리는 regasm -codebase을 사용하여 dll을 등록합니다.
Google 검색에서 알 수 있듯이 register 속성을 vsdraCOM으로 설정하면 msi 프로젝트에서이를 수행 할 수 있습니다.
설치 프로그램을 실행하고 레지스트리를 검사 할 때 코드베이스 경로는 msi를 빌드 할 때 파일이 있던 경로로 설정됩니다.
저는 한스의 대답과 그 링크 정보를 확장하려고합니다. 그리고 그것은 논평 이상의 의미를 가질 수 있습니다.
그 등록 파일이 파일의 경로 및 링크 기사를 포함 할 파일이 응용 프로그램 폴더에 설치되어 있지 않은 경우 기본적으로 잘못 인 [TARGETDIR] 사용하는 것이 좋습니다. 파일 경로는 가져 오는 reg 파일에 [# file-key]로 작성되어야합니다. VS 설정 프로젝트에서 파일 키는 _B049230C37DE4B6787C578DCEE30252A와 같은 것입니다. Orca로 MSI 파일을 열고 파일 테이블로 이동하여 파일 이름에 해당하는 파일 열의 파일 키를 사용하십시오. 여기에서 오는
:
http://msdn.microsoft.com/en-us/library/aa368609%28v=vs.85%29.aspx
7 글 머리 기호. 이 파일은 설치되어있는 곳마다 파일 경로로 해석됩니다.
Visual Studio에서 잘못된 작업을 수행 한 다음 Orca를 사용하여 레지스트리 테이블로 이동하여 경로를 찾고 [# file 키] [# _B049230C37DE4B6787C578DCEE30252A]와 같은 위치에 넣을 수 있습니다. 사람들은 때로 MSI를 업데이트하기위한 게시 빌드 스크립트로 이러한 종류의 업데이트를 수행합니다.
위의 내용은 훌륭하지만 GAC를 사용하지 못하게해야합니다. VS 설치 프로젝트는 실제로 [#file key] 구문을 사용해야하며, 내가 생각하는 어리석은 버그 일뿐입니다.
전업 생방송으로 18 년 동안 설치 한 사람이라면, 내 첫 번째 제안은 Windows Installer XML로 전환하는 것입니다. .VDPROJ 사용을 주장한다면, 나는 읽을 것을 제안 할 것이다 : Redemption of Visual Studio Deployment Projects.
개념은 Windows Installer XML을 사용하여 병합 모듈을 만든 다음 .VDPROJ를 사용하여 해당 병합 모듈을 사용한다는 것입니다. Wix에서는 Heat를 사용하여 DLL을 수집합니다. COM/Regasm 메타 데이터를 추출하여 레지스트리 테이블 항목으로 작성합니다. 이는 제작 모범 사례를 사용하여 깨끗한 캡슐화를 제공하고 빌드 된 MSI 데이터베이스의 게시 빌드 해킹을 수행하지 않아도됩니다.
http://blogs.msdn.com/b/msiclickonce/archive/2010/08/03/vs-setup-project-vsdracom-sets-codebase-in-registry-to-point-to-the-sourcepath .aspx –
이것은 똑바로 보지 못했습니다. 다른 사이트에서도 추천 된 것으로 보았습니다. GAC에 넣는 것이 더 좋은 해결책일까요? 그러나 어떻게하면 msi를 통해 COM 등록을받을 수 있습니까? 다시 .reg 파일?. GAC에 넣는 것만으로는 충분하지 않은 것 같습니다. reg 파일을 둘러 볼 방법이 없습니까? –
글쎄, 일반적으로 살아있는 사람을 위해 설치 프로그램을 쓰는 사람들은 그것을 돌볼 구성 요소를 강력히 불신합니다. 그들은 레지스트리 키를 직접 작성합니다. 그리고 예, [ComVisible] 구성 요소 용 GAC를 사용하는 것은 매우 좋은 생각입니다. COM에는 매우 지저분한 DLL 지옥 문제가 있습니다. 예를 들어, Regasm.exe에서 꽤 볼 수 있습니다./codebase를 사용하면 큰 소리로 불평합니다. –