Manual test: a tool that opts in with IDpiAwarePlugin gets the real DPI

[skfd]

The other half of the change: a tool that says it can take the real DPI should get it. This is what a tool author will do, so it is worth walking the path they walk.

Measured at 96 dpi already: the sample tool without the interface comes out UNAWARE; with the interface and a fresh scan it comes out PER_MONITOR_V2. What is not tested is what that looks like at 150% on a tool that has actually been written for it.

The trap, first

XrmToolBox caches what it knows about a tool in Plugins\manifest.json and only rescans an assembly whose version has changed. Adding IDpiAwarePlugin to a tool without a new version leaves the old metadata in place and the tool is still created unaware — silently. It cost me a build cycle to find; a tool author shipping a release will not hit it, but anyone testing locally will.

It is written into the interface's own documentation, and it is the first thing to check if this ticket seems to fail.

Walk the path

cd C:\Users\kk\Code\XrmToolBox
git checkout high-dpi-opt-in

1. Open Plugins\MsCrmTools.SampleTool\Plugin.cs and add the interface to the factory class, not the control:

   public class Plugin : PluginBase, INoConnectionRequired, IPayPalPlugin, IDpiAwarePlugin

2. Build, refresh the sandbox, and delete the cached manifest:

   & "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\MSBuild.exe" `
       XrmToolBox.sln -p:Configuration=Debug -m
   $sandbox = "$env:TEMP\xtb-dpi-sandbox"
   Copy-Item .\Plugins\MsCrmTools.SampleTool\bin\Debug\MsCrmTools.SampleTool.dll "$sandbox\Plugins\" -Force
   Remove-Item "$sandbox\Plugins\manifest.json" -Force
   .\XrmToolBox\bin\Debug\XrmToolBox.exe /overridepath:$sandbox

3. Open the sample tool and ask the machine:

   C:\Users\kk\Code\xrm-icons\tools\dpi-spike\bin\WindowProbe.exe XrmToolBox

What should be true

• The tool's window now reads PER_MONITOR_V2, not UNAWARE
• So does every control in it
• At 150%: the tool is sharp, like the shell around it — and, because the sample tool is laid out in pixels like every other tool, it may well be wrong: clipped labels, a squashed layout. That is the correct outcome for a tool that claims something it cannot do, and it is worth a screenshot as an illustration of what the interface is promising.
• Take the interface off again, rebuild, delete manifest.json, and it goes back to UNAWARE

Then the real one

Icons (~/Code/xrm-icons) is laid out in the font it is drawn in rather than in pixels, so it is the first tool that can honestly implement this. It is worth opening at 150% with the interface on:

• Rows, boxes and captions are whole — no clipping
• The icon grid's thumbnails are drawn at 144 dpi, not stretched from 96
• The in-context preview draws at the right size

That is the pair this whole scheme is meant to produce: one tool sharp and correct, every other tool exactly as it was.