다음을 통해 공유

다른 사용자가 배포할 수 있는 ClickOnce 애플리케이션 만들기

  • 아티클

ClickOnce 배포 계획을 만드는 모든 개발자가 애플리케이션을 직접 배포하지는 않습니다. 대부분은 ClickOnce를 사용하여 애플리케이션을 패키징한 다음, 대기업과 같은 고객에게 파일을 전달할 뿐입니다. 네트워크에서 애플리케이션을 호스트하는 것은 고객의 역할입니다. 이 항목에서는 .NET Framework 버전 3.5 이전에서 이러한 배포에 내재된 문제 몇 가지에 대해 설명합니다. 그런 다음, .NET Framework 3.5의 새로운 "신뢰에 대한 매니페스트 사용" 기능을 사용하여 제공되는 새 솔루션에 대해 설명합니다. 마지막으로, 아직 이전 버전의 .NET Framework를 사용하는 고객에게 권장되는 ClickOnce 배포 만들기 전략으로 마무리하겠습니다.

고객을 위한 배포 만들기와 관련된 문제

고객에게 배포를 제공하려는 경우 몇 가지 문제가 발생합니다. 첫 번째 문제는 코드 서명과 관련이 있습니다. 네트워크를 통해 배포하려면 ClickOnce 배포의 배포 매니페스트와 애플리케이션 매니페스트를 모두 디지털 인증서로 서명해야 합니다. 이렇게 하면 매니페스트에 서명할 때 개발자의 인증서를 사용할지 아니면 고객의 인증서를 사용할지에 대한 질문이 제기됩니다.

ClickOnce 애플리케이션의 ID는 배포 매니페스트의 디지털 서명을 기반으로 하기 때문에 어느 인증서를 사용할지에 대한 문제는 중요합니다. 개발자가 배포 매니페스트에 서명하는 경우 고객이 대기업이고 회사의 여러 부서에서 사용자 지정된 버전의 애플리케이션을 배포하는 경우 충돌이 발생할 수 있습니다.

예를 들어 Adventure Works에 재정부와 인사부가 있다고 가정합니다. 두 부서 모두 SQL 데이터베이스에 저장된 데이터에서 보고서를 생성하는 Microsoft Corporation ClickOnce 애플리케이션에 대한 라이선스를 부여합니다. Microsoft는 각 부서에 해당 데이터에 맞게 사용자 지정된 애플리케이션 버전을 제공합니다. 애플리케이션이 동일한 Authenticode 인증서로 서명된 경우 두 애플리케이션을 모두 사용하려는 사용자는 ClickOnce가 두 번째 애플리케이션을 첫 번째 애플리케이션과 동일한 것으로 간주합니다. 이에 오류가 발생합니다. 이 경우 고객은 애플리케이션에 의해 로컬로 저장된 데이터의 손실을 포함하여 예측할 수도 없고 원하지도 않는 부작용을 경험할 수 있습니다.

코드 서명과 관련된 추가 문제는 ClickOnce에 애플리케이션 업데이트를 찾을 위치를 알려주는 배포 매니페스트의 deploymentProvider 요소입니다. 이 요소는 서명 전에 배포 매니페스트에 추가해야 합니다. 이 요소가 나중에 추가되면 배포 매니페스트에 다시 서명해야 합니다.

고객이 배포 매니페스트에 서명하도록 요구

이 고유하지 않은 배포 문제에 대한 한 가지 솔루션은 개발자가 애플리케이션 매니페스트에 서명하고 고객이 배포 매니페스트에 서명하도록 하는 것입니다. 이 방법은 유효하지만 다른 문제를 초래합니다. 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를 참조하세요.

배포 매니페스트에 자체 서명된 인증서를 사용하면 몇 가지 이점이 있습니다. <useManifestForTrust>는 고객이 자체 Authenticode 인증서를 가져오거나 만들 필요가 없게 하여 개발자가 애플리케이션에서 자신의 브랜딩 ID를 유지하도록 허용하면서 고객에 대한 배포를 간소화합니다. 결과적으로 더 안전하고 고유한 애플리케이션 ID가 있는 서명된 배포 세트가 생성됩니다. 이렇게 하면 동일한 애플리케이션을 여러 고객에게 배포할 때 발생할 수 있는 잠재적 충돌이 제거됩니다.

<useManifestForTrust>를 사용하여 ClickOnce 배포를 만드는 방법에 대한 단계별 정보는 연습: 다시 서명할 필요가 없고 브랜딩 정보가 유지되는 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 등과 같이 이 이름에 고객별 변형을 사용하여 여러 배포를 만들 수 있습니다.

설치 패키지를 사용하여 배포

두 번째 가능한 배포 전략은 Microsoft 설치 프로젝트를 생성하여 ClickOnce 애플리케이션의 초기 배포를 수행하는 것입니다. 이 배포는 MSI 배포, 설치 실행 파일(.EXE), 배치 스크립트와 함께 캐비닛(.cab) 파일 등 여러 가지 형식 중 하나로 제공할 수 있습니다.

개발자는 이 기술을 사용하여 고객에게 애플리케이션 파일, 애플리케이션 매니페스트, 템플릿으로 사용되는 배포 매니페스트가 포함된 배포를 제공합니다. 고객이 설치 프로그램을 실행하면 배포 URL(사용자가 ClickOnce 애플리케이션을 설치할 서버 또는 파일 공유 위치)과 디지털 인증서를 입력하라는 메시지가 표시됩니다. 설치 애플리케이션은 업데이트 확인 간격과 같은 추가 ClickOnce 구성 옵션을 묻는 메시지를 표시할 수도 있습니다. 이 정보가 수집되면 설치 프로그램은 실제 배포 매니페스트를 생성하고, 서명하고, ClickOnce 애플리케이션을 지정된 서버 위치에 게시합니다.

이 경우 고객이 배포 매니페스트에 서명할 수 있는 세 가지 방법이 있습니다.

  1. 고객은 CA(인증 기관)에서 발급한 유효한 인증서를 사용할 수 있습니다.

  2. 이 방법의 변형으로 고객은 자체 서명된 인증서를 사용하여 배포 매니페스트에 서명하도록 선택할 수 있습니다. 이에 대한 단점은 사용자에게 설치 여부를 묻는 메시지가 표시될 때 애플리케이션이 "알 수 없는 게시자"라는 단어를 표시한다는 것입니다. 그러나 소규모 고객은 인증 기관에서 발급한 인증서에 필요한 시간과 비용을 소비할 필요가 없다는 이점이 있습니다.

  3. 마지막으로 개발자는 자체 서명된 인증서를 설치 패키지에 포함할 수 있습니다. 이 경우 이 항목의 앞부분에서 설명한 애플리케이션 ID의 잠재적인 문제가 초래됩니다.

    설치 배포 프로젝트 방법의 단점은 사용자 지정 배포 애플리케이션을 빌드하는 데 필요한 시간과 비용입니다.

고객이 배포 매니페스트를 생성

세 번째 가능한 배포 전략은 고객에게 애플리케이션 파일 및 애플리케이션 매니페스트만 전달하는 것입니다. 이 시나리오에서 고객은 .NET Framework SDK를 사용하여 배포 매니페스트를 생성하고 서명할 책임이 있습니다.

이 방법의 단점은 고객이 .NET Framework SDK 도구를 설치해야 하고 이를 사용하는 데 숙련된 개발자 또는 시스템 관리자가 있어야 한다는 것입니다. 일부 고객은 기술적인 노력이 거의 필요하지 않거나 전혀 필요하지 않은 솔루션을 요구할 수 있습니다.

관련 콘텐츠