Targetting Win 10 from app.manifest C#

Question

Sir i am trying to target Win 10 from app.manifest in C# but, it seems to be not working.

app.manifest

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="1.0.0.0" name="MyApplication.app" />

  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v1">
    <security>
      <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
        <!-- UAC Manifest Options
             If you want to change the Windows User Account Control level replace the 
             requestedExecutionLevel node with one of the following.

        <requestedExecutionLevel  level="asInvoker" uiAccess="false" />
        <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />
        <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />

            Specifying requestedExecutionLevel element will disable file and registry virtualization. 
            Remove this element if your application requires this virtualization for backwards
            compatibility.
        -->
        <requestedExecutionLevel level="highestAvailable" uiAccess="true" />
      </requestedPrivileges>
    </security>
  </trustInfo>

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- A list of the Windows versions that this application has been tested on and is
           is designed to work with. Uncomment the appropriate elements and Windows will 
           automatically selected the most compatible environment. -->

      <!-- Windows 10 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />

      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />

      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />

      <!-- Windows Vista -->
      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />
    </application>
  </compatibility>
  <!-- Enable themes for Windows common controls and dialogs (Windows XP and later) -->

  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        processorArchitecture="*"
        publicKeyToken="6595b64144ccf1df"
        language="*" />
    </dependentAssembly>
  </dependency>
</assembly>

The Environment.OSVersion.Version returned is still v6.2.

Also, i would like to know where to include

_NT_TARGET_VERSION=$ (_NT_TARGET_VERSION_LATEST)

Answer 1

If you're building with Visual Studio, the manifest should automatically be compiled into the EXE. If that's not happening, remove the manifest from your project and re-add it. That's detailed in this similar question

If you're building with another toolchain, mt.exe , available as part of the Windows SDK, can be used to inject a manifest.

Alternately, if your application has no embedded manifest, you can include the manifest as an additional file. Simply modify the application name in the manifest to match your executable, then rename the manifest file itself to

<application>.exe.manifest

and place it in the same directory as your executable. Embedding a manifest is recommended, however.

Note that the manifest is cached on first-run of an application; updating the timestamp on the EXE or rebooting the machine will cause the manifest to be re-loaded the next time the application is launched.

Answer 2

It's RtlGetVersion now, folks ! :-)

https://msdn.microsoft.com/en-us/library/windows/hardware/ff561910%28v=vs.85%29.aspx

No, but this shouldn't be necessary normally, really! Reading the version should work with a proper manifest from what is told, and MS is NOT trying to hinder all GetVersion/GetVersionEx calls. Have you checked with mt.exe, if the manifest is cleanly incorporated? (I haven't tried Environment.OSVersion.Version yet, but maybe this is still a bug?)

If someone activated the compatibility mode for an app, even RtlGetVersion gets the wrong version.

The problem is, if you have no clean Win 10 manifest it may happen that compatibility assistent will define some programs (eg which look similar to names like setup, install, etc.) as legacy and marks them with compatibility flags. Weird solutions (not new, was the same since Win 7, I have seen many people nearly crying because of this) ;-).

To repeat what was the idea of making it more difficult to test for the Windows version: Too many developers misused the API and blocked the app working on Windows versions they didn't know yet. And the users then blamed Windows for incompatibility.. That's a very big mistake, and as the Y2K problem hardly tested and discovered years later. Apart from certified software, eg for nuclear meltdowns, which often is allowed only on certified hardware, testing for future versions should never block the app!

Testing for windows versions make of course still sense to react on known Windows incompatibilities and different feature sets.

In theory the manifest solution should overcome the mentioned problem, because only those who "know" a Windows version (key) can test for the correct version.