There's a few things for your application in Windows Vista that you can control using a manifest. Perhaps the most well-known use for manifests is to specify the use of the comctl32.dll version 6, which is needed to use visual styles with your application. I'm not talking about this though, as this has been the case since XP, and there's no problem here with .Net since you can (and probably do) use Application.EnableVisualStyles() instead of a manifest.

Vista also offers some other stuff which you can control with manifests: requested execution level and high-DPI compatibility (aka DPI awareness).

The first you'll probably know: with UAC enabled, applications running on Vista don't get admin privileges by default, even if the current user is a member of the Administrators group (a good post about how this actually works can be found here). If you do need admin privileges, the application must be elevated. You can do this manually by right-clicking the application executable or shortcut and choosing "Run as administrator". Additionally, Vista uses some heuristics to automatically prompt for elevation for some apps.

But the recommended approach to doing this is by specifying the "requestedExecutionLevel" attribute in your application's manifest. You can use the "requireAdministrator" value to force elevation, but even if you don't need elevation it has benefits to use a manifest (specifying "asInvoker" to indicate you don't need anything special in this case). If you do this, you're sure that Vista's heuristics will never accidentally elevate your application when it doesn't need to be. Additionally, using a manifest will disable file and registry virtualization (a technique that allows badly behaved applications to think they can write to protected locations such as Program Files or HKEY_LOCAL_MACHINE, when in fact they can't; the writes are redirected to a virtualized location). Disabling virtualization helps enforce that your app behaves properly (since writes to those locations will now actually fail instead of be redirected) and makes sure it behaves consistently on x64; a .Net 2.0 application (compiled with the default "Any CPU" setting) when run under an x64 version of Windows will run as a native x64 application, and x64 processes never use virtualization.

The second, less well-known thing you can do with manifests in Vista is mark your application DPI aware. There are two ways to do this: by using the SetProcessDPIAware() function in the Win32 API, or by using a manifest. In my experience, the former method will break .Net's automatic scaling in some circumstances, no matter how early you call the function. The manifest approach doesn't have this problem. If your application is not marked DPI aware, it will be scaled by the Desktop Window Manager under non-standard DPI values, leading to reduced image quality (most notably, fuzzy text). Of course, only mark your application as DPI aware when it actually is DPI aware: be sure to test your application with different DPI settings!

A manifest that controls these two settings is shown below:

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

Now there's two ways you can include this manifest: as an external file named "YourExecutable.exe.manifest" or by embedding it into your executable. I vastly prefer the latter method since it eases deployment.

This is where it gets tricky (and also .Net specific; everything I've said so far applies to both native and .Net apps). Where Visual C++ automatically embeds manifests in executables, the C# and VB compilers do not offer this possibility. Fortunately, we can embed the manifest ourselves, using mt.exe (which is shipped with Visual Studio, and also with the Windows SDK):

mt.exe -manifest YourExecutable.exe.manifest -outputresource:YourExecutable.exe;#1

Looks simple enough. But wait! If the assembly was strong named, embedding the manifest invalidates the hash and thus breaks the executable (the latest version of mt.exe will warn you of this). The solution is to re-sign with sn.exe (comes with the .Net Framework SDK):

sn.exe -Ra YourExecutable.exe YourStrongNameKey.snk

Now wouldn't it be nice if this could be done automatically? Fortunately, it can, using build events. Build events can be found in the project properties in Visual Studio. For C# projects, it's a separate tab in the list on the left ("Build Events"). For VB projects, use the "Build Events" button at the bottom of the "Compile" tab. Set the post-build event command line to the following:

"$(DevEnvDir)..\..\VC\bin\mt.exe" -nologo -manifest "$(ProjectDir)app.manifest" -outputresource:"$(TargetPath);#1"
"$(DevEnvDir)..\..\sdk\v2.0\Bin\sn.exe" -q -Ra "$(TargetPath)" "$(ProjectDir)strongnamekey.snk"

You may need to adjust the paths of mt.exe and sn.exe depending on your Visual Studio installation. You will also need to modify the name of the strong name key file and manifest file.

There's one thing left. If you use the latest version of mt.exe, it will now perpetually warn you about the need to re-sign your assembly, which Visual Studio picks up on and shows in the Error List. To prevent that, check the "Delay sign only" box on the "Signing" tab of the project settings. Now your assembly will not actually be signed when mt.exe is run, so there's no warning. Sn.exe will correctly sign it afterwards.

Categories: Programming
Posted on: 2007-07-06 13:53 UTC.