MENU

WPFのApplication TimelineがNot applicable toolsになる原因と解決策｜Visual Studio 2022（ProjectTypeGuids修正）

Visual Studio

Visual Studio 2022のWPFアプリでパフォーマンスを見たいのに、Performance Profilerの「Application Timeline」が「Not applicable tools」に入って選べない――そんな現象はプロジェクト判定が崩れているサインです。原因の探し方と復旧手順をまとめます。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

起きていること：同じソリューションのWPFなのに片方だけTimelineが無効

今回の状況を整理すると、同じソリューション内にWPFアプリが2つ（App1・App2）あり、どちらも.NET Framework 4.8でEXEを出力する構成です。ところが、Performance Profiler（診断ツール）を開くと、App2では「Application Timeline」を選べるのに、App1では「Not applicable tools」に分類されて選択できません。

プロジェクトの参照やターゲット、ビルド設定を見比べても明確な差が見えないとき、この手の問題は「Visual Studioがそのプロジェクトを“WPFアプリとして認識できていない”」ことが原因になりがちです。見た目は同じWPFでも、内部判定に使われるメタ情報が欠けていると、ツール側が対象外として弾きます。

Application Timelineとは何か

Application Timelineは、Visual StudioのPerformance Profilerで選べるツールの1つで、アプリの起動から実行中の時間軸に沿って、UIスレッドやイベント処理、フレーム、入力、レイアウト、レンダリングなどの“体感性能に直結する動き”を俯瞰しやすくするための機能です。WPFでは、UIが固まる・スクロールがカクつく・画面遷移が遅いといった症状の原因を「いつ」「どこで」起きたかの観点で追いやすくなります。

逆に言うと、Application Timelineが選べない状態は「プロファイラがそのプロジェクトをWPFの対象として扱えていない」か、「起動の仕方やオプションがツールの前提に合っていない」可能性を示します。

「Not applicable tools」が意味すること

Performance Profilerの画面で「Not applicable tools」に入るのは、ツールが壊れているというより、現在の起動方法・ターゲット・プロジェクト種別では、そのツールを適用できないという判定が出ている状態です。たとえば次のような要因で起きます。

  • スタートアッププロジェクトとして起動していない（実行中プロセスにアタッチ、Executable指定など）
  • 診断ツール起動時のオプションが競合している（Instrumentationや.NET Object Allocation Trackingなど）
  • プロジェクト種別が正しく認識されていない（WPFとして扱われていない）
  • 出力タイプやフレームワーク設定がWPFアプリとして成立していない

ポイントは、ツールの表示は「プロジェクトの設定」と「起動の文脈」の両方で決まることです。同じEXEでも、起動経路が違うだけで対象外になることがあります。

最初に確認したい前提条件チェック

App2では動いているのにApp1だけ動かない場合でも、まずは“落とし穴”になりやすい前提を短時間で潰しておくと、無駄な試行錯誤を減らせます。以下は現場で効くチェック項目です。

チェック項目見る理由確認方法の例
Visual Studio 2022を使っているかTimelineの提供・挙動はVSの世代で差が出るヘルプ→バージョン情報
WPFアプリのテンプレートとして認識されているかプロジェクト種別判定がズレるとツールが対象外になるプロジェクトの種類、csprojのメタ情報
.NET Framework 4.0以上か（今回は4.8）対応対象外のフレームワークだと選べないプロパティ→ターゲットフレームワーク
OutputTypeがEXE（WinExe）になっているかライブラリ扱いだとアプリとして起動できず対象外になりやすいcsprojの<OutputType>、またはプロパティ
起動は「Startup Project」からかRunning Process/Executable経由はNot applicableになりやすいスタートアッププロジェクト設定→F5起動
Instrumentation / .NET Object Allocation Trackingを有効にしていないか組み合わせによってTimelineが使えないケースがあるPerformance Profiler起動時のチェックを見直す

この段階で多いのが「App1は実行中プロセスにアタッチしていた」「Executable指定で起動していた」など、起動経路が違っていたケースです。Application Timelineを使うときは、基本的にプロジェクトをスタートアップにしてF5で起動する運用が安全です。

App2は動くのにApp1だけ動かないときの切り分け方

同じソリューションに正常系（App2）があるのは、切り分けにとって最強の材料です。原因は必ずどこかの差分に埋まっています。おすすめは次の順で差分を潰すことです。

  1. 起動の仕方（Startup Projectか、デバッグ/リリース、x86/x64/AnyCPU）
  2. プロジェクトの種別（WPFとして認識されているか）
  3. csprojのメタ情報（ProjectTypeGuidsなど）
  4. アプリ固有設定（app.manifest、app.config、プロファイル関連）
  5. Visual Studioのキャッシュ（.vs、コンポーネントキャッシュ、拡張機能）

特にcsprojは「見比べたつもりでも見落としやすい」領域です。WPFのテンプレートから逸脱していると、見た目が似ていてもプロジェクトシステム上の扱いが変わります。

結論：原因はcsproj内のProjectTypeGuidsの欠落・不正

今回のケースで最終的に判明した原因は、App1の.csprojファイル内にある<ProjectTypeGuids>が欠落している、または値が不正だったことでした。App2の.csprojにあるProjectTypeGuidsをApp1へコピーして置き換えたところ、App1でもApplication Timelineが使用可能になりました。

ProjectTypeGuidsが効いてしまう理由

従来形式（非SDK形式）の.csprojでは、Visual Studioは<ProjectTypeGuids>を含むメタ情報から「これはC#のWPFアプリ」「これはクラスライブラリ」「これは別の拡張テンプレート」などを判定します。ここが壊れていると、Visual Studio内部ではApp1がWPFとしての機能セットを持たないプロジェクトとして扱われ、WPF向けのツール（Application Timelineなど）が対象外になり得ます。

一方、SDK形式（Microsoft.NET.Sdk.WindowsDesktopなど）のプロジェクトでは、UseWPFなど別の仕組みで判定されることが多く、そもそもProjectTypeGuidsが存在しないこともあります。まず自分のプロジェクトがどちらの形式かを把握し、今回の手当てが有効なタイプか確認してください。

迷ったら、.csprojの先頭を見て形式を判定できます。

形式csprojの見分け方（代表例）WPF判定のキーになりやすい項目
従来形式（非SDK）<Project ToolsVersion=”…”> で始まり、ImportでMicrosoft.CSharp.targets等を読み込む<ProjectTypeGuids>、<OutputType>、<TargetFrameworkVersion>
SDK形式<Project Sdk=”Microsoft.NET.Sdk.WindowsDesktop”> 等で始まる<UseWPF>true</UseWPF>、<TargetFramework>net48</TargetFramework>

今回の「ProjectTypeGuidsをコピーして直る」パターンは、主に従来形式（非SDK）で起きやすいトラブルです。SDK形式でTimelineが出ない場合は、まずUseWPFや起動方法、診断オプション側の条件を疑うのが近道です。

解決手順：正しいProjectTypeGuidsを復元する

最短で直す方法は「動いているWPFプロジェクトの値をコピーする」ことです。GUIDの正解を外から探すより、同一環境・同一ソリューションで動いているApp2が正解データになります。

手順の全体像

  1. 正常なWPFプロジェクト（App2、または新規作成した空のWPF）を用意する
  2. 正常側の.csprojを開き、<ProjectTypeGuids>要素を探す
  3. その要素を丸ごとコピーする
  4. App1の.csprojを開き、<ProjectTypeGuids>が無ければ追加、あれば置き換える
  5. 保存→Rebuild→必要ならVisual Studio再起動
  6. App1をスタートアッププロジェクトにしてPerformance Profilerを開き、Application Timelineが出るか確認

csprojの編集例（表示用）

実際のGUIDはプロジェクト形式やテンプレートで変わる可能性があるため、必ずApp2（または新規WPF）からコピーしてください。配置イメージは次のようになります。

<PropertyGroup>
  <ProjectTypeGuids>（ここにApp2からコピーした値）</ProjectTypeGuids>
</PropertyGroup>

参考として、従来形式の「C# + WPFアプリ」では次のようなGUIDの組み合わせになることが多いです（環境やテンプレートで追加のGUIDが入る場合もあるため、最終的にはApp2や新規作成したWPFプロジェクトの値を優先してください）。

<ProjectTypeGuids>{60DC8134-EBA5-43B8-BCC9-BB4BC16C2548};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

反映されないときの追加アクション

csprojを直しても表示が変わらないときは、Visual Studioが古い判定をキャッシュしていることがあります。次を順に試すと改善することがあります。

  • ソリューションを閉じてVisual Studioを再起動する
  • App1を右クリック→「プロジェクトの再読み込み」（一度アンロードしてから）
  • bin/objフォルダを削除してからRebuildする
  • ソリューション直下の「.vs」フォルダを削除してから開き直す（閉じた状態で）

「なぜ無効なのか」を知る方法はあるのか

結論から言うと、Performance ProfilerのUI上で「なぜNot applicableなのか」を理由付きで表示してくれる仕組みは基本的にありません。実務では、差分比較と最小再現で原因を詰めるのが近道です。

実務で効く調査アプローチ

アプローチ狙いやり方
csproj/app.manifest/app.configの差分比較プロジェクト種別・起動条件・権限などの違いを炙り出すファイルを並べて比較、またはdiffツールを使う
新規WPFを作って設定を段階的に移植どの変更で壊れたかを特定する参照や設定を少しずつ追加して都度確認する
MSBuildのビルドログ（binlog）を取るプロパティの最終値やインポート差分を可視化するmsbuild /bl でbinlogを生成し、Viewerで確認する
Visual StudioのActivityLog.xmlを確認拡張機能やプロジェクトシステムのエラーの手掛かりを探すdevenv /log で起動してログを採取する

特に「App2ではOK」「App1だけNG」という状況では、アプリのコードそのものより、プロジェクトシステムが持つメタ情報に原因がある確率が高いです。今回のProjectTypeGuidsのように、気づきにくい1行が決定打になることも珍しくありません。

よくある落とし穴と追加チェックポイント

ProjectTypeGuids以外にも、Application Timelineが出ない／出たり出なかったりするケースがあります。現場で遭遇しやすいものをまとめます。

症状疑うポイント対処の方向性
Running ProcessやExecutableからは出ない起動経路が対象外スタートアッププロジェクトとしてF5起動に統一する
特定のオプションをONにするとTimelineが消えるツール間の競合Instrumentation / .NET Object Allocation Trackingを外して試す
App1だけプロジェクトアイコンやデザイナ挙動が違うプロジェクト種別の誤認識ProjectTypeGuidsやテンプレート由来の設定を見直す
設定を直したのに表示が変わらないキャッシュが残っている.vs削除、再読み込み、Rebuild、VS再起動を試す
デバッグ構成では出るがリリース構成では出ない最適化やシンボル、ビルド差分まずDebugで再現確認し、構成差分を縮めていく

再発防止の考え方：csprojの“整合性”を守る

ProjectTypeGuidsが欠落する場面は、手作業で.csprojを編集したときだけではありません。たとえば次のようなタイミングで起きがちです。

  • 古いVisual Studioのプロジェクトを新しい環境へ移行した
  • Gitのコンフリクト解消で.csprojの一部を誤って削除した
  • 別テンプレートの.csprojを流用してプロジェクトを手作りした
  • 一部だけSDK形式へ変換した／逆変換した

再発防止としては、「動く状態のWPFプロジェクトを雛形として維持する」「プロジェクトファイルは差分レビューを徹底する」「ツールが効かなくなったらまず起動経路とプロジェクト種別を疑う」といった運用が効きます。アプリのコードよりも、プロジェクトメタ情報の破損の方が“静かに”問題を引き起こすからです。

現場向けチェックリスト

Application Timelineが「Not applicable tools」になったら、次の順で確認すると効率的です。

優先度チェック内容メモ
高スタートアッププロジェクトとして起動しているかRunning Process/Executableは避ける
高Instrumentation / .NET Object Allocation Trackingを外して試したか競合でTimelineが消えることがある
高csprojの<ProjectTypeGuids>が正しいかApp2や新規WPFからコピーが確実
中OutputType（WinExe）やターゲット（.NET Framework 4.8）を再確認WPFアプリとして成立しているか
中キャッシュ削除や再読み込みを実施したか.vs、bin/obj、VS再起動

今回の事例では、最終的にProjectTypeGuidsの修正が決定打となり、App1でもApplication Timelineが正常に選べるようになりました。App2が動いているなら、同じ値をコピーして“Visual StudioがWPFと認識できる状態”に戻すのが最短ルートです。

Visual Studio
WPF Visual Studio 2022 csproj ProjectTypeGuids Application Timeline

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次