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)

Microsoft wasn't kidding when they promised to defeat version number checks. You'll have to use the FileVersionInfo class, kernel32.dll is always around. — Hans Passant, Sep 01 '15 at 17:52
@HansPassant No, you do not. Frankly, that's hideous advice. Microsoft is under no obligation to update the file version. There's little reason to ever detect the OS version in the first place. — EKW, Oct 26 '15 at 20:38
Both of you are not correct: From what is told, MS supports generally still old version checks, IF the manifest contains the correct key!! 2nd:"There's little reason to ever detect".. ahem.. You are right, that many developers used it wrong, hindering running apps on modern windows versions. In "standard" apps it should be avoided, but there are plenty of reasons where you need this, e.g. in setups, and in any cases where things work in different Windows versions differently. Activating windows features as .NET for example behave totally different in detail. — Philm, Nov 11 '15 at 00:39

score 1 · Answer 1 · edited May 23 '17 at 10:33

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.

Philm · Answer 2 · 2015-11-11T01:00:09.810

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 (e.g. 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, e.g. 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.

Targetting Win 10 from app.manifest C#

2 Answers2