프로젝트 업그레이드

Visual Studio의 한 버전에서 다음 버전으로 프로젝트 모델을 변경하려면 최신 버전에서 실행할 수 있도록 프로젝트 및 솔루션을 업그레이드해야 할 수 있습니다. Visual Studio SDK는 사용자 고유의 프로젝트에서 업그레이드 지원을 구현하는 데 사용할 수 있는 인터페이스를 제공합니다.

업그레이드 전략

업그레이드를 지원하려면 프로젝트 시스템 구현에서 업그레이드 전략을 정의하고 구현해야 합니다. 전략을 결정할 때 SxS(Side-by-Side) 백업, 복사 백업 또는 둘 다를 지원하도록 선택할 수 있습니다.

SxS 백업은 프로젝트가 현재 위치에서 업그레이드해야 하는 파일만 복사하여 적절한 파일 이름 접미사(예: ".old")를 추가한다는 것을 의미합니다.
복사 백업은 프로젝트가 모든 프로젝트 항목을 사용자가 제공한 백업 위치에 복사한다는 것을 의미합니다. 그런 다음 원래 프로젝트 위치의 관련 파일이 업그레이드됩니다.

업그레이드 작동 방식

이전 버전의 Visual Studio에서 만든 솔루션이 최신 버전에서 열리면 IDE는 솔루션 파일을 확인하여 업그레이드해야 하는지 확인합니다. 업그레이드가 필요한 경우 업그레이드 마법사 가 자동으로 시작되어 사용자가 업그레이드 프로세스를 안내합니다.

솔루션을 업그레이드해야 하는 경우 각 프로젝트 팩터리에서 업그레이드 전략을 쿼리합니다. 이 전략은 프로젝트 팩터리에서 복사 백업 또는 SxS 백업을 지원하는지 여부를 결정합니다. 정보는 백업에 필요한 정보를 수집하고 사용자에게 적용 가능한 옵션을 제공하는 업그레이드 마법사로 전송됩니다.

다중 프로젝트 솔루션

솔루션에 여러 프로젝트가 포함되어 있고 업그레이드 전략이 다른 경우(예: SxS 백업만 지원하는 C++ 프로젝트 및 복사 백업만 지원하는 웹 프로젝트) 프로젝트 팩터리가 업그레이드 전략을 협상해야 합니다.

솔루션은 각 프로젝트 팩터리에서 IVsProjectUpgradeViaFactory를 쿼리합니다. 그런 다음 전역 프로젝트 파일을 업그레이드해야 하는지 확인하고 지원되는 업그레이드 전략을 결정하도록 호출 UpgradeProject_CheckOnly 합니다. 그런 다음 업그레이드 마법사 가 호출됩니다.

사용자가 마법사 UpgradeProject 를 완료한 후 각 프로젝트 팩터리에서 실제 업그레이드를 수행하도록 호출됩니다. 백업을 용이하게 하기 위해 IVsProjectUpgradeViaFactory 메서드는 업그레이드 프로세스의 세부 정보를 기록하는 서비스를 제공합니다 SVsUpgradeLogger . 이 서비스는 캐시할 수 없습니다.

모든 관련 전역 파일을 업데이트한 후 각 프로젝트 팩터리는 프로젝트를 인스턴스화하도록 선택할 수 있습니다. 프로젝트 구현은 IVsProjectUpgrade을 지원해야 합니다. UpgradeProject 그런 다음 모든 관련 프로젝트 항목을 업그레이드하기 위해 메서드를 호출합니다.

비고

이 메서드는 UpgradeProject SVsUpgradeLogger 서비스를 제공하지 않습니다. 이 서비스는 호출 QueryService하여 가져올 수 있습니다.

모범 사례

SVsQueryEditQuerySave 서비스를 사용하여 파일을 편집하기 전에 편집할 수 있는지 확인하고 저장하기 전에 저장할 수 있습니다. 이렇게 하면 백업 및 업그레이드 구현에서 소스 제어 아래의 프로젝트 파일, 권한이 부족한 파일 등을 처리하는 데 도움이 됩니다.

SVsUpgradeLogger 백업 및 업그레이드의 모든 단계에서 서비스를 사용하여 업그레이드 프로세스의 성공 또는 실패에 대한 정보를 제공합니다.

프로젝트 백업 및 업그레이드에 대한 자세한 내용은 vsshell2.idl의 IVsProjectUpgrade에 대한 주석을 참조하세요.

사용자 지정 프로젝트 업그레이드

다른 Visual Studio 버전의 제품 간에 프로젝트 파일에 유지되는 정보를 변경하는 경우 프로젝트 파일을 이전 버전에서 새 버전으로 업그레이드하도록 지원해야 합니다. Visual Studio 변환 마법사에 참여할 수 있는 업그레이드를 지원하려면 인터페이스를 구현합니다IVsProjectUpgradeViaFactory. 이 인터페이스에는 복사 업그레이드에 사용할 수 있는 유일한 메커니즘이 포함되어 있습니다. 프로젝트의 업그레이드는 솔루션의 일부가 열리면 발생합니다. 인터페이스는 IVsProjectUpgradeViaFactory 프로젝트 팩터리에 의해 구현되거나 적어도 프로젝트 팩터리에서 얻을 수 있어야 합니다.

인터페이스를 IVsProjectUpgrade 사용하는 이전 메커니즘은 계속 지원되지만 프로젝트 시스템을 열린 프로젝트의 일부로 개념적으로 업그레이드합니다. Visual Studio 환경에서는 인터페이스가 IVsProjectUpgradeViaFactory 호출되거나 구현된 경우에도 IVsProjectUpgrade 인터페이스를 호출합니다. 이 접근 방식을 사용하면 IVsProjectUpgradeViaFactory을(를) 활용하여 복사를 구현하거나 업그레이드의 일부 프로젝트 부분만 수행하고, 나머지 작업은 IVsProjectUpgrade 인터페이스를 통해 현재 위치 또는 새 위치에서 직접 처리되도록 위임할 수 있습니다.

샘플 구현 IVsProjectUpgrade은 VSSDK 샘플을 참조하세요.

다음 시나리오는 프로젝트 업그레이드에서 발생합니다.

파일이 프로젝트에서 지원할 수 있는 것보다 최신 형식인 경우 이를 나타내는 오류를 반환해야 합니다. 이 경우 이전 버전의 제품에 버전을 확인하는 코드가 포함되어 있다고 가정합니다.
메서드에 PUVFF_SXSBACKUP 플래그를 UpgradeProject 지정하면 프로젝트를 열기 전에 업그레이드가 현재 위치 업그레이드로 구현됩니다.
메서드에 PUVFF_COPYBACKUP 플래그를 UpgradeProject 지정하면 업그레이드가 복사 업그레이드로 구현됩니다.
호출에 UPF_SILENTMIGRATE UpgradeProject 플래그가 지정된 경우 프로젝트를 연 후 환경이 프로젝트 파일을 현재 위치 업그레이드로 업그레이드하라는 메시지가 사용자에게 표시됩니다. 예를 들어 환경은 사용자가 이전 버전의 솔루션을 열 때 업그레이드하라는 메시지를 표시합니다.
호출에 UPF_SILENTMIGRATE UpgradeProject 플래그가 지정되지 않은 경우 사용자에게 프로젝트 파일을 업그레이드하라는 메시지를 표시해야 합니다.

다음은 업그레이드 프롬프트 메시지의 예입니다.

"프로젝트 '%1'은 이전 버전의 Visual Studio를 사용하여 만들어졌습니다. 이 버전의 Visual Studio로 열면 이전 버전의 Visual Studio에서 열 수 없습니다. 이 프로젝트를 계속 열고 싶으신가요?"

IVsProjectUpgradeViaFactory를 구현하려면

인터페이스의 IVsProjectUpgradeViaFactory 메서드, 특히 프로젝트 팩터리 구현의 UpgradeProject 메서드를 구현하거나 프로젝트 팩터리 구현에서 구현을 호출할 수 있도록 합니다.
솔루션을 열 때 제자리 업그레이드를 수행하려면 PUVFF_SXSBACKUP 플래그 VSPUVF_FLAGS를 UpgradeProject 매개 변수로 구현에서 제공합니다.
솔루션 열기의 일부로 현재 위치 업그레이드를 수행하려면 구현에서 PUVFF_COPYBACKUP 플래그 VSPUVF_FLAGS 를 UpgradeProject 매개 변수로 제공합니다.
2단계와 3단계를 위해, 실제 파일 업그레이드 단계를 IVsQueryEditQuerySave2을 사용하여 구현하거나 아래 "구현 IVsProjectUpgade" 섹션에 설명된 대로 구현할 수 있으며, 또는 실제 파일 업그레이드를 IVsProjectUpgrade에 위임할 수 있습니다.
Visual Studio 마이그레이션 마법사를 사용하여 업그레이드 관련 메시지를 사용자에게 게시하기 위해 IVsUpgradeLogger 메서드를 사용합니다.
IVsFileUpgrade 인터페이스는 프로젝트 업그레이드의 일부로 수행해야 하는 모든 종류의 파일 업그레이드를 구현하는 데 사용됩니다. 이 인터페이스는 IVsProjectUpgradeViaFactory에서 호출되지 않고, 프로젝트 시스템의 일부인 파일을 업그레이드하는 메커니즘으로 제공되지만, 주 프로젝트 시스템에서 직접 인식하지 못할 수 있습니다. 예를 들어 컴파일러 관련 파일 및 속성이 프로젝트 시스템의 나머지 부분을 처리하는 동일한 개발 팀에서 처리되지 않는 경우 이 상황이 발생할 수 있습니다.

IVsProjectUpgrade 구현

프로젝트 시스템에서만 구현하는 IVsProjectUpgrade 경우 Visual Studio 변환 마법사에 참여할 수 없습니다. 그러나 IVsProjectUpgradeViaFactory 인터페이스를 구현하더라도 IVsProjectUpgrade 구현에 파일 업그레이드를 위임할 수 있습니다.

IVsProjectUpgrade를 구현하려면

사용자가 프로젝트를 열려고 하면 프로젝트가 UpgradeProject 열린 후 프로젝트에서 다른 사용자 작업을 수행할 수 있기 전에 환경에서 메서드를 호출합니다. 사용자에게 솔루션을 UPF_SILENTMIGRATE 업그레이드하라는 메시지가 이미 표시되면 매개 변수에 플래그가 grfUpgradeFlags 전달됩니다. 사용자가 기존 프로젝트 추가 명령을 UPF_SILENTMIGRATE 사용하는 등 프로젝트를 직접 여는 경우 플래그가 전달되지 않으며 프로젝트에서 사용자에게 업그레이드하라는 메시지를 표시해야 합니다.
호출에 UpgradeProject 대한 응답으로 프로젝트는 프로젝트 파일이 업그레이드되었는지 여부를 평가해야 합니다. 프로젝트가 프로젝트 형식을 새 버전으로 업그레이드할 필요가 없는 경우 플래그를 반환 S_OK 하기만 하면 됩니다.
프로젝트가 프로젝트 형식을 새 버전으로 업그레이드해야 하는 경우 메서드를 호출 QueryEditFiles 하고 매개 변수의 값을 tagVSQueryEditFlagsrgfQueryEdit 전달하여 프로젝트 파일을 수정할 수 있는지 여부를 결정해야 합니다. 그러면 프로젝트에서 다음을 수행해야 합니다.
- 매개 변수에 VSQueryEditResult 반환된 pfEditCanceled 값이 QER_EditOK면 프로젝트 파일을 쓸 수 있기 때문에 업그레이드가 진행될 수 있습니다.
- VSQueryEditResult 매개 변수에서 반환된 pfEditCanceled 값이 QER_EditNotOK이고 VSQueryEditResult 값에 QER_ReadOnlyNotUnderScc 비트가 설정되어 있는 경우, UpgradeProject는 실패를 반환해야 합니다. 사용자가 권한 문제를 직접 해결해야 하기 때문입니다. 그러면 프로젝트에서 다음을 수행해야 합니다.
  
  ReportErrorInfo를 호출하여 사용자에게 오류를 보고하고 VS_E_PROJECTMIGRATIONFAILED 오류 코드를 IVsProjectUpgrade로 반환합니다.
- 값이 VSQueryEditResult 비트 집합이고 QER_EditNotOK 값이 VSQueryEditResultFlagsQER_ReadOnlyUnderScc 설정된 경우 프로젝트 파일을 호출 QueryEditFiles 하여 체크 아웃해야 합니다(QEF_ForceEdit_NoPrompting QEF_DisallowInMemoryEdits,...).
프로젝트 파일의 QueryEditFiles 호출로 인해 파일이 체크 아웃되고 최신 버전이 검색되면 프로젝트가 언로드되고 다시 로드됩니다. UpgradeProject 프로젝트의 다른 인스턴스가 만들어지면 메서드가 다시 호출됩니다. 이 두 번째 호출에서는 프로젝트 파일을 디스크에 쓸 수 있습니다. 프로젝트 파일의 복사본이 .OLD 확장자로 이전 형식에 저장되도록 하는 것이 좋으며, 필요한 업그레이드 수정 사항을 적용한 후 프로젝트 파일을 새 형식으로 저장하십시오. 다시 한 번 업그레이드 프로세스의 일부가 실패하면 메서드는 오류를 반환하여 VS_E_PROJECTMIGRATIONFAILED표시해야 합니다. 이렇게 하면 솔루션 탐색기에서 프로젝트가 언로드됩니다.

환경에서 QueryEditFiles 메서드를 호출할 때 ReportOnly 값을 지정하면 QER_EditNotOK 플래그와 QER_ReadOnlyUnderScc 플래그가 반환되는 경우, 전체 프로세스를 이해하는 것이 중요합니다.
사용자가 프로젝트 파일을 열려고 합니다.
환경이 CanCreateProject 구현을 호출합니다.
CanCreateProject가 true를 반환하면, 환경이 CanCreateProject 구현을 호출합니다.
환경은 구현을 호출 Load 하여 파일을 열고 프로젝트 개체(예: Project1)를 초기화합니다.
환경은 IVsProjectUpgrade::UpgradeProject 구현을 호출하여 프로젝트 파일을 업그레이드해야 하는지 결정합니다.
매개 변수 rgfQueryEdit에 값을 QEF_ReportOnly로 지정하여 QueryEditFiles를 호출합니다.
환경에서 QER_EditNotOK을 반환하고 VSQueryEditResult이며 QER_ReadOnlyUnderScc 비트가 VSQueryEditResultFlags에 설정됩니다.
IVsProjectUpgrade 구현에서 IVsQueryEditQuerySave::QueryEditFiles 함수(QEF_ForceEdit_NoPrompting, QEF_DisallowInMemoryEdits)를 호출합니다.

이 호출로 인해 프로젝트 파일의 새 복사본이 체크 아웃되고 최신 버전이 검색될 수 있을 뿐만 아니라 프로젝트 파일을 다시 로드해야 할 수도 있습니다. 이 시점에서 다음 두 가지 중 하나가 발생합니다.

사용자 고유의 프로젝트 다시 로드를 처리하는 경우 환경은 사용자 ReloadItem (VSITEMID_ROOT) 구현을 호출합니다. 이 호출을 받으면 프로젝트의 첫 번째 인스턴스(Project1)를 다시 로드하고 프로젝트 파일을 계속 업그레이드합니다. 환경은 GetProperty(VSHPROPID_HandlesOwnReload)에 대해 true을 반환하는 경우 사용자가 자신의 프로젝트를 다시 로드한다는 것을 알고 있습니다.
프로젝트 다시 로드를 사용자가 직접 처리하지 않으면 GetProperty (VSHPROPID_HandlesOwnReload)에 대해 false을 반환합니다. 이 경우 (QEF_ForceEdit_NoPrompting, QEF_DisallowInMemoryEdits)가 반환되기 전에 QueryEditFiles환경은 프로젝트의 다른 새 인스턴스(예: Project2)를 다음과 같이 만듭니다.
1. 환경은 첫 번째 프로젝트 개체인 Project1을 호출 Close 하여 이 개체를 비활성 상태로 만듭니다.
2. 환경은 IVsProjectFactory::CreateProject 구현을 호출하여 프로젝트의 두 번째 인스턴스인 Project2를 만듭니다.
3. 환경은 구현 IPersistFileFormat::Load 을 호출하여 파일을 열고 두 번째 프로젝트 개체인 Project2를 초기화합니다.
4. 환경은 프로젝트 개체를 업그레이드해야 하는지 여부를 확인하기 위해 두 번째로 호출 IVsProjectUpgrade::UpgradeProject 합니다. 그러나 이 호출은 프로젝트의 새 두 번째 인스턴스인 Project2에서 수행됩니다. 솔루션에서 열리는 프로젝트입니다.
  
  비고
  
  첫 번째 프로젝트인 Project1이 비활성 상태에 있는 경우 첫 번째 호출에서 귀하의 UpgradeProject 구현으로 S_OK을(를) 반환해야 합니다.
5. 매개 변수 rgfQueryEdit에 값을 QEF_ReportOnly로 지정하여 QueryEditFiles를 호출합니다.
6. 환경이 코드 QER_EditOK을 반환하므로 프로젝트 파일을 쓸 수 있어 업그레이드를 진행할 수 있습니다.

업그레이드에 실패하면 IVsProjectUpgrade::UpgradeProject에서 VS_E_PROJECTMIGRATIONFAILED을 반환합니다. 업그레이드가 필요하지 않거나 업그레이드하지 않도록 선택한 경우 호출을 IVsProjectUpgrade::UpgradeProject no-op처리합니다. 반환 VS_E_PROJECTMIGRATIONFAILED하는 경우 자리 표시자 노드가 프로젝트의 솔루션에 추가됩니다.

프로젝트 항목 업그레이드

구현하지 않는 프로젝트 시스템 내에서 항목을 추가하거나 관리하는 경우 프로젝트 업그레이드 프로세스에 참여해야 할 수 있습니다. Crystal Reports는 프로젝트 시스템에 추가할 수 있는 항목의 예입니다.

일반적으로 프로젝트 항목 구현자는 이미 완전히 인스턴스화되고 업그레이드된 프로젝트를 활용하려고 합니다. 프로젝트 참조가 무엇이고 업그레이드 결정을 내리기 위해 다른 프로젝트 속성이 무엇인지 알고 있어야 하기 때문입니다.