Program Compatibility Assistant believes my application is an installer

Question

I created the .NET C # WinForms application on Win 7 RTM x64, which allows me to say that I called DataInstaller.

When I run this program outside of the debugger (just an empty form with no function at the moment), it works fine until I close the form. Then I get a message from the program compatibility assistant that says:

This program may not be installed correctly.

Then I get the opportunity to reinstall using the recommended options or to say that the installation really worked as expected.

If I call the DataThingy application, this is not a problem, I think this is due to the way the programs called * Setup get the UAC shield icon.

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

I am not sure if this is happening in Vista since I do not have access at this time.

Changing the name is not an option, and turning off UAC is not an option, so please do not offer this!

Edit:

OMG.

It seems that if any of the following statements is true, the UAC inserts its paddle into:

The name Exe contains the word Installer

AssemblyInfo.cs

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

The "installer" can also be "Setup".

It breeds faith, it really is. Obviously, one of the older VB6 programmers has moved to the UAC team in Redmond.

I still need a workaround, I'm not ready to admit that my application cannot be called by the installer because it does not touch the registry or put files in the Program Files folder.

I assume that UAC will put the machine in full lock if I try to run my IAmAVirus.exe application. (Actually, I'm not trying to do this because I'm not quite sure that I'm just stupid)

Answer 1

Add this to 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 operating systems in the previous example provide lower-level support. Applications that support multiple platforms do not need separate manifests for each platform.

Taken from the application manifest (executable file) .

Answer 2

Like the workshop, Alex will make assumptions based on file names.

But did you try to add the manifest file? This allows you to use the permissions required to run the application.

MSDN on how to create it from Visual Studio Another article links in which help .

Answer 3

I had this problem and decided to fix it, making sure that my assembly header in the AssemblyInfo.cs file and the assembly name of my cs.proj file match. When they were not synchronized, it threw this error, forcing them to equally make it go away. I'm not sure if this applies to your situation, but the same mistake of similar circumstances might be worth a try and avoid the accepted answer of ignoring the error all together.