Windows服务无法通过MSI安装程序在几台计算机上安装

Question

I have developed an MSI setup with WiX, which includes a windows form application in c# .Net 2.0 framework and a windows service. When I run the setup, it gets installed successfully in all win 7, but fails in few win 7 and all win 8 machines by showing the privilege error ("Product: mysetup -- Error 1920. Service 'service displayname' (servicename) failed to start. Verify that you have sufficient privileges to start system services.") while trying to start the service at installation. Then I created an App.config file inside my windows service project and according to this link I wrote the following line which helped the setup get installed in all the win 7 machines till now, but no luck for any win 8 machine.

<runtime><generatePublisherEvidence enabled="false"/></runtime>

Regarding the service details, I have written the methods OnStart and OnStop inside my service. It actually starts the win form exe file at windows start-up. I have made the StartType property as Automatic at ServiceInstaller page and Account as LocalSystem at ServiceProcessInstaller page. I have also written the codes below inside WiX to install my service.

<ServiceInstall Id="ServiceInstaller" Type="ownProcess" Name="*******" DisplayName="******" Description="****** description" Start="auto" Account="LocalSystem" ErrorControl="ignore" Vital="yes" />
<ServiceControl Id="ServiceInstallerControl" Start="install" Stop="uninstall" Remove="uninstall" Name="******" Wait="yes" />

Presently, The setup and the windows service gets installed and runs fine in any win 7 machine, but fails in any win 8 and machine. Windows Event Viewer shows no detail but "msi setup fails".

Please note that, I have not added any ClickOnce or Publisher certificate yet for my application. I have planned to do it later, if that is not the reason for installation failure. How can I solve this or get the error details or debug this any way? Please help.

EDIT:

PhilDW's answer is very important to note. My win form application (.exe file) which my service tries to run, does not show up as a GUI but yes it actually interacts with the desktop and to achieve that I have followed and implemented this link . This is working fine on win xp and win 7 as of now and the service starts the win from app successfully whenever a user logs on. Not sure about win 8 or higher, hope this method does not get deprecated or blocked or barred by Microsoft Windows in higher versions for any security purpose (I mean, could this happen? what will be the solution then for interacting with desktop through LocalSystem windows service).

After Morten Frederiksen's answer I did the following. On one Win 8 (32bit) pc, I checked inside Windows->Microsoft.Net->Framework folder which contains 4.0 and 4.5 but no 2.0/3.0/3.5 exactly as told by Morten. Now, my win form app already contains the supportedRuntime entry in its App.config file as suggested by Morten, but no luck with the installation. So I added the same ie

<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

inside the App.config of my windows service (I think it's unnecessary) and ran the MSI after a rebuild, but the same thing happens, the installation rolls back displaying the same privilege error message. Then I tried to run my win form app manually. It shows the message "The app requires .Net framework 3.5. Would you like to download and install .Net framework 3.5 (2.0 and 3.0 included)". I clicked on "OK", it downloaded and installed the frameworks and ran the win form app .exe file successfully. Now that all frameworks are installed, I tried to reinstall my MSI and now it successfully gets installed and the service starts along with the app which actually does the desktop interaction now successfully.

So, Morten Frederiksen's answer helped me solve my case. It is clear now that in my case it is the absence of the required framework which caused the failure of the win form app which again caused the windows service to fail to start, which in turn caused the roll back of the MSI installation.

Answer 1

There are a few areas I'd look at, in no particular order. I'm assuming your forms app attempts to show UI, among some other assumptions.

You have wait=yes in the service startup. This causes Windows to wait until the service has started properly, the default wait time being 30 seconds. This means the service must get out of OnStart within 30 secs to show that it has in fact started ok. If there is a delay in there because of what's going on, you may find a timing issue could randomly cause it to finish within 30 seconds or not.

The second issue is probably more serious. I do not believe you can start a Winforms app from a service for the same reason that local system services can no longer interact with the desktop - it exposes a system account to the user's desktop for shatter attacks. This may be strictly enforced in Windows 8, so the Winform process dies and has a downstream effect on the service, depending how it's coded. This is relevant https://msdn.microsoft.com/en-us/library/windows/desktop/ms683502(v=vs.85).aspx

Finally, even if you could interact with the desktop there's a potential timing issue after reboots. If your service starts up and fires off the Winforms app, then this can happen before anyone has logged on, unless your code waits for a logon, because services run all the time when there is no interactive user, so your service is starting a Winforms app that tries to access a non-existent desktop. I don't know if you've handled this area or not.

I suggest you install your Winforms app and add a shortcut to the Start->Startup programs menu so that it starts when a user logs on. Then it can establish communication with the running service.

Answer 2

My guess is that you don't have .NET 2.0/3.0/3.5 installed on the Windows 8 PCs. By adding some configuration in your .config file you can enable .NET 2.0 applications on a system with only .NET 4.0/4.5 installed.

Here's how: https://msdn.microsoft.com/en-us/library/jj152935%28v=vs.110%29.aspx