.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は、このプロジェクトでWPFを使用することについて寄せられたフィードバックに取り組んでいます。 彼の理由は、イデオロギーよりも実用的です。 画像ビューアはWindowsでのみ動作する必要があります。 MAUIとそのクロスプラットフォームレイヤーを導入することで、単一プラットフォームツールには何の利点もないオーバーヘッドが追加されます。

建築的な議論の他に、メンテナンスの角度もあります。 Timの元のソースコードは、4～5台のマシンを経た7年間、大きな変更もなく生き残っています。 唯一の更新は、フレームワークのアップグレードでした (.NET Frameworkから.NET 8、現在は.NET 10へ) 。 もし、毎回AppleやGoogleがOSのアップデートを出すたびに注意が必要なフレームワークでユーティリティが構築されていたら、その7年のメンテナンスフリーの運営は不可能だったでしょう。 保守に多くの時間がかかり、節約されるものが何もなくなるユーティリティは、もはや節約していないことになります。

単一ファイルの公開とPDBファイル

[4:59 - 6:32] デプロイモードが決定した後、Tim は "単一ファイルの生成" オプションを有効にし、Windows x64 をターゲットにします。公開は完了し、出力フォルダーが開き、.exe と .pdb の2つのファイルが含まれています。

2番目のファイルはプログラムデータベースファイルで、その役割を理解する価値があります。 Releaseモードでコンパイルすると、コンパイラーはパフォーマンスのために内部シンボルを最適化し、名前を変更します。 PDBは最適化された名前を実際のコードベースにマッピングし、デバッガーを実行中の実行ファイルにアタッチして、まるでDebugモードで作業しているかのようにブレークポイントを設定することができます。 顧客向けのプロダクションアプリケーションの場合は、デプロイ後に問題を診断できるように、各リリースと一緒に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のアドバイスは明快です: レジストリを変更しないでください。

レジストリに慣れている開発者にとっては、2つのエントリはシンプルです。 各コマンドは、適切なキーの下に名前付きシェルコマンドを作成し、実行可能ファイルの完全パスを指し、実行時にターゲットディレクトリまたはファイルパスを渡す %V または %1 プレースホルダーを含みます。新しいコンテキストメニューエントリが表示される前に再起動が必要な場合があります。

まとめ: 一度配布して永遠に使用

[10:21 - 10:30] 配布プロセス全体は2ステップです: フォルダーに公開し、右クリックメニューに実行ファイルを登録します。 インストーラーも、更新メカニズムも、クラウドサービスも不要です。単一目的のユーティリティとしては、そのシンプルさこそがポイントです。

結論

[10:30 - 10:40] 要約すると、フレームワーク依存と単一ファイル設定で dotnet publish は、どこにでもドロップできる軽量な実行可能ファイルを生成します。 2つのレジストリエントリがそれをWindows Explorerのコンテキストメニューアクションにします。

ビデオ全体を通しての教訓は制限です。 デプロイ方法をアプリケーションの範囲に一致させてください。 個人利用向けに作られたユーティリティは、何千もの顧客に配布される製品と同じインフラを必要としません。そして、そう取り扱うことは、ツールを作った時短を侵食するメンテナンス作業を生むだけです。

例のヒント: 個人プロジェクトでもPDBファイルを保持してください。 それらを実行可能ファイルと同じフォルダーまたは近くのアーカイブに保管してください。もし後になってユーティリティが予期せぬ動作をした場合、PDBがあればソースから再コンパイルすることなく、Visual Studioを接続してリリースビルドをデバッグできます。

彼のYouTubeチャンネルでフルビデオを見て、.NETデスクトップアプリケーションのデプロイに関する知見をさらに得ましょう。