First posted to MSDN on Jun, 18 2009
I have an ongoing conversation with a customer whose application is now popping up a Program Compatibility Assistant dialog box, where it didn’t used to before (on either Windows Vista or Windows 7 beta). What’s going on?
Well, when I cracked the resources for the binary, you can spot right away that it’s going to trigger installer detection, given the presence of the word “Install” in multiple places. You can also turn on shim diagnostics and see that it’s wiring up with GenericInstaller.
But why wasn’t it popping PCA on Windows Vista? Is this a new PCA scenario? I explored that, and discovered that it was Scenario #1 – an app that we detect as a setup doesn’t leave anything behind in Add/Remove Programs. That suggests possible failure.
So, existing scenario, new PCA prompt, and the final bit of evidence: the application doesn’t prompt for UAC Elevation on either Windows Vista or Windows 7. You should now be able to connect all of the dots.
The application has a UAC manifest.
On Windows Vista, the presence of a UAC manifest disables PCA. On Windows 7, that’s not good enough. You have to have one of the new-fangled Windows 7 GUIDs in your manifest to avoid PCA annoyance.
So, if you’re following along, here’s what happened:
-
Customer has an app that looks suspiciously enough like an installer that the operating system is trying to intervene and make things work
-
Developer notices that, doesn’t want/need the elevation, wonders how to make it go away, and discovers our documentation saying how you can turn off setup detection by including a UAC manifest – being good law-abiding citizens, they do exactly that (at their own expense)
-
Unbeknownst to the developer, we came along behind their back and
changed the rules
to make our previous guidance null and void, and once again we’re annoying their users with dialog boxes that
make the developer look bad
-
Now the developer, if they wanted to make their users happy, would have to stop what they are doing, update their currently shipping app to include a manifest for an operating system that isn’t even released yet, so that Windows 7 can be more successful by having a more compatible and friendly OS (at their own expense)
-
Repeat for every subsequent version of Windows, as the Windows 7 GUID would no longer indicate Windows 8 compatibility either when it comes along
Does anyone else see anything wrong with this picture?
I’m trying to see what we can do about this, because I don’t think we’re being fair to developers right now. I believe that an asInvoker manifest is a pretty darned good indication that you’re not an installer, both from the perspective of GenericInstaller and PCA. I have absolutely no idea why somebody would disagree.
In the interim, rather than gripe about this (if you only know how many not-so-polite words and pejorative phrases I have already deleted from this blog post, you’d likely be very disappointed in me), I figured I’d tell you how you can fix it until whenever / if ever we address this:
Shim your application with SpecificNonInstaller.
I know of no other way to tell setup detection that “hey, you’re wrong” that will survive into the future. Because UAC Manifests only work on Windows Vista, Windows 7 Manifests will presumably only work on Windows 7, and who knows what you’ll need in the future?
What I don’t understand about PCA is, why haven’t we learned our lesson that asking the user a question every time we’re confused isn’t the right approach? <sigh />
