Summary
The bootstrapper's output directory is defined relative to $(SolutionDir), but WpfVisualTreeMcp.Server.csproj looks for it at a path relative to the project directory. The two agree only when the .vcxproj is built standalone. This is a trap for anyone fixing #14 via the most natural route.
Detail
WpfVisualTreeMcp.Bootstrapper.vcxproj (all four configurations):
<OutDir>$(SolutionDir)build\$(Platform)\$(Configuration)\</OutDir>
WpfVisualTreeMcp.Server.csproj expects:
..\WpfVisualTreeMcp.Bootstrapper\build\Win32\Release\WpfInspectorBootstrapper.dll
..\WpfVisualTreeMcp.Bootstrapper\build\x64\Release\WpfInspectorBootstrapper.dll
i.e. src/WpfVisualTreeMcp.Bootstrapper/build/{Win32|x64}/Release/.
Those resolve to the same place only when MSBuild is invoked directly on the .vcxproj, where $(SolutionDir) falls back to the project directory.
The obvious fix for #14 — "add the vcxproj to WpfVisualTreeMcp.sln and build the solution" — silently breaks this. Building via the solution sets $(SolutionDir) to the repository root, so the DLL lands in <repo>/build/Win32/Release/, the Exists() conditions in Server.csproj evaluate false, and the package ships without the bootstrapper again — with a green build, since nothing errors when the glob misses.
ProcessInjector.GetBootstrapperDllPath()'s third probe location hardcodes the same project-relative assumption, so the dev-tree fallback breaks in exactly the same way.
Suggested fix
Make the output path independent of how MSBuild is invoked, e.g. anchor it to the project directory:
<OutDir>$(MSBuildProjectDirectory)\build\$(Platform)\$(Configuration)\</OutDir>
That keeps the existing Server.csproj globs and ProcessInjector fallback valid whether the project is built standalone, from the solution, or from CI.
Summary
The bootstrapper's output directory is defined relative to
$(SolutionDir), butWpfVisualTreeMcp.Server.csprojlooks for it at a path relative to the project directory. The two agree only when the.vcxprojis built standalone. This is a trap for anyone fixing #14 via the most natural route.Detail
WpfVisualTreeMcp.Bootstrapper.vcxproj(all four configurations):WpfVisualTreeMcp.Server.csprojexpects:i.e.
src/WpfVisualTreeMcp.Bootstrapper/build/{Win32|x64}/Release/.Those resolve to the same place only when MSBuild is invoked directly on the
.vcxproj, where$(SolutionDir)falls back to the project directory.The obvious fix for #14 — "add the vcxproj to
WpfVisualTreeMcp.slnand build the solution" — silently breaks this. Building via the solution sets$(SolutionDir)to the repository root, so the DLL lands in<repo>/build/Win32/Release/, theExists()conditions inServer.csprojevaluate false, and the package ships without the bootstrapper again — with a green build, since nothing errors when the glob misses.ProcessInjector.GetBootstrapperDllPath()'s third probe location hardcodes the same project-relative assumption, so the dev-tree fallback breaks in exactly the same way.Suggested fix
Make the output path independent of how MSBuild is invoked, e.g. anchor it to the project directory:
That keeps the existing
Server.csprojglobs andProcessInjectorfallback valid whether the project is built standalone, from the solution, or from CI.