views:

84

answers:

1

The following manifest is added to my .exe.:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
     <ms_asmv2:security>
      <ms_asmv2:requestedPrivileges>
       <ms_asmv2:requestedExecutionLevel level="asInvoker" />
      </ms_asmv2:requestedPrivileges>
     </ms_asmv2:security>
    </ms_asmv2:trustInfo>
  <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

but when I view the manifest (for example using Kenny Kerr's Manifest View) the application, windowsSettings and dpiAware tags are seemingly duplicated:

 <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
... general properties ...
     <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;
          <dpiAware>true</dpiAware> 
        </asmv3:windowsSettings>
     </asmv3:application>
     <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
         <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"&gt;
          <dpiAware>true</dpiAware> 
         </asmv3:windowsSettings>
     </asmv3:application>
  </assembly>

Any idea why this happens, and would it cause any problems?

A: 

After doing an awful lot of experiments and trying various versions of mt.exe to embed the manifest as suggested on some sites, I noticed a pattern; in all the samples I saw, the manifest filename seemed to always match the project or executable name, but with a '.manifest' appended.

My manifest filename did not totally match, so I rename it to match the Visual Studio project name for my application. I also changed the 'Additional Manifest Files' option in the Manifest Tool properties to, '$(ProjectDir)$(ProjectName).manifest', rather than my previous hardcoded filename.

Together, these changes worked and provided me with an executable with a correctly embedded manifest.

Sam
"Additional Manifest Files" causes the manifest to be *merged* with the auto generated manifest."app.exe.manifest" is a common name for the final generated manifest as, with this name, it can be placed in the same folder as 'app.exe' and be loaded by the system without having to be embedded as a resource. This is also why, choosing the exact same name is a bad idea for a manifest fragment (i.e. a manifest added via additional manifest files) as you now have a piece of the final manifest masquerading as the complete manifest.
Chris Becke