ClickOnce 배포를 만드는 모든 개발자가 애플리케이션 자체를 배포할 계획이 있는 것은 아닙니다. 그들 중 많은 사람들이 ClickOnce를 사용하여 애플리케이션을 패키지한 다음 대기업과 같은 고객에게 파일을 전달합니다. 고객은 네트워크에서 애플리케이션을 호스팅하는 책임을 집니다. 이 항목에서는 버전 3.5 이전의 .NET Framework 버전에서 이러한 배포에 내재된 몇 가지 문제에 대해 설명합니다. 그런 다음 .NET Framework 3.5의 새로운 "신뢰에 매니페스트 사용" 기능을 사용하여 제공되는 새 솔루션에 대해 설명합니다. 마지막으로, 여전히 이전 버전의 .NET Framework를 사용하는 고객을 위해 ClickOnce 배포를 만들기 위한 권장 전략으로 마무리합니다.
고객을 위한 배포 만들기와 관련된 문제
고객에게 배포를 제공하려는 경우 몇 가지 문제가 발생합니다. 첫 번째 문제는 코드 서명과 관련이 있습니다. 네트워크를 통해 배포하려면 ClickOnce 배포의 배포 매니페스트와 애플리케이션 매니페스트를 모두 디지털 인증서로 서명해야 합니다. 이렇게 하면 매니페스트에 서명할 때 개발자의 인증서 또는 고객의 인증서를 사용할지 여부에 대한 의문이 제기됩니다.
ClickOnce 애플리케이션의 ID는 배포 매니페스트의 디지털 서명을 기반으로 하므로 사용할 인증서에 대한 질문은 중요합니다. 개발자가 배포 매니페스트에 서명하는 경우 고객이 대기업이고 회사의 둘 이상의 부서가 사용자 지정된 버전의 애플리케이션을 배포하는 경우 충돌이 발생할 수 있습니다.
예를 들어 Adventure Works에는 재무 부서와 인사 부서가 있다고 가정해 보겠습니다. 두 부서 모두 SQL 데이터베이스에 저장된 데이터에서 보고서를 생성하는 Microsoft Corporation의 ClickOnce 애플리케이션 라이선스를 부여합니다. Microsoft는 각 부서에 해당 데이터에 맞게 사용자 지정된 애플리케이션 버전을 제공합니다. 애플리케이션이 동일한 Authenticode 인증서로 서명된 경우 두 애플리케이션을 모두 사용하려는 사용자는 두 번째 애플리케이션이 첫 번째 애플리케이션과 동일한 것으로 간주하므로 오류가 발생합니다. 이 경우 고객은 애플리케이션에 의해 로컬로 저장된 데이터의 손실을 포함하는 예측할 수 없고 원치 않는 부작용을 경험할 수 있습니다.
코드 서명 deploymentProvider 과 관련된 추가 문제는 애플리케이션 업데이트를 찾을 위치를 ClickOnce에 알려주는 배포 매니페스트의 요소입니다. 이 요소는 서명하기 전에 배포 매니페스트에 추가해야 합니다. 이 요소가 나중에 추가되면 배포 매니페스트에 다시 서명해야 합니다.
고객이 배포 매니페스트에 서명하도록 요구
고유하지 않은 배포의 이 문제에 대한 한 가지 해결 방법은 개발자가 애플리케이션 매니페스트에 서명하고 고객이 배포 매니페스트에 서명하도록 하는 것입니다. 이 방법은 작동하지만 다른 문제를 소개합니다. Authenticode 인증서는 보호된 자산으로 유지되어야 하므로 고객은 배포에 서명하기 위해 개발자에게 인증서를 제공할 수 없습니다. 고객은 .NET Framework SDK에서 자유롭게 사용할 수 있는 도구를 사용하여 배포 매니페스트 자체에 서명할 수 있지만, 이는 고객이 기꺼이 제공하거나 제공할 수 있는 것보다 더 많은 기술 지식이 필요할 수 있습니다. 이러한 경우 개발자는 일반적으로 고객이 서명을 위해 애플리케이션 버전을 제출할 수 있는 애플리케이션, 웹 사이트 또는 기타 메커니즘을 만듭니다.
ClickOnce 애플리케이션 보안에 대한 고객 서명의 영향
개발자와 고객이 애플리케이션 매니페스트에 서명해야 한다는 데 동의하더라도, 특히 신뢰할 수 있는 애플리케이션 배포에 적용되므로 애플리케이션의 ID를 둘러싼 다른 문제가 발생합니다. (이 기능에 대한 자세한 내용은 신뢰할 수 있는 애플리케이션 배포 개요를 참조하세요.) Adventure Works는 Microsoft Corporation에서 제공한 모든 애플리케이션이 완전 신뢰로 실행되도록 클라이언트 컴퓨터를 구성하려고 합니다. Adventure Works가 배포 매니페스트에 서명하는 경우 ClickOnce는 Adventure Work의 보안 서명을 사용하여 애플리케이션의 신뢰 수준을 결정합니다.
신뢰를 위해 애플리케이션 매니페스트를 사용하여 고객 배포를 생성하기
.NET Framework 3.5의 ClickOnce에는 개발자와 고객에게 매니페스트 서명 방법에 대한 시나리오에 대한 새로운 솔루션을 제공하는 새로운 기능이 포함되어 있습니다. ClickOnce 애플리케이션 매니페스트는 개발자가 애플리케이션 매니페스트의 디지털 서명이 신뢰 결정을 내리는 데 사용해야 한다는 것을 나타낼 수 있도록 하는 새 <useManifestForTrust> 요소를 지원합니다. 개발자는 Mage.exe,MageUI.exe및 Visual Studio와 같은 ClickOnce 패키징 도구를 사용하여 이 요소를 애플리케이션 매니페스트에 포함할 뿐만 아니라 매니페스트에 게시자 이름과 애플리케이션 이름을 모두 포함합니다.
사용하는 <useManifestForTrust>경우 배포 매니페스트는 인증 기관에서 발급한 Authenticode 인증서로 서명할 필요가 없습니다. 대신 자체 서명된 인증서로 서명할 수 있습니다. 자체 서명된 인증서는 표준 .NET Framework SDK 도구를 사용하여 고객 또는 개발자가 생성한 다음 표준 ClickOnce 배포 도구를 사용하여 배포 매니페스트에 적용됩니다. 자세한 내용은 MakeCert를 참조하세요.
배포 매니페스트에 자체 서명된 인증서를 사용하면 몇 가지 이점이 있습니다. 고객이 자체 Authenticode 인증서 <useManifestForTrust> 를 가져오거나 만들 필요가 없도록 함으로써 개발자가 애플리케이션에서 자신의 브랜딩 ID를 유지할 수 있도록 하면서 고객을 위한 배포를 간소화합니다. 그 결과 보다 안전하고 고유한 애플리케이션 ID가 있는 서명된 배포 집합이 생성됩니다. 이렇게 하면 동일한 애플리케이션을 여러 고객에게 배포할 때 발생할 수 있는 잠재적 충돌이 제거됩니다.
ClickOnce 배포가 <useManifestForTrust> 사용되도록 설정된 경우에 대한 단계별 정보는 연습: 다시 서명할 필요가 없으며 브랜딩 정보를 유지하는 ClickOnce 애플리케이션을 수동으로 배포하는 방법을 참조하세요.
신뢰에 대한 애플리케이션 매니페스트의 런타임 작동 방식
런타임에 애플리케이션 매니페스트를 신뢰에 사용하는 방법을 더 잘 이해하려면 다음 예제를 고려하세요. .NET Framework 3.5를 대상으로 하는 ClickOnce 애플리케이션은 Microsoft에서 만듭니다. 애플리케이션 매니페스트는 <useManifestForTrust> 요소를 사용하고 Microsoft에서 서명합니다. Adventure Works는 자체 서명된 인증서를 사용하여 배포 매니페스트에 서명합니다. Adventure Works 클라이언트는 Microsoft에서 서명한 모든 애플리케이션을 신뢰하도록 구성됩니다.
사용자가 배포 매니페스트에 대한 링크를 클릭하면 ClickOnce가 사용자의 컴퓨터에 애플리케이션을 설치합니다. 인증서 및 배포 정보는 클라이언트 컴퓨터의 ClickOnce에 대한 애플리케이션을 고유하게 식별합니다. 사용자가 다른 위치에서 동일한 애플리케이션을 다시 설치하려고 하면 ClickOnce에서 이 ID를 사용하여 애플리케이션이 클라이언트에 이미 있는지 확인할 수 있습니다.
다음으로 ClickOnce는 애플리케이션 매니페스트에 서명하는 데 사용되는 Authenticode 인증서를 검사하여 ClickOnce가 부여할 신뢰 수준을 결정합니다. Adventure Works는 Microsoft에서 서명한 모든 애플리케이션을 신뢰하도록 클라이언트를 구성했기 때문에 이 ClickOnce 애플리케이션에는 완전 신뢰가 부여됩니다. 자세한 내용은 신뢰할 수 있는 애플리케이션 배포 개요를 참조하세요.
이전 버전에 대한 고객 배포 만들기
개발자가 이전 버전의 .NET Framework를 사용하는 고객에게 ClickOnce 애플리케이션을 배포하는 경우 어떻게 될까요? 다음 섹션에서는 각 솔루션의 이점 및 단점과 함께 몇 가지 권장 솔루션을 요약합니다.
고객을 대신하여 배포를 서명하기
가능한 배포 전략 중 하나는 개발자가 고객의 프라이빗 키를 사용하여 고객을 대신하여 배포에 서명하는 메커니즘을 만드는 것입니다. 이렇게 하면 개발자가 프라이빗 키 또는 여러 배포 패키지를 관리할 필요가 없습니다. 개발자는 각 고객에게 동일한 배포를 제공합니다. 서명 서비스를 사용하여 환경에 맞게 사용자 지정하는 것은 고객의 달려 있습니다.
이 메서드의 한 가지 단점은 구현하는 데 필요한 시간과 비용입니다. 이러한 서비스는 .NET Framework SDK에 제공된 도구를 사용하여 빌드할 수 있지만 제품 수명 주기에 더 많은 개발 시간을 추가합니다.
이 항목의 앞부분에서 설명한 것처럼 또 다른 단점은 각 고객의 애플리케이션 버전이 동일한 애플리케이션 ID를 갖게 되어 충돌이 발생할 수 있다는 것입니다. 이 문제가 있는 경우 개발자는 배포 매니페스트를 생성할 때 사용되는 이름 필드를 변경하여 각 애플리케이션에 고유한 이름을 지정할 수 있습니다. 이렇게 하면 애플리케이션의 각 버전에 대해 별도의 ID가 만들어지고 잠재적인 ID 충돌이 제거됩니다. 이 필드는 Mage.exe의 -Name 인수와 MageUI.exe의 이름 탭의 이름 필드에 해당합니다.
예를 들어 개발자가 Application1이라는 애플리케이션을 만들었다고 가정합니다. 이름 필드가 Application1로 설정된 단일 배포를 만드는 대신, 개발자는 Application1-CustomerA, Application1-CustomerB 등과 같이 이 이름에 대한 고객별 변형을 사용하여 여러 배포를 만들 수 있습니다.
설치 패키지를 사용하여 배포
두 번째 가능한 배포 전략은 ClickOnce 애플리케이션의 초기 배포를 수행하는 Microsoft 설치 프로젝트를 생성하는 것입니다. MSI 배포, 설치 실행 파일(.EXE) 또는 배치 스크립트와 함께 캐비닛(.cab) 파일 등 여러 가지 형식 중 하나로 제공할 수 있습니다.
개발자는 이 기술을 사용하여 고객에게 애플리케이션 파일, 애플리케이션 매니페스트 및 템플릿 역할을 하는 배포 매니페스트를 포함하는 배포를 제공합니다. 고객은 설치 프로그램을 실행하여 배포 URL(사용자가 ClickOnce 애플리케이션을 설치할 서버 또는 파일 공유 위치) 및 디지털 인증서를 묻는 메시지를 표시합니다. 설치 애플리케이션은 업데이트 확인 간격과 같은 추가 ClickOnce 구성 옵션을 묻는 메시지를 표시하도록 선택할 수도 있습니다. 이 정보가 수집되면 설치 프로그램에서 실제 배포 매니페스트를 생성하고, 서명하고, ClickOnce 애플리케이션을 지정된 서버 위치에 게시합니다.
고객이 이 상황에서 배포 매니페스트에 서명할 수 있는 세 가지 방법이 있습니다.
고객은 CA(인증 기관)에서 발급한 유효한 인증서를 사용할 수 있습니다.
이 방법의 변형으로 고객은 자체 서명된 인증서를 사용하여 배포 매니페스트에 서명하도록 선택할 수 있습니다. 이에 대한 단점은 사용자에게 설치 여부를 묻는 메시지가 표시되면 애플리케이션에 "알 수 없는 게시자"라는 단어가 표시된다는 것입니다. 그러나 이점은 소규모 고객이 인증 기관에서 발급한 인증서에 필요한 시간과 비용을 소비할 필요가 없다는 것입니다.
마지막으로 개발자는 자체 서명된 인증서를 설치 패키지에 포함할 수 있습니다. 이 항목에서는 이 항목의 앞부분에서 설명한 애플리케이션 ID와 관련된 잠재적인 문제를 소개합니다.
설치 배포 프로젝트 메서드의 단점은 사용자 지정 배포 애플리케이션을 빌드하는 데 필요한 시간과 비용입니다.
고객이 배포 매니페스트를 생성하게 합니다.
세 번째 가능한 배포 전략은 애플리케이션 파일 및 애플리케이션 매니페스트만 고객에게 전달하는 것입니다. 이 시나리오에서 고객은 .NET Framework SDK를 사용하여 배포 매니페스트를 생성하고 서명할 책임이 있습니다.
이 방법의 단점은 고객이 .NET Framework SDK 도구를 설치하고 이를 사용하는 데 숙련된 개발자 또는 시스템 관리자가 있어야 한다는 것입니다. 일부 고객은 기술적 노력이 거의 또는 전혀 필요하지 않은 솔루션을 요구할 수 있습니다.