VSPackage 설치 시나리오
유연성을 제공하도록 VSPackage 설치 관리자를 디자인하는 것이 중요합니다. 예를 들어 나중에 보안 패치를 릴리스해야 하거나 철저한 병렬 버전 관리 지원이 필요한 비즈니스 전략을 변경할 수 있습니다.
여러 버전의 Visual Studio 지원에서 VSPackage의 공유 또는 병렬 설치를 사용하여 Visual Studio의 병렬 설치를 지원하는 작업의 이점과 문제에 대해 읽어볼 수 있습니다. 간단히 말해서, 병렬 VSPackage는 Visual Studio의 새로운 기능을 지원하기 위한 가장 많은 유연성을 제공합니다.
이 항목에서 설명하는 시나리오는 유일한 선택 사항은 아니지만 제안된 모범 사례로 제공됩니다.
구성 요소, 프라이버시 및 공유
구성 요소를 독립적으로 만들기
구성 요소를 식별하고 채우고, GUID를 할당하고, 구성 요소를 배포한 후에는 해당 컴퍼지션을 변경할 수 없습니다. 구성 요소의 컴퍼지션을 변경하는 경우 결과 구성 요소는 새 GUID를 사용하는 새 구성 요소여야 합니다. 이 사실을 감안할 때, 각 구성 요소를 독립적이고 자립적인 단위로 만들면 가장 뛰어난 버전 관리 유연성이 제공됩니다. 구성 요소를 관리하는 규칙에 대한 자세한 내용은 구성 요소 코드 변경 및 구성 요소 규칙이 손상되면 어떻게 되나요?를 참조하세요.
구성 요소에서 공유 리소스와 프라이빗 리소스를 혼합하지 마세요.
참조 횟수는 구성 요소 수준에서 발생합니다. 따라서 공유 리소스와 프라이빗 리소스를 한 구성 요소에서 혼합하면 공유 리소스를 덮어쓰지 않고는 실행 파일과 같은 프라이빗 리소스를 업데이트할 수 없습니다. 이 시나리오에서는 이전 버전과의 호환성 문제를 만들고 병렬 기능을 만들지 못하도록 제한합니다.
예를 들어 VSPackage를 Visual Studio SDK에 등록하는 데 사용되는 레지스트리 값은 VSPackage를 Visual Studio에 등록하는 데 사용되는 구성 요소와는 분리된 구성 요소에 유지해야 합니다. 공유 파일 또는 레지스트리 값은 다른 구성 요소에 들어갑니다.
시나리오 1: 공유 VSPackage
이 시나리오에서는 공유 VSPackage(여러 버전의 Visual Studio를 지원하는 단일 이진 파일)가 Windows Installer 패키지에 제공됩니다. Visual Studio의 각 버전에 등록하는 작업은 사용자가 선택할 수 있는 기능에 의해 제어됩니다. 또한 별도의 기능에 할당된 경우 설치 또는 제거를 위해 각 구성 요소를 개별적으로 선택할 수 있으므로 사용자가 VSPackage를 여러 가지 버전의 Visual Studio에 통합하는 작업을 제어할 수 있습니다. (Windows Installer 패키지의 기능 사용에 대한 자세한 내용은 Windows Installer 기능을 참조하세요.)
일러스트레이션과 같이 공유 구성 요소는 항상 설치되는 Feat_Common 기능의 일부로 만들어집니다. Feat_VS2002 및 Feat_VS2003 기능을 표시함으로써 사용자는 설치 시 VSPackage를 통합하려는 Visual Studio 버전을 선택할 수 있습니다. 또한 사용자는 Windows Installer 유지 관리 모드를 사용하여 기능을 추가하거나 제거할 수 있습니다. 이 경우 여러 버전의 Visual Studio에서 VSPackage 등록 정보를 추가하거나 제거할 수 있습니다.
참고 항목
기능의 디스플레이 열을 0으로 설정하면 숨겨집니다. 낮은 수준 열 값(예: 1)을 사용하면 항상 설치됩니다. 자세한 내용은 INSTALLLEVEL 속성 및 기능 테이블을 참조하세요.
시나리오 2: 공유 VSPackage 업데이트
이 시나리오에서는 시나리오 1에서 업데이트된 버전의 VSPackage 설치 관리자가 제공됩니다. 설명을 위해 이 업데이트는 Visual Studio에 대한 지원을 추가하지만 더 간단한 보안 패치 또는 버그 수정 서비스 팩이 될 수도 있습니다. 최신 구성 요소를 설치하기 위한 Windows Installer의 규칙에 따라 시스템에 이미 있는 변경되지 않은 구성 요소는 다시 저장되지 않아야 합니다. 이 경우 버전 1.0이 이미 있는 시스템은 업데이트된 구성 요소 Comp_MyVSPackage.dll을 덮어쓰며 이를 통해 사용자는 해당 구성 요소 Comp_VS2005_Reg와 함께 새 기능 Feat_VS2005를 추가하도록 선택할 수 있습니다.
주의
VSPackage가 여러 버전의 Visual Studio 간에 공유될 때마다 VSPackage의 후속 릴리스는 이전 버전 Visual Studio와의 호환성을 유지 관리해야 합니다. 이전 버전과의 호환성을 유지 관리할 수 없는 경우 병렬, 프라이빗 VSPackage를 사용해야 합니다. 자세한 내용은 여러 버전의 Visual Studio 지원을 참조하세요.
이 시나리오에서는 부분 업그레이드에 대한 Windows Installer 지원을 활용하여 새로운 VSPackage 설치 관리자를 제공합니다. 사용자는 단순히 버전 1.1을 설치하고 이 버전이 버전 1.0을 업그레이드합니다. 그러나 시스템에 버전 1.0이 있을 필요는 없습니다. 동일한 설치 관리자가 버전 1.0이 없는 시스템에 버전 1.1을 설치합니다. 이 방식으로 부분 업그레이드를 제공하는 이점은 업그레이드 설치 관리자 및 전체 제품 설치 관리자를 개발하는 작업을 수행할 필요가 없다는 것입니다. 한 설치 관리자가 두 작업을 모두 수행합니다. 대신 보안 수정 또는 서비스 팩이 Windows Installer 패치를 활용할 수 있습니다. 자세한 내용은 패치 및 업그레이드를 참조하세요.
시나리오 3: 병렬 VSPackage
이 시나리오에서는 Visual Studio .NET 2003 및 Visual Studio의 각 버전에 하나씩 두 개의 VSPackage 설치 관리자를 제공합니다. 각 설치 관리자는 병렬 또는 프라이빗 VSPackage(특정 버전의 Visual Studio용으로 특별히 빌드 및 설치됨)를 설치합니다. 각 VSPackage는 자체 구성 요소에 있습니다. 따라서 각각은 패치 또는 유지 관리 릴리스를 사용하여 개별적으로 제공될 수 있습니다. VSPackage DLL은 이제 버전별로 다르므로 등록 정보를 DLL과 동일한 구성 요소에 포함해도 안전합니다.
각 설치 관리자에는 두 설치 관리자 간에 공유되는 코드도 포함됩니다. 공유 코드가 공통 위치에 설치된 경우 두 .msi 파일을 모두 설치하면 공유 코드가 한 번만 설치됩니다. 두 번째 설치 관리자는 구성 요소에 대한 참조 횟수를 증분시킵니다. 참조 횟수는 VSPackage 중 하나가 제거된 경우 다른 VSPackage에 대해 공유 코드가 유지되도록 합니다. 두 번째 VSPackage도 제거되면 공유 코드가 제거됩니다.
시나리오 4: 병렬 VSPackage 업데이트
이 시나리오에서 Visual Studio용 VSPackage에는 보안 취약성이 있으며 업데이트를 실행해야 합니다. 시나리오 2와 마찬가지로 보안 수정을 포함하도록 기존 설치를 업데이트하는 새 .msi 파일을 만들고 보안 수정이 이미 적용된 새 설치를 배포할 수 있습니다.
이 경우 VSPackage는 GAC(전역 어셈블리 캐시)에 설치된 관리형 VSPackage입니다. 보안 수정을 포함하도록 다시 빌드하는 경우 어셈블리 버전 번호의 수정 번호 부분을 변경해야 합니다. 새 어셈블리 버전 번호에 대한 등록 정보는 이전 버전을 덮어쓰기 때문에 Visual Studio에서 고정 어셈블리를 로드합니다.
병렬 어셈블리 배포에 대한 자세한 내용은 .NET Framework를 사용하여 배포 간소화 및 DLL 결함 해결을 참조하세요.