Visual Studio Installer Projects 2022でショートカットが白紙や既定のアイコンになる場合は、最初に「実行ファイル自体」「インストーラーが作ったショートカット」「インストール済みアプリ一覧」「タスクバー」のどこで違うかを確認します。それぞれ設定元が異なるため、アイコンキャッシュの削除だけで直るとは限りません。
現行.NETのPublish Itemsと、インストール後に起動するapphostの.exeを区別して確認すると、DLLへの誤ったショートカットを切り分けられます。
この記事では、.NET Frameworkと現行.NETの出力の違い、ショートカットのTarget・Icon・IconIndex、配布したMSIの確認を順に扱います。手元のプロジェクトと対象PCを検証して原因を絞る手順であり、拡張機能全体に共通する不具合と断定するものではありません。
最初に、どこのアイコンが違うか確認する
| 現象 | 先に確認する設定・実物 |
|---|---|
| ビルド／発行した.exeも既定のアイコン | アプリ側のアイコン設定と、実際に配布する.exeのリソース。 |
| .exeは正しいがデスクトップだけ白紙 | そのショートカットの対象とIcon、IconIndex。 |
| デスクトップは正しいがスタートメニューだけ違う | User’s Programs Menu側の別ショートカットの設定。 |
| 設定のインストール済みアプリ一覧だけ違う | SetupプロジェクトのAddRemoveProgramsIcon。 |
| 起動したウィンドウ・タスクバーだけ違う | WPF Window.Iconなどアプリのウィンドウ設定。既存のピン留めも区別。 |
| 開発PCは正しく別PCで違う | 同じ配布物か、参照先の存在、インストールされた版、表示キャッシュ。 |
スクリーンショットだけで判断せず、表示場所・OS・Visual Studioと拡張機能の版・対象フレームワーク・x86/x64/ARM64・新規インストールか更新かを記録します。これで「アイコンがない」という同じ症状でも、出力不足と表示上の問題を分けられます。
拡張機能とプロジェクトの種類を確認する
MicrosoftのMarketplace配布ページは、この拡張機能をVisual Studio 2022および2026向けと案内しています。ARM64 OS用は同ページで別の版を案内しているため、開発環境に合うものを確認します。拡張機能の表示名が「2022」であることだけを理由に、他のVisual Studioの対応を決めつけません。
Setup Project（.vdproj）のショートカットを扱う話と、MSIX・ClickOnceの設定は同一ではありません。既存プロジェクトを修正する前にソース管理やバックアップを取り、構成マネージャーでアプリとSetupのビルド対象・構成・プラットフォームを確認します。
.NET Frameworkと現行.NETで出力の選び方が違う
Microsoftの現行.NET向けInstaller Projects資料は、.NET Core 3.1と.NET 5以降を対象として、Primary OutputではなくPublish Itemsを選ぶよう案内しています。.NET Framework向けに使われる「プライマリ出力を追加する」という説明を、現行.NETへ一律に当てはめないでください。
| アプリの種類 | Setupに含める内容の考え方 |
|---|---|
| .NET Framework、従来のC++など | 対応するPrimary Outputと必要な依存ファイルを確認。 |
| 現行.NETのWindowsデスクトップアプリ | Add → Project OutputでPublish Itemsを選び、発行内容を確認。 |
| 現行.NETの自己完結型 | 発行プロファイルを作り、Publish ItemsのPublishProfilePathに対応する相対パスを設定。 |
| ASP.NET Core | このWindowsデスクトップ向けワークフローの対象外。Web用の配置方式を確認。 |
「Publish Itemsはアイコンが壊れるから使わない」という説明は適切ではありません。正しい発行内容を含めることと、ショートカットがどの実行ファイルを起動するかは別の確認です。発行先にあるアプリ名.exe、DLL、runtimeconfig.json、deps.jsonなど必要なファイルを、選んだ発行方式に沿って確認します。
.NET SDKのUseAppHostはネイティブ実行ファイルの生成を制御するプロパティです。UseAppHost=falseの構成では、.exeがないこと自体が発行設定による場合があります。Windowsで.exeを直接起動する設計なら、発行フォルダーに目的のapphostが存在するか確認します。DLLを.exeのように扱ってショートカットを作らないでください。
アプリ側のアイコンを、配布する.exeで確認する
アイコンを設定したあと、アプリをビルド／発行し、Setupへ含める実際のファイルを確認します。Debugの出力だけを見てReleaseや発行フォルダーも正しいと判断しないでください。エクスプローラーの表示と、必要なら開発用リソース確認ツールで埋め込まれたアイコンを照合します。すべての.exeのプロパティに「Iconタブ」があるわけではありません。
WPFではWindow.Iconの公式説明が、プロジェクトのApplicationIconによるアセンブリアイコンと、個々のWindow.Iconを区別しています。XAMLのWindow.Iconだけを変更して、配布する.exeやMSIのショートカットも変更されたと判断しないでください。
WPFのプロジェクトファイルに追加する一例です。既存のPropertyGroup内へ設定し、指定した.icoがプロジェクト内の実在するファイルであることを確認します。アプリ全体の完成した.csprojを置き換える例ではありません。
<PropertyGroup>
<ApplicationIcon>Assets\App.ico</ApplicationIcon>
</PropertyGroup>.icoには表示に使う複数のサイズを含められます。拡張子だけをPNGから.icoに変更しても変換にはなりません。まず正しい形式と各サイズの見た目を確認し、64×64を入れれば必ず安定する、サイズを多く含めると必ず壊れる、という固定ルールでは扱いません。
File SystemでショートカットのTargetを確認する
SetupプロジェクトのFile Systemエディターを開き、Application Folder内の出力と実行ファイルを確認します。MicrosoftのSetupプロジェクトの例では、追加した出力からCreate Shortcut to…を作り、User’s Programs Menuへ移動しています。これはC++の例なので、現行.NETの出力選択は前述のPublish Itemsの資料に従います。
- インストールするアプリの実行ファイルを確認し、それを起動するショートカットを作成する。
- 必要な配置先のUser’s Desktop／User’s Programs Menuへ移動し、各フォルダーに実際に項目があるか確認する。
- 各ショートカットを選択し、F4などでプロパティのTarget・Arguments・WorkingFolder・Icon・IconIndexを読む。
- 現行.NETで出力グループの対象がDLLになっていないか、インストール後の実物と照合する。
- 発行済み.exeを明示的なファイルとして参照する構成なら、参照元が毎回正しい発行先を指し、必要な発行ファイルも同じ版で含まれるよう管理する。
デスクトップとスタートメニューに配置したものは別のショートカットです。一方だけのIcon変更が他方へ自動的に反映されるとは限りません。コピー／移動の操作をした後も、両方のプロパティを個別に確認してください。
手動で追加した.exeの参照が古いbinフォルダーに固定されていると、新しい発行をしても古いファイルがSetupへ入ることがあります。出力グループを使う構成と、固定ファイルを追加する構成のどちらかを明確にし、同じアプリの重複した古い出力を混在させません。
IconとIconIndexを個別に設定・検証する
対象のショートカットのIcon選択画面で、意図したアプリの.exeやアイコンリソースを選び、表示される候補から目的の画像を確認します。IconIndexはリソース内の位置であり、「常に0を入れればよい」という決め方ではありません。ファイルを入れ替えた場合は、その候補が今も存在するか確認します。
Windows InstallerのShortcutテーブルは、起動対象のTargetと、Iconテーブルを参照するIcon_、非負のIconIndexを別の列として定義しています。つまり、Targetが正しいことだけでIconの設定も正しいと確定しません。作業フォルダーや引数もアイコンとは別の項目です。
IconテーブルのDataはPE（.dll／.exe）や.ico形式のデータを扱います。一方、広告ショートカットに関する公式の説明には、ショートカット用のアイコンファイルのバイナリ形式と対象の拡張子について条件があります。「別の.icoを指定したから必ず失敗」「.icoならどのMSIでも必ず成功」と単純化せず、拡張機能が生成したMSIとショートカットの種類を確認します。.icoを.exeへ名前だけ変更する対応はしません。
開発PCにしかない絶対パスや、一時的なビルドフォルダーを配布先の表示元にしていないかも確認します。アイコンを含むファイル／リソースが、対象PCでインストーラーの設計どおり利用できることが必要です。
AddRemoveProgramsIconとタスクバーは別に確認する
「設定 → アプリ → インストールされているアプリ」の表示だけが違う場合は、SetupプロジェクトのAddRemoveProgramsIconを確認します。MSIではARPPRODUCTICONがIconテーブルのキーを指定します。これを変更しても、デスクトップのショートカットのIconが同時に設定されるわけではありません。
起動中のWPFウィンドウならWindow.Iconなどを確認します。既にピン留めしたアイコンだけが古い場合は、今回インストールしたスタートメニュー項目と起動中のウィンドウを比較し、必要なら古いピンを外して現在の項目をピン留めし直します。更新のたびに必ず壊れる、すべてをグループポリシーで回避できる、という一般化はしません。
同じビルドの配布物で新規インストールと更新を比較する
- アプリ側のビルド／発行を完了してからSetupをビルドし、出力ウィンドウの成功と出力先を確認する。
- MSI、setup.exe、ローカル配置する前提条件のファイルを、同じビルドの組として識別する。
- 配布用ZIPを作る場合は、対象PCで一式を展開し、相対位置を保つ。ZIP内から部分的に起動しない。
- 検証用PC／仮想環境で新規インストール後の.exeと両ショートカットを確認する。
- 同じ環境を戻して旧版からの更新も試し、実行ファイルの版・配置先・ショートカットが期待どおりか確認する。
setup.exeのBootstrapperは、.NETなど選択した前提条件をアプリより先に導入する役割です。WPF／WinFormsのフレームワーク依存配置では対応する.NET Desktop Runtime、コンソールでは.NET Runtimeを検討し、版とアーキテクチャを合わせます。自己完結型でも、アプリ固有の他の前提条件まで不要になるとは限りません。
前提条件をsetup.exeへ任せる構成なら、そのsetup.exeから検証します。必要条件が既に満たされた管理配布などではMSIを使う構成もあるため、「必ずsetup.exeでなければアイコンが壊れる」とは扱いません。インストール方式の違いと、Icon・Targetの設定を分けて確認します。
旧版だけに症状が出る場合は更新設計を調べる
新規インストールは正常なのに旧版からの更新だけで古い.exe／アイコンが残るなら、インストール先、ファイルの版、ProductVersion、ProductCode、UpgradeCodeと旧版の検出・削除の動作を確認します。MSIのメジャーアップグレードはProductCodeの変更を伴う製品更新です。アイコン表示の切り分けのためだけに、これらのコードを無計画に変更しません。
開発中に検証用環境で旧版をアンインストールして新規導入する比較はできますが、本番の利用者には設定・データの保持や移行を検証してから配布します。アンインストールすればすべてのキャッシュやユーザーデータが消える、とも保証しません。
MSIの内容とインストールログを確認する
プロジェクトの表示と実際のMSIに差がある疑いがあれば、Windows SDKのMSIデータベース閲覧ツールなどで、まずコピーしたMSIを読み取ります。ShortcutのDirectory_・Target・Component_・Icon_・IconIndex、Iconの参照、File／Componentの対応を確認し、プロジェクトにあるからMSIにも必ず入ったと決めません。配布物を直接手編集して署名や再現性を失う対応は避けます。
検証環境でインストールを行うときに詳細ログを取る例です。MySetup.msiは実際の検証用パッケージに置き換え、C:\InstallTestなどログ先フォルダーを先に用意します。これは表示専用の調査ではなくインストール操作です。前提条件を既に確認した場合に使い、必要なBootstrapperの動作を省略するための例ではありません。
msiexec.exe /i "C:\InstallTest\MySetup.msi" /L*V "C:\InstallTest\install.log" /norestartmsiexecの公式仕様では/L*Vで詳細ログを記録し、/norestartで自動再起動を抑えます。再起動が不要になるという意味ではありません。ログでCreateShortcuts周辺、失敗コード、参照ファイルや旧版の処理を確認し、共有時はユーザー名・パスなどの情報を必要に応じて伏せます。
キャッシュを疑うのは設定と配布物を確認した後
同じ正しい.exe・ショートカットを別の検証ユーザーやPCで表示でき、特定の環境だけ古い見た目になるなら、表示キャッシュの影響を検討できます。まず作業を保存してサインアウト／再起動し、同じ項目で比較します。設定不備を残したままキャッシュを消しても、正しいアイコンの参照先は追加されません。
この記事ではアイコンキャッシュの一括削除、レジストリ変更、全ユーザーのキャッシュ消去を最初の対処にしません。対象が広告ショートカットの場合は通常の.lnkのTarget表示だけで判断できないこともあるため、必要ならMSIのテーブルとインストール結果を照合します。
よくある質問
ショートカットをPublish Itemsから作ると必ず白紙になりますか？
必ずそうなるとは言えません。現行.NETではPublish Itemsが公式の出力選択です。実際に作られたショートカットが起動するapphostの.exeと、Icon・IconIndexの参照を別に確認します。
デスクトップだけ直したらスタートメニューも直りますか？
両方にあるショートカットの設定を確認します。コピーした別項目のプロパティが自動的に連動するとは限りません。
インストール済みアプリ一覧のアイコンだけ違います
SetupプロジェクトのAddRemoveProgramsIconを確認します。ショートカットのIconやWPFのWindow.Iconとは別の設定です。
まとめ
まず表示場所と実物を特定し、アプリの.exe、出力グループ、各ショートカットのTarget・Icon・IconIndex、AddRemoveProgramsIconの順に確認します。現行.NETではPublish Itemsと実行用apphostを区別し、同じ配布物で新規導入と更新を比較すると、設定・出力・更新設計・表示キャッシュのどこに問題があるかを絞れます。
コメント