ClickOnceの魔物を調教する：証明書枯渇の回避と、バージョン跨ぎのデータ継承の極意
社内ニッチアプリの配布において、ClickOnceほど手軽で強力なデプロイメントツールはない。しかし、この「手軽さ」の裏側には、多くのVB.NET開発者が一度は踏み抜く地雷が埋まっている。
「ある日突然、アプリが起動しなくなった。原因は証明書の期限切れだ」
「アップデートしたら、ユーザーが丹精込めて入力したローカル設定やSQLiteのDBが消滅した」
これらは初歩的なミスではない。ClickOnceというブラックボックスのライフサイクル、そしてWindowsのセキュリティコンテキストを理解していないが故に起こる、構造的な必然なのだ。
本稿では、レガシーとモダンが混在する現場を生き抜くシニアエンジニアに向け、証明書のライフサイクル管理と、バージョンアップ時におけるローカルデータの死守・移行に関する極限の知見を授ける。
—
1. 自己署名証明書（.pfx）の呪縛と「更新」の正しい作法
ClickOnceで発行されるアプリには、コード署名が必須である。開発PCのVisual Studioにデフォルトで備わっている「テスト用証明書」をそのまま本番運用していなか？
テスト用証明書は、作成日から1年で確実に「有効期限切れ」を迎える。期限が切れた瞬間、エンドユーザーの端末ではアプリの自動更新どころか、起動すらもWindows Defender SmartScreenによって阻害される。
証明書更新の正しい手順
証明書の有効期限切れを防ぐには、Visual Studioのプロジェクトプロパティに依存せず、PowerShellを用いて強固なSHA-256署名証明書を明示的に生成・管理する必要がある。
以下のスクリプトは、10年間の有効期限を持つ新しい証明書を生成し、証明書ストアに格納した上で、プロジェクト用の`.pfx`としてエクスポートする実務的スクリプトだ。
— 10年間有効なコード署名用自己署名証明書の生成 (PowerShell) —
$certName = “MyCompany_ClickOnce_Master”
$cert = New-SelfSignedCertificate `
-Type CodeSigningCert `
-Subject “CN=Internal Development Department, O=MyCompany, C=JP” `
-KeyLength 2048 `
-HashAlgorithm “SHA256” `
-NotAfter (Get-Date).AddYears(10) `
-CertStoreLocation “Cert:\CurrentUser\My”
パスワード付きPKCS#12 (.pfx) としてエクスポート
$securePassword = ConvertTo-SecureString “P@ssw0rd_Strict_202X” -AsPlainText -Force
Export-PfxCertificate -Cert $cert -FilePath “C:\Deploy\Certificates\MasterKey.pfx” -Password $securePassword
Visual Studioでの紐付けと「拇印（Thumbprint）」の固定
生成した`.pfx`をプロジェクトにインポートする際、注意すべきは「拇印の不一致」だ。開発者が変わるたびに証明書が異なると、ClickOnceは「異なるアプリからの改ざん」と検知して更新を拒絶する。
プロジェクトファイル（`.vbproj`）を直接テキストエディタで開き、以下のように署名情報をハードコード、またはビルドサーバーのパイプラインで動的に注入する構成にリファクタリングせよ。
—
2. バージョンアップの悲劇：ローカルデータ消滅のメカニズム
ClickOnceアプリのアップデート時、最も現場から悲鳴があがるのが「設定ファイルやローカルDBの消失」だ。
ClickOnceは、アプリケーションをバージョンごとに完全に分離されたディレクトリ（例：`AppData\Local\Apps\2.0\…\`）に展開する。
そのため、アプリケーションフォルダ直下に設定ファイル（`config.json` や `data.sqlite`）を配置している場合、新しいバージョンに移行した瞬間、前回のデータは古いディレクトリに取り残されるか、綺麗に消去される。
これを防ぐための決定版が、Windows APIを活用した「ユーザーAppData（`%LocalAppData%` または `%AppData%`）への動的パス解決」と、初回起動時のデータ移行ロジックである。
極限まで最適化されたデータストアパス解決クラス (VB.NET)
オブジェクトのライフサイクルを考慮し、アプリケーション全体のコンテキストで一度だけパスを確定させ、GC（ガベージコレクション）に無駄な負荷をかけない設計を実装する。
Imports System.IO
Imports System.Runtime.InteropServices
Public NotInheritable Class ApplicationDataRepository
‘ インスタンス化させない静的クラス
Private Sub New()
End Sub
‘ 実行ファイル名から一意のカンパニー/アプリ構造を生成
Private Shared ReadOnly CompanyName As String = “MyCompany”
Private Shared ReadOnly AppName As String = “NicheEnterpriseClient”
”’
”’
Public Shared Function GetLocalDataPath() As String
‘ %LocalAppData%\MyCompany\NicheEnterpriseClient を強制生成
Dim localAppData As String = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
Dim targetPath As Path = Path.Combine(localAppData, CompanyName, AppName)
If Not Directory.Exists(targetPath) Then
Directory.CreateDirectory(targetPath)
End If
Return targetPath
End Function
”’
”’
Public Shared Sub MigrateLegacyDataIfNeeded(currentVersion As Version)
Dim migrationFlagFile As String = Path.Combine(GetLocalDataPath(), “.migrated”)
‘ すでに移行済みの場合は即座にリターン（パフォーマンスの最適化）
If File.Exists(migrationFlagFile) Then Return
‘ ClickOnceの古い実行ディレクトリ、またはIsolatedStorageからのサルベージ処理
‘ ここでは例として、ClickOnce実行パス直下にあった “data.db” を探す
Dim executionDir As String = AppDomain.CurrentDomain.BaseDirectory
Dim legacyDbPath As String = Path.Combine(executionDir, “data.db”)
Dim destinationDbPath As String = Path.Combine(GetLocalDataPath(), “data.db”)
Try
If File.Exists(legacyDbPath) AndAlso Not File.Exists(destinationDbPath) Then
File.Copy(legacyDbPath, destinationDbPath, True)
End If
‘ 移行完了フラグを書き込み、二度と実行させない
File.WriteAllText(migrationFlagFile, currentVersion.ToString() & ” on ” & DateTime.Now.ToString(“yyyy-MM-dd”))
Catch ex As Exception
‘ ログ出力基盤へスロー（UIスレッドをブロックしないよう非同期推奨）
System.Diagnostics.Trace.WriteLine($”Data migration failed: {ex.Message}”)
End Try
End Function
End Class
—
3. アプリケーション起動時のライフサイクル制御
上記の移行ロジックと証明書の整合性を担保するため、`ApplicationEvents.vb`（あるいは `Main` エントリポイント）で、イベント駆動型の初期化フックを構築する。
Windows Formsのアーキテクチャにおいて、UIスレッドが描画を完了する前に重いI/O処理を行うと、起動遅延（フリーズと誤認される現象）を引き起こす。非同期初期化のパターンを取り入れるべきだ。
Namespace My
‘ VB.NETの MyApplication 拡張イベント
Partial Friend Class MyApplication
Private Sub MyApplication_Startup(sender As Object, e As Microsoft.VisualBasic.ApplicationServices.StartupEventArgs) Handles Me.Startup
‘ ストリームの競合を防ぐため、UI表示の最先でデータ移行と整合性チェックを走らせる
Dim currentVer As Version = System.Deployment.Application.ApplicationDeployment.CurrentDeployment.CurrentVersion
‘ バックグラウンドスレッドで安全に移行処理をキック
System.Threading.Tasks.Task.Run(Sub()
ApplicationDataRepository.MigrateLegacyDataIfNeeded(currentVer)
End Sub)
End Sub
End Class
End Namespace
—
4. チーフアーキテクトからの最終提言
ClickOnceは「古い技術」として片付けられがちだが、イントラネット環境や閉域網における閉じたエコシステムにおいては、今なお最強の自動デプロイメント機構である。
しかし、その利便性に甘え、デフォルト設定のまま運用を続けることは、時限爆弾を抱えてシステムを運用するに等しい。
1. 証明書は自己管理し、10年スパンのライフサイクルをコードで担保せよ。
2. データは絶対にClickOnceのアプリ領域に置くな。`Environment.SpecialFolder` を経由した永続化パスへ即座に退避せよ。
3. バージョンアップ時のマイグレーションコードは、初回起動時に一度だけ走るイミュータブルな設計にしろ。
この3点を徹底した瞬間、ClickOnceは「手間の掛かる配布ツール」から「鉄壁の社内ニッチアプリ基盤」へと変貌を遂げる。コードの細部に宿る神を恐れず、堅牢なシステムを構築し続けよ。
