The real problem
Under the hood, the WindowChrome class binds its ResizeBorderThickness to SystemParameters.WindowResizeBorderThickness which in turns uses the Win32 API GetSystemMetrics to determine the system border size.
However, the behavior of this method changes depending of the subsystem version set in the executable PE header. If compiled only for Windows Vista and later (version >= 6.0), it will return thinner borders than if compiled for older operating systems. More information on this in this SO answer.
When compiling against .NET 4.5, the C# compiler sets this version to 6.0 since .NET 4.5 cannot be used on XP. However, the WindowChrome class seems to rely on the legacy behavior and thus fails to calculate the glass size correctly on Windows Vista and 7.
Solutions
Use .NET 4
You can compile against .NET 4 to force the compiler to use 4.0 as its subsystem version value. The ribbon is available for WPF 4 as a separate download. Note that even with this solution, you should uncheck “Enable the Visual Studio hosting process” in the project properties for debugging purposes. Otherwise, the vshost.exe process will be used, which is flagged with a subsystem version of 6.0.
Change the subsystem version
Edit: Olly provided a way to do this in the comments:
Add a property in the project file
<subsystemversion>5.01</subsystemversion>that falsely indicates that
the code can run on Windows XP.
Ignore the system
You can change the WindowChrome.WindowChrome attached property on your window and use the values that you want, thus completely ignoring the system values. You should never do that, but you can.
Fill a bug
There is an existing bug on Connect about the change in behavior of GetSystemMetrics but it all comes down to the subsystem version so it’s rather a feature from a Microsoft view point. However, the WindowChrome class should really be fixed to work correctly under Vista/7, especially since it’s now built in .NET 4.5.