Windows resources file and manifest dpi awareness

Usage
, ,
1

I have trouble linking both resources (*.rc for a windows icon) as well as a manifest into my application.
First i only had a manifest in which i set the DPI awareness to PerMonitor. This worked as expected: moving the window to a different dpi monitor triggered a WM_DPICHANGED message.
I linked the manifest like this into my application:

target_sources(myapp PRIVATE manifest.manifest)

Then i wanted to add an icon. So i created a resources file (*.rc) and linked it like this:

add_custom_command(
    OUTPUT 	 app.o
    COMMAND  cd ${CMAKE_BINARY_DIR} && windres.exe app.rc -o app.o -F pe-i386
)
target_sources(myapp PRIVATE app.o manifest.manifest)

The icon was present but the manifest was not linked into the application. I checked with the manifesttool.
I then searched for a solution and found the following. I included the manifest in the resources file, disabled the linking of a standard manifest and only linked the resource object explicitly.

Resource File:

#include "winres.h"
1 24 manifest.manifest
IDI_ICON1 ICON DISCARDABLE "myapp.ico"

cmake:

set(CMAKE_EXE_LINKER_FLAGS /MANIFEST:NO)

target_sources(myapp PRIVATE app.o)

With this the warning stating that there are multiple .rsrc sections is gone. My manifest is linked in correctly (checking with manifesttool again). However the monitor aware dpi does not work. No WM_DPICHANGED is sent to my application.

The manifest should be correct, since it works if directly linked. Also from what i can observe, the manifest is present in the application (checking both with manifesttool as well as resource hacker).

Here is the extracted manifest from manifesttool:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
        <assemblyIdentity version="14.0.0.0" processorArchitecture="x86" name="myapp" type="win32"></assemblyIdentity>
        <description>My Application</description>
		<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
			<application> 
				<!-- Windows 10 --> 
				<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"></supportedOS>
				<!-- Windows 8.1 -->
				<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"></supportedOS>
				<!-- Windows Vista -->
				<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"></supportedOS> 
				<!-- Windows 7 -->
				<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></supportedOS>
				<!-- Windows 8 -->
				<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></supportedOS>
			</application> 
		</compatibility>
        <dependency>
                <dependentAssembly>
                        <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
                </dependentAssembly>
        </dependency>
        <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
                <security>
                        <requestedPrivileges>
                                <requestedExecutionLevel level="asInvoker"></requestedExecutionLevel>
                        </requestedPrivileges>
                </security>
        </trustInfo>
        <asmv3:application>
                <asmv3:windowsSettings>
                        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
                        <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2,PerMonitor</dpiAwareness>
                </asmv3:windowsSettings>
        </asmv3:application>
</assembly>
2

It also seems as if it is working correctly in my debug build. The only options i am explicitly changing for the debug build are:

set(CMAKE_CXX_FLAGS_DEBUG "-Wall")
set(CMAKE_CXX_FLAGS_RELEASE "-O2")
set(CMAKE_EXE_LINKER_FLAGS /MANIFEST:NO)

set(CMAKE_CXX_FLAGS_DEBUG "-g")

if(CMAKE_BUILD_TYPE STREQUAL "Debug")
    set(CMAKE_VERBOSE_MAKEFILE)
endif()
3

I turned out it worked perfectly and for some reason windows has the configuration cached. Moving the binary to a different location causes it to work