Program Compatibility Assistant thinks my app is an installer

Question

I have created a .NET C# WinForms application on Win 7 RTM x64, which let's say I have called DataInstaller.

When I run this program outside of the debugger (just an empty form with no functionality at the moment), it works fine until I close the form. I then get a message from the Program Compatibility Assistant that says:

This program might not have installed correctly

I then get the option to reinstall using recommended settings or to say that the install did work as expected.

If I name the app 'DataThingy' this isn't an issue, I guess this is related to the way that programs called *Setup gain a UAC shield icon.

I assume that there will be something simple that I can put in the application manifest to prevent this?

I'm not sure if this occurs on Vista as I don't have access currently.

Changing the name is not an option and turning off UAC is not an option so please don't suggest this!

Edit:

OMG.

It seems that if any of the following are true, UAC sticks its oar in:

Exe name contains the word Installer

AssemblyInfo.cs

AssemblyTitle contains the word 'Installer'
    e.g. [assembly: AssemblyTitle("DataInstaller")]
AssemblyProduct contains the word 'Installer'
    e.g. [assembly: AssemblyProduct("Data Installation Utility")]

'Installer' can also be 'Setup'.

It beggars belief, it really does. Obviously one of the old VB6 programmers got relocated into the UAC team over at Redmond.

I still need a workaround, I'm not prepared to accept that my application can't possibly be an called an installer because it doesn't touch the registry or put any files in the Program Files folder.

I assume that UAC would put the machine into total lockdown if I tried to execute my application called IAmAVirus.exe. (Actually, I daren't try it because I'm not entirely convinced that I'm just being silly)

Honourable

Actually, Windows just checks the filename for words like "setup" or "install" to determine if something is an installer or not. Yes, it's dumb... Can something be done about it? I wonder... Good Q, though. – Meagre

I hope so, because it's all a bit too 'magic stringy' for my liking.. thanks for the vote! – Honourable

@Wim - No, it seems to be AssemblyTitle like the post suggests. Verified on my Win7 SP1 machine for PackageInstaller.exe - no problem if assembly title is PackageNstaller – Murdoch

Answer 1

Add this into your manifest.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
  <application>
    <!--The ID below indicates application support for Windows Vista -->
    <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
    <!--The ID below indicates application support for Windows 7 -->
    <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    <!--The ID below indicates app support for Windows 8 -->
    <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
    <!--The ID below indicates app support for Windows 8.1 -->
    <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
  </application>
</compatibility>

The GUIDs for all the operating systems in the previous example provide down-level support. Apps that support multiple platforms do not need separate manifests for each platform.

Taken from App (executable) manifest.

Rhizotomy

Works like a charm, even when deployed to ProgramFiles! Thanks Justin. – Honourable

This didn't make any difference when I tried it... my tool is called "ccsetup" since it replaces the original settings tool with that name, but as long as either the name or version information have the word "setup" in it, the compatibility junk keeps popping up. When I remove it, the problem immediately disappears, but I don't want it to have a different name. – Lewallen

{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38} for Windows 8. Read more: msdn.microsoft.com/en-us/library/windows/desktop/… – Funderburk

{1f676c76-80e1-4239-95bb-83d0f6d0da78} for Windows 8.1 – Seka

See this blog post. – Flipper

Answer 2

Like Workshop Alex will make a guess based on filenames.

But have you tried to add a manifest file ? That allows you to spesify what access rights you need to be run the application.

MSDN on how to create one from Visual studio Another link article that help.

Granivorous

Just adding the manifest did the trick (although I did try that before posting this, honest!). For a bit of further info, see: blogs.msdn.com/cjacks/archive/2009/06/18/… and technet.microsoft.com/en-us/library/dd638326%28WS.10%29.aspx. Thanks. – Honourable

As an update, no, this didn't work. As soon as the exe gets deployed to another location, such as <Program Files> the PCA rears its ugly head again. – Honourable

Old question but the filename was what was doing it for me. Changed installer to tool and it worked fine. Thanks for the tip @Granivorous – Titration

Answer 3

I just had this problem and ended up fixing it by making sure my assembly title within the AssemblyInfo.cs file and the assembly name of my cs.proj file matched up. When they weren't synced up it was throwing this error, making them the same caused it to go away. Not sure if it applies to your situation, but same error similar circumstances, might be worth a try and avoid the accepted answer of ignoring the error all together.

Telpher

That is exactly the problem I was facing. Thanks for point it out man, even though question was answered. I was thinking it was manifest settings but I had changed the Assembly name in project properties and it was not matching the Default namespace. – Banks