Released package ships without WpfInspectorBootstrapper.dll - all injection fails

[gentledepp]

Summary

WpfInspectorBootstrapper.dll is never built by any build or CI path, and is not committed as a prebuilt binary. The released package therefore ships without it, and every injection attempt fails — which makes wpf_attach (and consequently every other tool) unusable against any process that does not already self-host the Inspector.

Repro

Using the published WpfVisualTreeMcp-v0.12.0-win-x64.zip against a 32-bit .NET Framework 4.8 WPF app:

wpf_attach(process_id=…, auto_inject=true)
→ {"success":true, "inspector_status":
   "Injection failed - …\\server\\native\\x86\\WpfInspectorBootstrapper.dll not found"}

wpf_find_elements(...)  → error (no in-process agent)

The file is absent from the release zip for both architectures:

server/native/x86/  WpfInjectorHelper.exe/.dll/.json, WpfVisualTreeMcp.Injector.dll,
                    WpfVisualTreeMcp.Inspector.dll, WpfVisualTreeMcp.Shared.dll
server/native/x64/  WpfVisualTreeMcp.Inspector.dll, WpfVisualTreeMcp.Shared.dll

Everything the injector needs is there except the native bootstrapper.

Root cause

Four things line up:

1. The C++ project is not in the solution. WpfVisualTreeMcp.sln lists Server, Shared, Inspector, Injector, InjectorHelper, SampleWpfApp and Tests. src/WpfVisualTreeMcp.Bootstrapper/WpfVisualTreeMcp.Bootstrapper.vcxproj is not among them.

2. No CI job builds it. release.yml builds with dotnet build WpfVisualTreeMcp.sln — and the dotnet CLI cannot build .vcxproj at all, so adding it to the solution would not by itself fix this. build.yml does uses: microsoft/setup-msbuild@v1.3 and then never invokes msbuild; it only runs dotnet build on the C# projects. Both setup-msbuild steps are currently vestigial.

3. No prebuilt binary is committed. src/WpfVisualTreeMcp.Bootstrapper/ contains exactly WpfInspectorBootstrapper.cpp and the .vcxproj — there is no checked-in build/ output for the <None Include> globs to pick up.

4. The packaging step fails silently. WpfVisualTreeMcp.Server.csproj (lines 69–94) brings the DLL in behind an Exists() guard:

   <None Include="..\WpfVisualTreeMcp.Bootstrapper\build\Win32\Release\WpfInspectorBootstrapper.dll"
         Condition="Exists('..\WpfVisualTreeMcp.Bootstrapper\build\Win32\Release\WpfInspectorBootstrapper.dll')"
         Link="native\x86\WpfInspectorBootstrapper.dll">

   When the file is missing the build succeeds and quietly omits it — no warning, no error. That is how a release can be cut with a complete-looking native/ layout that is missing the one file that matters.

At runtime ProcessInjector.GetBootstrapperDllPath() probes the three locations (assembly dir → native/{arch}/ → ../WpfVisualTreeMcp.Bootstrapper/build/{Win32|x64}/Release/), finds nothing, and InjectInspector throws with:

Bootstrapper DLL not found (x86). Build the native bootstrapper first or run 'dotnet publish' to include it.

That guidance cannot be followed as written — dotnet publish is structurally incapable of building the vcxproj.

Suggested fix

In build.yml and release.yml, after setup-msbuild, build both architectures with MSBuild (not dotnet) before the dotnet build / dotnet publish steps that consume the output:

- name: Build native bootstrapper (x86 + x64)
  run: |
    msbuild src/WpfVisualTreeMcp.Bootstrapper/WpfVisualTreeMcp.Bootstrapper.vcxproj `
      /p:Configuration=Release /p:Platform=Win32
    msbuild src/WpfVisualTreeMcp.Bootstrapper/WpfVisualTreeMcp.Bootstrapper.vcxproj `
      /p:Configuration=Release /p:Platform=x64

Note the output-path mismatch this interacts with — see #15.

Two things worth doing alongside it:

• Turn the silent omission into a hard failure. Drop the Exists() conditions, or add an MSBuild <Error> when the bootstrapper is missing and a release is being packed, so a broken package cannot be published again.
• Add a smoke test to CI that attaches to samples/SampleWpfApp via real injection and asserts a non-empty visual tree. Any of the four causes above would have been caught by it.

Happy to send a PR if that would help.