Manifest and the fusion cache

When you have an application without a manifest and you try to elevate it with an external manifest, you might get frustrated and get to the conclusion that this external manifest thing is flaky at best. The scenario goes something like this.

You install your legacy application (by which I mean there is no manifest with a requestedExecutionLevel specified) on a Vista machine. You launch the application and you see it is installer detected and for that reason, it prompts for credentials. You know that providing a manifest with that requestedExecutionLevel will make the installer detection go away. Since you don't want to link it in or use the mt.exe tool, you provide an external manifest in the form of myapp.exe.manifest and put that next to your app. Now, whatever you try to do with the requestedExecutionLevel, it just doesn't make a difference. Then you really get frustrated and move the file to another directory. Low and behold, the manifest is picked up. What in the world?

As you might know, the Windows folks have put a tremendous effort in optimizing the performance of the system. Superfetch is a good example. Numbers showed that resolving manifests and SxS probing caused a significant delay in start up time. So they came up with caching of the activation context. Basically, the second time you launch your application we no longer bother to look for a manifest since it wasn't there initially. When you move the executable (or change the time stamp somehow), the entry in the cache is not found and the loader looks for the manifest file again.