.NET WPF 유틸리티를 퍼블리시하고 배포하는 방법

Visual Studio에서 게시

[1:03 - 1:25] Tim은 Visual Studio에서 프로젝트를 우클릭하고 게시를 선택하여 시작합니다. 마법사는 여러 대상(Azure, Docker, ClickOnce)을 제공합니다. 하지만 그는 이 모든 것을 넘기고 폴더를 선택합니다. 개인 유틸리티가 자신의 기계에만 있을 때, 폴더 게시가 가장 직접적인 경로입니다: 배포 인프라 없이도 필요한 모든 곳에 파일을 복사할 수 있습니다.

대상 폴더를 선택한 후, Tim은 즉시 게시를 실행하는 대신 설정 페이지로 바로 건너뜁니다. 출력이 원하는 것과 일치하기 위해 기본값을 조정해야 합니다.

프레임워크 종속 vs. 자체 포함

[1:25 - 2:32] 첫 번째 설정은 배포 모드입니다. 프레임워크 종속 빌드는 대상 기기에 이미 .NET SDK 또는 런타임이 설치되어 있다고 가정합니다. 출력은 시스템에 있는 공유 런타임을 사용하는 덕분에 작으며, 이 애플리케이션의 경우 약 200킬로바이트입니다.

자체 포함 빌드는 전체 .NET 런타임을 출력물에 번들로 묶습니다. .NET이 설치되지 않은 기기에서도 패키지를 이동 가능하게 하지만, 크기는 약 140메가바이트로 증가합니다. Tim은 사용하는 모든 기기에 .NET이 이미 설치되어 있기 때문에 프레임워크 종속을 선택합니다. 런타임이 없을 수 있는 동료나 고객에게 도구를 배포하는 경우 자체 포함이 더 안전한 선택이지만, 개인적인 유틸리티의 경우 이러한 교환이 거의 의미가 없습니다.

WPF를 선택한 이유 - MAUI가 아닌 이유

[2:50 - 4:10] Tim은 이 프로젝트에 MAUI 대신 WPF를 사용하는 것에 대한 피드백을 처리합니다. 그의 이유는 이념보다는 실질적입니다. 이미지 뷰어는 Windows에서만 실행되어야 합니다. 단일 플랫폼 도구에 대해 MAUI 및 그 교차 플랫폼 레이어를 도입하면 이점 없이 오버헤드가 추가됩니다.

구조적 논거 외에도 유지 보수 관점이 있습니다. Tim의 원래 소스 코드가 거의 7년 동안 최소한의 변경으로 약 4~5대의 기기를 거쳤습니다. 유일한 업데이트는 프레임워크 업그레이드(.NET Framework에서 .NET 8, 그리고 이제 .NET 10)였습니다. 유틸리티가 매번 Apple이나 Google이 OS 업데이트를 배포할 때마다 주의를 기울여야 하는 프레임워크에서 구축되었다면, 그 7년 간의 비활성운영은 불가능했을 것입니다. 유지 관리에 더 많은 시간을 소비해야 하는 유틸리티는 더 이상 시간 절약을 하지 않습니다.

단일 파일 게시 및 PDB 파일

[4:59 - 6:32] 배포 모드가 결정된 후, Tim은 '단일 파일 생성'을 활성화하고 Windows x64를 대상으로 설정합니다. 출판이 완료되고 두 개의 파일이 포함된 출력 폴더가 열립니다: .exe 와 .pdb.

두 번째 파일은 프로그램 데이터베이스 파일이며, 그 역할은 이해할 가치가 있습니다. 릴리스 모드로 컴파일할 때, 컴파일러는 성능을 위해 내부 기호를 최적화하고 이름을 변경합니다. PDB는 최적화된 이름을 실제 코드베이스로 다시 매핑하여 실행 중인 실행 파일에 디버거를 연결하고 디버그 모드에서 작업하는 것처럼 중단점을 설정할 수 있습니다. 고객을 위한 프로덕션 애플리케이션의 경우, 배포 후 문제를 진단할 수 있도록 각 릴리스와 함께 안전하게 PDB 파일을 저장해야 합니다.

자신을 위해 제작한 도구의 경우, Tim은 PDB가 애플리케이션 실행에 필요하지 않다고 언급합니다. 그는 단순화를 위해 이를 삭제하지만, 사용자에게 배포되는 제품에는 이를 채택하지 말 것을 경고합니다. 단일 .exe 은 PDB가 없어도 자체적으로 실행됩니다.

주목할 만한 현상 중 하나는 프레임워크 종속에서 자체 포함으로 전환하고 "단일 파일"을 활성화 상태로 유지하면 출력물이 더 이상 단일 파일이 아니라는 것입니다. 실행 파일 옆에 추가 런타임 파일들이 나타납니다. 단일 파일 옵션은 프레임워크 종속 빌드와 연결할 때만 진정한 단일 파일을 생성합니다.

유틸리티를 기기에 배치하기

[7:17 - 7:52] 실행 파일을 확보한 후, Tim은 이를 영구적인 위치로 이동합니다. 그는 전용 C:\Apps\SimpleImageViewer 폴더를 사용합니다. 이는 개인 도구를 프로그램 파일과 분리하고 찾기 쉽게 유지하는 관행입니다. 2024년부터 사용하던 실행 파일이 현재 기기에서도 동일하게 실행되며, 이는 수명 연장에 대해 이전에 언급한 점을 강조합니다: 간단한 프로젝트 구조로 잘 정의된 유틸리티는 하드웨어 변경 및 OS 업그레이드를 필요 없이 견딜 수 있습니다.

오른쪽 클릭 메뉴에 도구 추가하기

[7:52 - 10:21] 마지막 단계는 유틸리티를 Windows Explorer의 컨텍스트 메뉴에 연결하는 것입니다. Tim은 폴더에서 마우스 오른쪽 버튼을 클릭하여 그림 디렉토리를 열거나 폴더의 빈 공간을 우클릭하여 현재 디렉토리에서 뷰어를 실행하도록 두 위치에 항목을 추가하기 위해 Windows 레지스트리를 수정합니다.

각 레지스트리 항목은 선택한 경로를 명령줄 인수로 실행 파일에 전달하는 쉘 명령어를 생성합니다. 이것은 응용 프로그램의 진입점에 있는 args 매개변수가 값을 받는 곳입니다.

Tim은 .reg 파일을 제공하지만 공유하기 전에 .txt 로 이름을 변경합니다. 그런 예방 조치가 중요합니다: .reg 파일을 두 번 클릭하면 즉시 레지스트리에 값을 작성하라는 메시지가 표시되며, 신뢰할 수 없는 레지스트리 파일을 실행하면 심각한 시스템 문제가 발생할 수 있습니다. 그의 접근 방식은 파일을 열고 경로를 확인한 다음, 그것을 자신의 기계에 맞게 업데이트하고, 확장자를 .reg 로 다시 변경한 다음에야 실행하도록 요구합니다. 그 중 어느 것이라도 익숙하지 않다면, Tim의 조언은 직설적입니다: 레지스트리를 수정하지 말라는 것입니다.

레지스트리에 익숙한 개발자에게는 두 가지 항목이 직관적입니다. 각각은 적절한 키 아래에 이름이 지정된 셸 명령을 생성하고, 실행 파일의 전체 경로를 %V 또는 %1 자리표시자와 함께 가리키며, 이들은 실행 시 대상 디렉토리 또는 파일 경로를 전달합니다. 새 컨텍스트 메뉴 항목이 나타나기 전에 재부팅이 필요할 수 있습니다.

정리: 한 번 배포하고 영원히 사용하세요

[10:21 - 10:30] 전체 배포 과정은 두 단계입니다: 폴더에 게시하고 오른쪽 클릭 메뉴에 실행 파일을 등록하는 것입니다. 설치 프로그램도, 업데이트 메커니즘도, 클라우드 서비스도 없습니다. 자신의 기기의 단일 목적 유틸리티를 위한, 그 단순함이 핵심입니다.

결론

[10:30 - 10:40] 요약하자면: dotnet publish 는 프레임워크 의존 및 단일 파일 설정으로 어디에나 드롭할 수 있는 경량 실행 파일을 생성합니다. 레지스트리 항목 두 개쌍은 Windows Explorer 어디에서나 사용할 수 있는 컨텍스트 메뉴 동작으로 바꿉니다.

전체 비디오 내내 전달되는 교훈은 자제입니다. 배포 접근 방식을 애플리케이션의 범위에 맞추세요. 개인 용도로 제작된 유틸리티는 수천 명에게 출하되는 제품과 동일한 인프라를 필요로 하지 않습니다. 그렇게 대우하면 유틸리티가 절약하려 만든 시간을 갉아먹는 유지 관리 작업만 생깁니다.

팁 예시: 개인 프로젝트에도 PDB 파일을 보관하세요. 실행 파일과 동일한 폴더나 가까운 아카이브에 저장하세요. 유틸리티가 몇 달 후 예기치 않게 동작하면, PDB를 통해 Visual Studio를 연결하여 소스에서 다시 컴파일하지 않고 릴리스 빌드를 디버깅할 수 있습니다.

전체 비디오를 그의 YouTube 채널에서 시청하여 .NET 데스크톱 애플리케이션 배포에 관한 인사이트를 얻으세요.