일반적으로 응용 프로그램 업데이트에는 두 가지 방법이 있습니다. 하나는 사용자에게 이메일 전송 등을 알리고 지정된 웹 사이트 주소에서 업데이트된 프로그램을 다운로드하도록 요청하는 것이고, 다른 하나는 업데이트 책임을 사용자로부터 사용자에게 이전하는 것입니다. 사용자가 소프트웨어 업데이트를 받고 설치하는 대신 클라이언트 응용 프로그램 자체가 알려진 서버에서 업데이트를 다운로드하고 설치하는 일을 담당합니다. 사용자가 해야 할 유일한 개입은 새 업데이트를 지금 설치할지 아니면 설치할지 결정하는 것입니다. 나중에. 분명히 후자가 전자보다 더 친근하다. 이제 Windows XP 및 Microsoft Money와 같이 후자의 접근 방식과 유사한 실제 제품을 볼 수 있습니다. 이 문서에 소개된 .NET 애플리케이션 업데이트 구성 요소는 유사한 기능을 제공할 수 있습니다.
1. .NET 애플리케이션 업데이트 구성 요소 소개
.NET 애플리케이션 업데이트 구성 요소 AppUpdater는 .NET 프레임워크를 사용하여 개발되었습니다. AppUpdater는 Microsoft 제품은 아니지만 VS.NET 도구 모음에 구성 요소를 추가하는 한 다른 구성 요소를 사용하는 것처럼 도구 모음에서 응용 프로그램으로 구성 요소를 끌어서 놓을 수 있습니다. 및 업데이트 획득 빈도 등), 클라이언트 애플리케이션에 자동 업데이트 기능이 있을 수 있습니다.
2. 작동 원리
.NET 클라이언트 응용 프로그램 업데이트 구성 요소의 작동 원리를 깊이 이해하려면 클라이언트 응용 프로그램 업데이트를 구현하기 위해 수행해야 하는 작업을 주의 깊게 연구해야 합니다. 첫 번째 단계는 업데이트가 있는지 확인하는 것입니다. 업데이트가 발견되면 두 번째 단계인 업데이트 다운로드를 시작하고, 업데이트 다운로드가 완료되면 마지막 단계인 업데이트 구현으로 진행합니다.
(1) 업데이트를 확인
하려면 먼저 애플리케이션에 업데이트를 확인할 위치를 알려주어야 합니다. 그렇지 않으면 건초더미에서 바늘을 찾는 것과 같지 않을까요? 둘째, 업데이트를 확인할 시기를 결정합니다. 사용자가 매번 클라이언트 프로그램을 실행하는 것은 불가능하며 백그라운드에서 지속적으로 업데이트를 확인하고 있습니다. 얼마나 자원 낭비입니까! 마지막으로 해결해야 할 중요한 사항은 업데이트를 확인하는 방법입니다. .NET 응용 프로그램 업데이트 구성 요소는 통신에 HTTP를 사용하므로 클라이언트 응용 프로그램이 방화벽을 통해 업데이트를 수행할 수 있습니다. 그리고 업데이트 확인에 필요한 주소는 알려진 웹 서버의 URL 주소가 되며, 첫 번째 문제는 성공적으로 해결됩니다.
.NET 애플리케이션 업데이트 구성 요소는 업데이트 확인을 담당하는 구성 요소 생성을 기반으로 스레드를 생성합니다. 이 스레드는 대부분의 시간 동안 휴면 상태이지만 설정된 간격으로 깨어나 업데이트 확인을 수행합니다. 애플리케이션이 새 업데이트를 확인하는 빈도는 애플리케이션에 따라 다릅니다. 업데이트 확인 간격에 대한 일반적인 값은 일반적으로 1시간에서 며칠까지입니다. 폴링에 대한 이러한 기본 접근 방식은 모든 상황에 적합하지 않습니다. 예를 들어 Microsoft Money는 사용자가 요청할 때만 업데이트를 확인합니다. 이 경우 업데이트 폴링 스레드를 비활성화할 수 있습니다.
업데이트 확인은 명령으로 업데이트 구성 요소의 CheckForUpdate() 메서드를 호출하여 구현됩니다.
업데이트 확인을 수행하는 방법에는 여러 가지가 있습니다.
방법 1: 직접 파일 확인 - HTTP를 사용하여 서버와 클라이언트 애플리케이션의 마지막 수정 날짜/타임 스탬프를 비교하여 일치하는지 확인합니다. 서버에 업데이트된 파일이 있으면 클라이언트는 자체적으로 업데이트할 수 있다는 것을 알고 있습니다. HTML 페이지나 이미지를 다시 다운로드해야 하는지 또는 이전에 다운로드한 것을 재사용할 수 있는지 여부를 아는 웹 브라우저의 경우에도 마찬가지입니다. 새 버전의 응용 프로그램을 사용할 수 있게 되면 관리자는 웹 서버의 이전 버전 위에 새 버전을 복사하기만 하면 됩니다. 이 접근 방식의 문제점은 업데이트가 자동으로 이루어지지 않아 실패할 가능성이 있다는 것입니다. 예를 들어 관리자가 웹 서버에서 응용 프로그램 버전을 업데이트하고 고객이 업데이트 이전 버전을 다운로드하는 경우 고객의 컴퓨터에는 업데이트 이전의 일부 파일과 새 업데이트의 일부 파일이 포함됩니다. 업데이트 이후의 버전입니다. 위의 이유로 중요한 응용 프로그램의 경우 파일 업데이트를 직접 확인하는 것은 권장되지 않습니다.
방법 2: 명시적 확인 - 서버의 명시적 구성 파일을 사용합니다. .NET 애플리케이션 업데이트 구성 요소와 함께 사용할 유효한 서버 명시적 파일은 다음과 같습니다. ..
<VersionConfig>
<사용 가능한 버전>1.0.0.0</사용 가능한 버전>
<ApplicationUrl> http://localhost/demos/selfupdate/V1/ </
애플리케이션URL>
</VersionConfig>
AvailableVersion은 사용 가능한 최신 어셈블리의 버전 번호를 지정합니다. ApplicationURL 속성은 이 버전의 애플리케이션이 위치한 URL 주소를 지정합니다. 관리자가 클라이언트 응용 프로그램을 업데이트하려는 경우 새 버전의 응용 프로그램을 웹 서버에 복사하고 서버 명시적 파일을 적절하게 수정합니다. 클라이언트 자체는 서버의 명시적 파일이 수정되었음을 감지한 후 명시적 파일을 다운로드합니다. 그런 다음 클라이언트는 명시적 파일에 지정된 어셈블리 버전 번호를 애플리케이션 EXE 파일의 버전 번호와 비교합니다. 서버의 명시적 파일에서 최신 버전 번호를 사용할 수 있는 경우 애플리케이션은 이를 업데이트해야 함을 인식합니다. 이 방법은 대부분의 응용 프로그램에 권장됩니다.
방법 3: XML 웹 서비스 확인 - XML WebServices는 더욱 발전된 업데이트 확인 방법을 제공합니다. 예를 들어, 다른 사용자를 업데이트하기 전에 초기 사용자 집합을 업데이트하려는 경우 클라이언트 응용 프로그램이 업데이트 사용 가능 여부를 확인하기 위해 XML Web Service를 호출하면 해당 XML Web Service는 해당 업데이트에 대한 데이터베이스도 쿼리할 수 있습니다. 사용자가 초기 사용자인지 여부를 판단합니다. 초기 사용자인 경우 XML Web Service는 업데이트를 사용할 수 있음을 나타내는 값을 반환합니다. 그렇지 않은 경우 웹 서비스는 업데이트를 사용할 수 없음을 나타내는 값을 반환합니다. 그러나 이 문서에 소개된 .NET 응용 프로그램 업데이트 구성 요소는 직접적인 XML 웹 서비스 지원을 제공하지 않습니다.
XML Web Service를 사용하여 업데이트 확인을 수행하려면 먼저 XML Web Service를 만들고 OnCheckForUpdate 이벤트를 연결합니다. 이를 통해 폴러 스레드 업데이트 확인 대신 사용자 정의 확인을 작성할 수 있습니다. OnCheckForUpdate 이벤트에는 업데이트가 검색되었는지 여부를 나타내는 반환 값이 있습니다.
(2) 업데이트 다운로드
.NET 애플리케이션 업데이트 구성 요소가 새 업데이트가 있음을 감지하면 자동으로 다른 스레드를 시작하고 업데이트의 비동기 백그라운드 다운로드를 시작합니다.
다운로드는 HTTP-DAV를 사용하여 수행됩니다. DAV는 디렉터리 및 파일 열거와 같은 기능을 제공하는 HTTP의 확장 버전입니다. 전체 다운로드 프로세스는 URL을 지정하는 것으로 시작됩니다. 다운로드에 사용되는 URL은 업데이트 확인을 완료하는 데 사용되는 방법에 따라 다릅니다. 예를 들어 서버 명시적 파일을 사용하는 경우 업데이트를 다운로드하는 데 사용되는 URL은 서버 명시적 파일의 ApplicationURL 특성을 통해 지정됩니다.
업데이트 다운로드에는 분명히 어느 정도 견고성이 필요합니다. 다운로드 및 업데이트 후에 클라이언트 애플리케이션을 불안정한 상태로 두는 것은 허용되지 않습니다. 다운로드 프로세스 중에 여러 가지 문제가 발생할 수 있습니다. 업데이트 파일이 속한 웹 서버가 다운되거나, 클라이언트 시스템이 충돌하거나, 사용자가 어떤 이유로 애플리케이션을 닫을 수도 있습니다. 애플리케이션을 다운로드 중이므로 종료하면 다운로드가 중지됩니다. 대안적인 설계 솔루션은 애플리케이션 다운로드 및 업데이트를 위해 별도의 시스템 서비스를 사용하는 것입니다. 시스템 서비스를 사용하면 애플리케이션 자체가 실행되지 않는 경우에도 업데이트 다운로드가 계속됩니다. 실제로 Windows XP에는 이러한 목적을 달성하는 BITS라는 다운로드 서비스가 내장되어 있습니다. BITS는 Windows XP에서 Windows 자체를 다운로드하고 업데이트하는 데 사용됩니다. BITS에 대한 자세한 내용은 http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp를 참조하세요. 이 서비스는 .NET 응용 프로그램 업데이트 구성 요소에서는 사용되지 않으므로 시스템 서비스를 지원하지 않는 Windows 9x에서 사용할 수 있습니다.
(3) 업데이트 구현
.NET 응용 프로그램 업데이트 구성 요소는 다운로드 및 업데이트 프로세스를 두 개의 개별 단계로 나누어 견고성을 얻습니다. 각 단계가 완료되면 클라이언트 애플리케이션 디렉터리에 있는 업데이트된 매니페스트 파일에 기록됩니다. 다운로드 또는 업데이트 프로세스가 어떤 단계에서든 중단되면 다음에 애플리케이션을 시작할 때 마지막으로 완료된 중단점부터 원래 작업을 다시 시작합니다. 각 단계는 재실행이 가능하므로, 단계 중간에 실패가 발생하면 해당 단계의 재실행이 성공하게 됩니다. 다운로드 중에 서버 연결이 끊어지는 등의 오류가 발생하면 .NET 업데이트 구성 요소는 나중에 다시 시도합니다. 오류가 너무 많이 보고되면(예: 웹 서버가 다시 온라인 상태로 돌아오지 않는 경우) 다운로드 및 업데이트가 중단되고 오류가 보고됩니다.
첫 번째 접근 방식은 업데이트를 구현하기 위해 별도의 프로세스를 시작하는 것입니다. 이 별도의 프로세스는 먼저 애플리케이션 프로세스를 종료하고, 업데이트를 구현하고(현재 잠금 해제되었으므로) 애플리케이션 프로세스를 다시 시작한 다음 완료되면 자체적으로 종료됩니다. 따라서 이 디자인에는 세 가지 기본적인 문제가 있습니다.
어떤 경우에는 작동하지 않습니다. 애플리케이션이 업데이트되면 업데이트 프로세스는 원래 애플리케이션 프로세스를 종료하고, 업데이트 프로세스 자체도 종료되므로 업데이트가 구현되지 않습니다.
. 업데이트가 필요한 모든 코드를 자동으로 업데이트할 수 있기를 원합니다. 우리는 응용 프로그램뿐만 아니라 .NET 응용 프로그램 업데이트 구성 요소 자체에도 패치를 자동으로 설치하는 기능을 원합니다. 이 모드를 사용하면 업데이트를 구현하는 프로세스를 업데이트할 수 없습니다.
. 사용자에게 애플리케이션을 강제로 닫고 사용하는 동안 기다리게 하는 것은 무례한 행동입니다.
애플리케이션 업데이트를 구현하는 데 사용되는 마지막 방법은 .NET Framework 병렬 어셈블리 패턴을 사용하는 것입니다. 애플리케이션 자체를 업데이트하는 대신 현재 기존 버전보다 최신 버전의 애플리케이션을 생성하십시오.
현재 기존 애플리케이션 카탈로그를 다운로드한 업데이트 버전과 병합하여 새 버전을 생성할 수 있습니다. 새 버전이 완성되면 사용자는 다음에 앱을 다시 열 때 자동으로 새 버전을 사용하게 됩니다. 그런 다음 원본 애플리케이션의 사본을 제거할 수 있습니다. 까다로운 점은 주어진 순간에 어떤 버전을 로드해야 하는지 파악하는 것입니다. Appstart라는 애플리케이션을 소개합니다. Appstart는 애플리케이션의 진입점입니다. 이 모드를 사용하면 애플리케이션 디렉토리는 다음과 같습니다. ..
--> Program Files
--> MyApp
--> Appstart.exe
--> Appstart.config
- -> V1 폴더
-- > MyApp.exe
--> V1.1 폴더
--> MyApp.exe
애플리케이션을 실행하려면 일반적으로 Appstart.exe를 시작합니다. 바탕 화면에 바로 가기 키를 갖고 싶다면 해당 바로 가기 키가 응용 프로그램을 직접 가리키지 않고 Appstart를 가리켜야 합니다. (AppStart.exe의 이름을 YourApp.exe와 같이 원하는 이름으로 바꿀 수 있습니다.) Appstart.exe입니다. Appstart.config 파일을 읽고 지정된 애플리케이션을 로드하는 매우 간단한 프로그램입니다. 유효한 Appstart.config 파일은 다음과 같습니다.
<Config>
<앱폴더이름>V1 폴더</앱폴더이름>
<AppExe이름>MyApp.exe</AppExe이름>
<AppLaunchMode>appdomain</AppLaunchMode>
</구성>
AppFolderName은 현재 실행 중인 애플리케이션 버전이 포함된 하위 폴더를 지정합니다. AppExeName에는 해당 폴더에 로드할 exe 파일의 이름이 포함되어 있습니다. 애플리케이션 업데이트가 완료되면 마지막 단계는 애플리케이션의 새 버전을 가리키도록 AppFolderName 값을 수정하는 것입니다. 이렇게 하면 다음에 사용자가 애플리케이션을 실행할 때 새로 업데이트된 버전의 애플리케이션이 실행됩니다. AppLaunchMode는 애플리케이션이 로드되는 방식을 지정합니다. 애플리케이션을 로드하는 방법에는 두 가지가 있습니다. 첫 번째 방법은 AppDomains를 사용하는 것입니다. AppDomains는 .NET Framework 공용 언어 런타임의 기능이자 독립적인 논리 단위이자 관리 개체이기도 합니다. 공용 언어 런타임에서는 프로세스당 여러 애플리케이션 도메인을 허용합니다. 이런 방식으로 Appstart.exe는 별도의 AppDomain에 있지만 동일한 AppStart.exe 프로세스에 애플리케이션을 로드할 수 있습니다. 두 가지 다른 exe 프로그램(예: Appstart.exe 및 MyApp.exe)이 실행되고 있음에도 불구하고 하나의 프로세스만 사용됩니다. AppDomain은 대부분의 애플리케이션에서 잘 작동하지만 별도의 AppDomain에서 실행하는 것과 별도의 프로세스에서 실행하는 것 사이에는 약간의 차이가 있습니다. 이 경우 AppLaunchMode를 "process"로 설정하면 애플리케이션이 별도의 프로세스에 로드됩니다.
Appstart가 애플리케이션을 실행하면 애플리케이션이 종료될 때까지 기다리며 절전 모드로 전환됩니다. 애플리케이션이 종료되면 Appstart도 종료됩니다.
3. 예제 연습
앞에서 .NET 애플리케이션 업데이트가 작동하는 방식을 설명했습니다. 이제 이를 예제에 적용해 보겠습니다.
1단계: 업데이트할 애플리케이션 생성
1. VS.NET을 사용하여 "SampleApp"이라는 새 Windows 애플리케이션 프로젝트를 생성합니다.
2. 원하는 흥미로운 배경색을 양식에 지정하십시오. 이후 업데이트 버전과 구별하기 위해 배경색을 사용하겠습니다.
3. 이제 이 애플리케이션에 미묘한 기능을 추가해 보겠습니다. 먼저 양식에 버튼을 추가합니다. 압축 파일에는 간단한 Windows Form이 포함된 어셈블리가 포함되어 있습니다. 압축 파일에 SamplesSampleAppSimpleForm 어셈블리에 대한 참조를 추가합니다. 그런 다음 버튼 이벤트 핸들러에 두 줄의 코드를 추가합니다.
..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.쇼();
4. 빌드 플래그를 디버그에서 RELEASE로 변환합니다. 이렇게 하면 나중에 원본이 실행되는 동안 새 버전의 애플리케이션을 빌드할 때 pdb 파일 잠금 문제를 방지할 수 있습니다. 애플리케이션을 구축하고 테스트하세요.
2단계: .NET 애플리케이션 업데이트 구성 요소 추가
1. VS.NET 도구 모음의 구성 요소 탭에서 마우스 오른쪽 버튼을 클릭하고 "도구 모음 사용자 정의"를 선택합니다. ".NET Framework 구성 요소" 탭을 선택합니다. "찾아보기"를 클릭하고 압축 파일의 AppUpdater 프로젝트 아래에 있는 AppUpdater.dll을 선택한 후 확인을 클릭하세요.
2. 이제 AppUpdater 아이콘이 도구 모음 구성 요소 목록 하단에 나타납니다. AppUpdater 구성 요소를 SampleApp 양식으로 끌어서 놓습니다. appUpdater1이라는 .NET 응용 프로그램 업데이트 구성 요소의 인스턴스가 양식 아래쪽에 나타납니다.
3단계: .NET 애플리케이션 업데이트 구성 요소 설정
이 단계에서는 .NET 애플리케이션 업데이트 구성 요소를 설정합니다. 이 예에서는 처음 4개의 속성만 변경하고 나머지는 기본값으로 유지해야 합니다.
AppUpdater 속성: 이는 .NET 애플리케이션 애플리케이션 업데이트의 핵심입니다. 이 프로그램에 대해 다음 설정을 지정해야 합니다.
(1) AutoFileLoad: 나중에 설명할 명령 다운로드 특성을 제어합니다.
(2) ChangeDetectionMode: 이 열거형은 업데이트를 확인하는 방법을 결정합니다. 이 예에서는 서버 명시적 검사를 사용하므로 이 값을 "ServerManifestCheck"로 설정합니다.
(3) ShowDefaultUI: .NET 애플리케이션 업데이트 구성 요소에는 새 업데이트를 사용할 수 있거나 업데이트 중 오류가 발생하는 등 일부 이벤트를 사용자에게 알리는 일련의 사용자 인터페이스가 있습니다. 이 UI는 기본 UI를 유효하지 않은 것으로 설정하고 이를 적절한 이벤트(예:
OnUpdateComplete) 사용자 정의 사용자 인터페이스를 팝업합니다. 이 예에서는 기본 사용자 인터페이스를 사용하므로 이 값을 true로 설정합니다.
(4) UpdateUrl: UpdateUrl은 업데이트 프로그램이 업데이트를 찾을 위치를 결정합니다. 이 예에서는 업데이트를 확인하기 위해 서버 명시적 파일을 사용하므로 이 속성은 서버 명시적 파일의 URL로 설정되어야 합니다.
이 예에서는 http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml 로 설정합니다. "yourWebserver"를 웹 서버 이름으로 바꾸십시오.
다운로더 속성: AppUpdater 구성 요소에는 두 개의 하위 구성 요소가 있습니다. 첫 번째는 구성 요소의 다운로드 및 Poller 속성을 제어하는 Downloader입니다. AppUpdater의 두 번째 하위 구성 요소는 업데이트 확인을 제어하는 Poller입니다.
(1)AutoStart: 애플리케이션이 시작될 때 Poller가 폴링을 시작해야 하는지 또는 계획된 업데이트 쿼리가 시작될 때까지 기다려야 하는지 여부를 제어하는 부울 값입니다.
(2) DownloadOnDetection: 부울 값은 새 업데이트가 발견되면 Poller가 즉시 업데이트 다운로드를 시작할지 또는 DownloadUdpate() 메서드를 호출하여 명시적인 다운로드를 시작할지 여부를 제어합니다.
(3)InitialPollInterval: 애플리케이션이 시작된 후 첫 번째 업데이트 확인을 수행하기 전에 대기하는 시간(초)입니다.
(4)PollInterval: 첫 번째 업데이트 확인 후 PollInterval은 각 후속 업데이트 확인 사이의 시간(초)을 제어합니다. 참고: 기본값은 30초마다 확인하는 것입니다. 당연히 애플리케이션에서 업데이트 확인 횟수를 줄이는 것이 좋습니다. .
이 모든 작업이 완료되면 속성 테이블은 다음과 같아야 합니다.
SamplesSampleAppSampleApp_Complete 디렉터리에는 올바르게 설치된 애플리케이션 버전이 포함되어 있습니다.
설치:
(1)DownloadRetryAttempts: 다운로드하는 동안 오류가 발생하면(예: 웹 서버 다운) 다운로더가 나중에 다시 시도합니다. 이 속성은 다운로더가 전체 애플리케이션 업데이트 오류로 간주하기 전에 네트워크 요청을 재시도하는 횟수를 제어합니다.
(2)SecondsBetweenDownloadRety: 네트워크 요청을 재시도하기 전에 기다려야 하는 시간(초)입니다.
(3)UpdateRetryAttempts: 업데이트 중에 심각한 오류가 발생하는 경우(예: 다운로더가 재시도 횟수를 초과하는 경우) 애플리케이션 업데이트 오류가 생성됩니다. 기본적으로 업데이트 시도는 중지됩니다. 그러나 다음에 애플리케이션이 시작될 때 복구를 시도합니다(예를 들어 웹 서버 업데이트가 며칠 동안 중단될 수 있음). 이 속성은 업데이트 시도 횟수를 제어합니다. 이 값을 초과하면 업데이트 프로그램이 업데이트를 취소하고 상태를 재설정한 후 업데이트 확인으로 돌아갑니다.
(4)ValidateAssemblies: 이 속성은 다운로드한 어셈블리가 효과적으로 완료되는 수준을 제어합니다. 자세한 내용은 이 문서의 보안 섹션을 참조하세요.
4단계: 클라이언트에서 애플리케이션 V1 버전을 생성하고 배포합니다.
SampleApp 프로젝트에서 AssemblyInfo.cs 파일을 엽니다. AssemblyVersion 값을 "1.0"에서 "1.0.0.0"으로 수정합니다. 이로 인해 어셈블리를 빌드할 때 VS.NET이 일반적으로 증분으로 지정하는 값 대신 "1.0.0.0" 값이 있는 태그를 가져옵니다.
1. 애플리케이션을 빌드합니다.
2. 압축 파일의 SamplesSampleAppSampleApp_ClientSetup 디렉터리를 로컬 컴퓨터에 복사합니다. 이 디렉터리에는 이미 AppStart.exe가 포함되어 있습니다. AppStart.config는 1.0.0.0 디렉터리를 가리키고 SampleApp.exe를 시작하도록 설정되었습니다.
SampleApp의 릴리스 디렉터리에서 SampleApp(Appupdater.dll, SimpleForm.dll 및 SampleApp.exe)를
클라이언트 SampleApp_ClientSetup1.0.0.0 디렉터리로 복사합니다. 이제 모든 기능을 갖춘 애플리케이션 버전이 클라이언트에 "설치"되었으며 AppStart.exe를 실행하여 실행할 수 있습니다.
5단계: 웹 서버 설치
이 단계에서는 업데이트 폴링 기능을 제공하기 위해 웹 서버를 설치합니다. .NET 응용 프로그램 업데이트 구성 요소는 HTTP-DAV를 사용하여 응용 프로그램 업데이트를 다운로드하므로 HTTP-DAV를 지원하는 웹 서버가 필요합니다. Windows 2000 및 최신 운영 체제의 IIS5.0은 HTTP-DAV를 지원합니다.
1. Samples/SampleApp_ServerSetup 디렉터리를 웹 서버의 wwwroot 디렉터리에 복사합니다.
2. SampleApp V1 버전을 웹 서버의 1.0.0.0 폴더에 복사합니다.
3. 웹 서버의 SampleApp_ServerSetup 디렉터리에 대한 IIS의 "디렉터리 찾아보기" 권한을 활성화합니다.
6단계: 애플리케이션 자동 업데이트
좋습니다. 이제 새 버전을 자동으로 설치하여 이 모든 노력의 결과를 확인할 차례입니다.
1. 클라이언트에 배포한 SampleApp 버전이 실행되고 있지 않으면 이를 로드하고 AppStart.exe를 사용해야 합니다.
2. VS.NET으로 돌아가서 SampleApp 양식에서 몇 가지 눈에 띄는 변경(예: 배경색 변경)을 수행합니다.
3. AssemblyInfo.cs의 버전 정보를 2.0.0.0으로 변경합니다.
4. 재생성.
5. 웹 서버로 돌아가서 1.0.0.0 디렉터리와 동일한 디렉터리 2.0.0.0을 생성합니다. 릴리스 생성 디렉터리의 새 버전의 애플리케이션을 웹 서버에 새로 생성된 2.0.0.0 디렉터리로 복사합니다.
6. UpdateVersion.xml을 열고 AvailableVersion을 2.0.0.0으로 수정합니다. 새로운 2.0.0.0 경로를 가리키도록 ApplicationURL을 수정합니다.
7. UpdateVersion.xml에 대한 변경 사항을 저장합니다.
새 UpdateVersion.xml을 저장하고 나면 30초 이내에 SampleApp 사본을 실행하면 사용 가능한 새 버전이 감지됩니다.
4. 주문형 설치, 보안, 확장성 및 디버깅
(1) 주문형 설치
소위 주문형 설치란 클라이언트 컴퓨터에 기본 실행 프로그램만 명시적으로 설치되는 것을 의미합니다. 나머지 애플리케이션은 기본 요구 사항에 따라 자동으로 다운로드되어 설치될 수 있습니다.
.NET 애플리케이션 업데이트 구성 요소의 AutoFileLoad 속성을 통해 주문형 설치를 시작합니다. 애플리케이션 내에서 어셈블리 경계가 어디에 있는지, 어셈블리를 다운로드하게 만드는 작업을 신중하게 고려해야 합니다. 어셈블리 다운로드에는 네트워크 입력 및 출력이 포함되므로 다운로드하는 데 걸리는 시간은 가변적입니다. 어셈블리를 다운로드하는 동안 어셈블리 다운로드가 완료될 때까지 기다리면서 애플리케이션이 정지됩니다.
(2) 배포
애플리케이션 업데이트를 자동으로 안전하게 설치하는 기능에는 많은 이점이 있지만 몇 가지 잠재적인 위험도 따릅니다. 업데이트 설치를 쉽게 만들면, 주의하지 않으면 악성코드 설치도 쉽게 만들 수 있습니다. 두 가지 위험이 있습니다. 첫 번째 위험은 누군가 자신의 웹 서버를 사용하여 업데이트 배포에 사용되는 웹 서버를 속이는 것입니다. 해당 웹 서버를 사용하여 응용 프로그램 경로에 바이러스를 설치할 수 있습니다. 네트워크를 통한 스푸핑이나 기타 부적절한 간섭을 방지하는 가장 간단한 방법은 HTTPS를 사용하는 것입니다. .NET 응용 프로그램 업데이트 구성 요소와 함께 HTTPS를 사용하려면 HTTP URL을 HTTPS URL로 바꾸면 됩니다. 물론 HTTPS는 만능은 아닙니다. HTTPS를 사용하는 데에는 두 가지 문제가 있습니다. 첫 번째는 확장성입니다. HTTPS를 사용하려면 서버가 웹 서버에서 다운로드한 모든 파일을 암호화해야 합니다. 애플리케이션의 업데이트 파일이 큰 경우 업데이트 파일을 암호화하는 비용으로 인해 서버에 과부하가 걸릴 수 있습니다. HTTPS 사용의 또 다른 문제점은 두 번째 보안 위험에 아무런 도움이 되지 않는다는 것입니다. 두 번째 위험은 해커가 외부뿐만 아니라 내부에서도 서버를 공격할 수 있다는 것입니다. 공격이 성공하면 수백 또는 수천 개의 클라이언트도 자동 업데이트의 영향을 받게 되며 이는 재앙이 될 수 있습니다.
이 문제를 해결하기 위해 .NET 응용 프로그램 업데이트 구성 요소는 .NET 어셈블리에 대한 강력한 이름 기능을 사용하여 다운로드된 어셈블리를 확인합니다. .NET 애플리케이션 업데이트 구성 요소가 다운로드 중에 어셈블리가 키로 서명되지 않았음을 감지하면 다운로드가 취소됩니다. 이는 애플리케이션의 개인 키를 가진 사람만이 자동으로 배포할 수 있는 업데이트를 만들 수 있음을 의미합니다.
어셈블리가 유효한지 확인하기 위해 .NET 애플리케이션 업데이트 구성 요소는 현재 설치된 애플리케이션 실행 파일의 공개 키와 다운로드한 업데이트의 공개 키가 일치하는지 확인합니다. 두 개의 어셈블리가 동일한 비밀 개인 키로 서명된 경우 포함된 공개 키는 동일합니다. CLR에 의해 로드되는 어셈블리는 공개 키를 확인하므로 CLR은 일반 해시 검사를 계산하여 해당 어셈블리가 변조된 어셈블리가 아니라 실제로 진짜 어셈블리인지 확인합니다. 다운로드 시 유효성 검사를 활성화하려면 모든 애플리케이션 어셈블리에 강력한 이름을 추가하고 .NET 애플리케이션 업데이트 구성 요소의 ValidateAssemblies 속성을 true로 설정하세요.
다운로드 시 어셈블리 확인은 많은 도움이 되지만 실제로 애플리케이션에는 서로 다른 개인 키로 서명된 구성 요소가 있는 경우가 많습니다. 예를 들어 애플리케이션에는 개인 키로 서명된 실행 가능한 어셈블리와 애플리케이션에서 구입하여 사용한 타사 차트 컨트롤이 포함된 다른 dll 어셈블리라는 두 개의 파일이 있을 수 있습니다. 타사 어셈블리는 귀하의 개인 키 대신 타사의 개인 키를 사용하여 서명될 수 있습니다. 상황을 더욱 복잡하게 만들기 위해 애플리케이션에서 어셈블리에 서명하는 데 사용되는 유효한 개인 키 설정이 버전 번호에서 버전 번호로 변경될 수 있습니다. 해당 애플리케이션 유형을 어떻게 자동으로 업데이트합니까? 이 문제를 해결하기 위해 애플리케이션에서 유효한 공개 키 목록이 포함된 어셈블리를 생성할 수 있습니다. 애플리케이션의 마스터 개인 키(애플리케이션의 exe 파일에 서명하는 데 사용되는 키)로 어셈블리에 서명하고 애플리케이션 업데이트 파일이 있는 웹 서버의 디렉터리에 어셈블리를 배치합니다. 업데이트 다운로드 프로세스가 시작되기 전에 .NET 응용 프로그램 업데이트 구성 요소는 웹 서버의 응용 프로그램 업데이트 디렉터리에서 "AppUpdaterKeys.dll"이라는 어셈블리를 확인합니다. 있는 경우 어셈블리가 다운로드됩니다. 어셈블리는 기본 애플리케이션의 공개 키에 대해 확인됩니다. 서명이 유효하면 키 목록이 추출됩니다. 이제부터 이 목록의 모든 키는 업데이트된 파일의 유효한 서명으로 간주됩니다.
권장되는 보안 접근 방식은 업데이트 확인에 HTTPS URL을 사용하는 것입니다. 이는 스푸핑 방지의 첫 번째 수준을 제공합니다. 업데이트 다운로드의 경우 웹 서버 과부하를 방지하려면 HTTPS RL을 사용하지 않는 것이 가장 좋습니다. 대신 애플리케이션 어셈블리에 강력한 이름을 추가하고 어셈블리 유효성 검사 기능을 사용하세요.
(3) 확장성
이 기사의 앞부분에서 언급한 예에서는 구성 요소를 응용 프로그램에 끌어서 놓고 자동 배포를 달성하기 위한 몇 가지 속성을 설정했습니다.
이는 많은 애플리케이션에서 잘 작동하지만 일부 애플리케이션에는 코드를 작성해야만 얻을 수 있는 높은 수준의 제어가 필요합니다. 재정의된 CheckForUpdate() 및 ApplyUpdate() 메서드를 사용하여 확인 및 업데이트 동작을 사용자 지정함으로써 .NET 애플리케이션 업데이트 구성 요소 표준 프로세스를 대체하는 자체 코드를 작성할 수 있습니다.
(4) 디버깅
이 섹션에서는 몇 가지 선호하는 디버깅 옵션을 지적하고 이 구성 요소 사용자가 직면하는 가장 일반적인 문제를 설명합니다.
.NET 응용 프로그램 업데이트 프로그램은 AppStart.exe와 동일한 디렉터리에 AppUpdate.log라는 숨겨진 로그 파일을 생성합니다.
모든 업데이트 성공 및 실패 정보가 이 로그에 기록됩니다. 로그 파일은 특정 클라이언트가 업데이트에 실패할 때 특히 유용합니다.
로그를 사용하여 업데이트가 실패한 시기와 방법을 확인할 수 있습니다. 또한 .NET 애플리케이션 업데이트 구성 요소는 .NET Framework의 Debug 클래스를 사용하여 다양하고 유용한 정보를 출력합니다. 디버거에서 애플리케이션을 실행하면 출력 창에 이 정보가 표시됩니다. .NET Application Updater의 로그를 따라 문제 영역을 강조 표시하고 찾을 수 있습니다.
어떤 이유로 인해 .NET 응용 프로그램 업데이트 프로그램이 작동하지 않는 경우 디버깅을 시작하기 전에 다음 사항을 확인하십시오. 발생한 문제는 다음 중 하나일 가능성이 높습니다. ..
IIS를 탐색하셨습니까? 디렉토리가 열렸나요? 그렇지 않으면 업데이터가 파일을 다운로드하고 설치하지 않습니다.
. 모든 것을 올바르게 배포하고 URL을 올바르게 설정했습니까?
. 귀하의 응용 프로그램이 프로그램 파일 디렉터리에 설치되어 있는 경우 귀하가 해당 컴퓨터의 슈퍼 관리자 또는 슈퍼 사용자이신가요? 그렇지 않으면 애플리케이션을 업데이트하기 위한 쓰기 액세스 권한이 없습니다.
. 애플리케이션의 기본 UI 스레드에서 AppUpdater 객체를 생성하고 있습니까? 그렇지 않으면 업데이트 프로그램이 UI를 표시할 수 없으며 UI에 다시 이벤트를 실행할 때 실패합니다.
. 업데이트가 성공했지만 애플리케이션이 새 업데이트로 자동으로 다시 시작되지 않습니까? .NET 애플리케이션 업데이트 구성 요소는 Application.Exit 메서드를 호출하여 애플리케이션 종료를 시도합니다. 그러나 이 방법은 응용 프로그램 종료를 보장하지 않습니다. 별도의 스레드를 생성하고 실행 중인 상태로 두면 이 메서드는 프로세스를 종료할 수 없습니다. 모든 스레드가 종료되도록 보장하는 솔루션은 Application.OnExit 이벤트를 호출하거나 .NET 애플리케이션 업데이트 프로그램의 OnUpdateComplete 이벤트에 연결하고 직접 종료를 처리하는 것입니다.
5. 요약
클라이언트 응용 프로그램의 편리한 배포는 .NET 프레임워크 첫 번째 버전의 중요한 목표입니다. .NET Framework를 사용하는 것은 배포 문제를 해결하는 클라이언트 응용 프로그램을 구축하는 데 유용한 기술입니다. 배포 용이성은 .NET Framework의 향후 새 버전에 대한 중요한 목표로 남아 있습니다. 솔루션으로서 여기에 설명된 .NET 애플리케이션 업데이트 구성 요소는 향후 버전의 .NET Framework에서 직접 사용할 수 있는 몇 가지 아이디어를 나타냅니다. 그러나 그 이전 기간에는 .NET 애플리케이션 업데이트 구성 요소가 자동 업데이트 애플리케이션 구축을 시작하는 중요한 방법으로 간주될 수 있습니다.
출처: csdn, Tianji에서 봤지만 아직 자세히 연구하지는 않았습니다. 나중에 참고하도록 남겨두겠습니다.