You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
src/WpfVisualTreeMcp.Injector/README.md describes the injector as unimplemented. It has been overtaken by the actual implementation and now actively misleads anyone reading it to understand how attaching works.
Current text vs. reality
The README says:
The injector is currently a stub implementation. Full DLL injection into external .NET processes requires advanced techniques that are beyond the scope of the initial implementation.
and closes with:
Files
ProcessInjector.cs - Stub implementation with P/Invoke declarations for future use
But ProcessInjector.cs is ~18 KB of working code implementing the CreateRemoteThread + LoadLibrary approach that the README lists as hypothetical "Option 2 / Future": architecture detection, a native bootstrapper, multi-location DLL probing, and an out-of-process WpfInjectorHelper.exe for the x64-server → x86-target case.
Related knock-on effects:
"Option 1: Self-Hosted Mode (Recommended for Development)" is presented as the recommended path, though injection is now the shipped default (wpf_attach(auto_inject=true)).
The four approaches under "Option 2: Native Injection (Future)" read as open design questions when Create WPF Visual Tree MCP server #1 has in fact been chosen and built.
Suggested fix
Rewrite the README to document what the injector actually does — the injection sequence, the role of WpfInspectorBootstrapper.dll and WpfInjectorHelper.exe, and the CLR-flavour split between the net48 and net8.0-windows Inspector builds. That last part is currently only discoverable by reading the <None Include> blocks in WpfVisualTreeMcp.Server.csproj.
Worth noting that this stale README costs real debugging time in combination with #14: someone hitting "Bootstrapper DLL not found" who opens this README is told the injector is a stub and that self-hosting is the intended path, which points away from the actual bug (the bootstrapper simply never being built or packaged).
Summary
src/WpfVisualTreeMcp.Injector/README.mddescribes the injector as unimplemented. It has been overtaken by the actual implementation and now actively misleads anyone reading it to understand how attaching works.Current text vs. reality
The README says:
and closes with:
But
ProcessInjector.csis ~18 KB of working code implementing the CreateRemoteThread + LoadLibrary approach that the README lists as hypothetical "Option 2 / Future": architecture detection, a native bootstrapper, multi-location DLL probing, and an out-of-processWpfInjectorHelper.exefor the x64-server → x86-target case.Related knock-on effects:
wpf_attach(auto_inject=true)).Suggested fix
Rewrite the README to document what the injector actually does — the injection sequence, the role of
WpfInspectorBootstrapper.dllandWpfInjectorHelper.exe, and the CLR-flavour split between thenet48andnet8.0-windowsInspector builds. That last part is currently only discoverable by reading the<None Include>blocks inWpfVisualTreeMcp.Server.csproj.Worth noting that this stale README costs real debugging time in combination with #14: someone hitting "Bootstrapper DLL not found" who opens this README is told the injector is a stub and that self-hosting is the intended path, which points away from the actual bug (the bootstrapper simply never being built or packaged).