On 22 Nov., 23:55, r norman <r_s_nor...@comcast.net> wrote:
> On Mon, 22 Nov 2010 14:39:16 -0800 (PST), Lothar Behrens
>
>
>
> <lothar.behr...@lollisoft.de> wrote:
> >On 22 Nov., 20:23, r norman <r_s_nor...@comcast.net> wrote:
> >> On Mon, 22 Nov 2010 09:17:07 -0800 (PST), Lothar Behrens
>
> >> <lothar.behr...@lollisoft.de> wrote:
> >> >Hi,
>
> >> >I have written a Windows Service (for the test - a dummy to divide and
> >> >conquer) and the service cannot be intalled on the Windows 7
> >> >Enterprise (64Bit version) box.
>
> >> >On that box there was installed the .NET 4.0 Client profile and as I
> >> >have seen, all earlier versions are installed in the C:\Windows
> >> >\Microsoft.Net directory. For a try I have removed that version but no
> >> >success.
>
> >> >The service is a .NET 3.5 version service and I have tried building
> >> >Any CPU, x86 and x64. All has failed with the following error, that
> >> >the application is not a valid Win32 Application.
>
> >> >As other sources state that Windows 7 installs .Net, I did not see any
> >> >reason why such a simple test service fails to load whereas a GUI
> >> >application will run (compiled in 64Bit).
>
> >> >I am using Visual Studio 2008 9.0.21022.8 RTM with .NET 3.5 SP1.
>
> >> >The installer does start the service after it has installed it and
> >> >then it fails. If I do not have any custom installer
> >> >steps, the service will fail to start from services.msc either.
>
> >> >Any help please !!!!
>
> >> Service startup problems can be a real headache. *
>
> >> I have a "debug log" system that writes all sorts of information
> >> relating to startup including passing through key steps and catching
> >> and logging all exceptions. *It is invaluable.
>
> >> More invaluable is writing the service to be dual startup: *if you
> >> have a command line saying "-debug" (or something similar) it will run
> >> as a console based application program and write all debug log
> >> information to the screen.
>
> >I have a debug GUI application, as I have abstracted the internal
> >functionality off of the service. The GUI has not been tested on
> >64Bit. But it is crazy that a simple dummy service can't get started
> >on 64Bit. The service is simply that what visual studio template
> >generates.
>
> >So this in my view - simply - should work.
>
> Should does not mean does. *Welcome to services programming. *That is
> why I suggested the debug log. *My console app isn't the innards of
> the services but the identical code that runs as a service (if started
> by the service controller) or as a console app (if started with a
> specific command line). *Another enormous advantage of this is that
> you can then run it from the debugger as an application program and
> see exactly what is happening in the first steps of startup.
>
> An alternative is to make the service sleep for, say, ten seconds
> before doing anything at all giving you time to connect a debugger to
> it.
>
> One thing you must realize is that the service runs, depending on how
> you set it up, under different credentials than an application program
> and, if it tries to access any system resources, you have to make sure
> it has rights to do so.
I have identified the problem. The installation class was located in a
DLL and the service in an executable. Thus the Service installer
routine has used the DLL as the service. That will fail.
But when I use the installer class in an executble I get an error
while the commit phase.
Does any one have advice on 64Bit Windows 7 with the class as shown
here to enable on demant service registration (to mate the installer
updateable)?
using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel;
using System.Configuration.Install;
using System.ServiceProcess;
namespace ServiceSetupDll
{
[RunInstaller(true)]
public partial class ServiceInstaller : Installer
{
public ServiceInstaller()
{
bool isInstalled = false;
ServiceController[] controllers =
ServiceController.GetServices();
foreach (ServiceController ctrl in controllers)
{
if (ctrl.DisplayName == "Service")
{
isInstalled = true;
}
}
if (!isInstalled)
{
InitializeComponent();
}
else
{
this.serviceController1 = new
System.ServiceProcess.ServiceController();
this.serviceController1.ServiceName = "Service";
this.BeforeUninstall += new
System.Configuration.Install.InstallEventHandler(this.ServiceInstaller_BeforeUninstall);
this.BeforeInstall += new
System.Configuration.Install.InstallEventHandler(this.ServiceInstaller_BeforeInstall);
this.AfterInstall += new
System.Configuration.Install.InstallEventHandler(this.ServiceInstaller_AfterInstall);
}
}
private void ServiceInstaller_AfterInstall(object sender,
InstallEventArgs e)
{
serviceController1.Start();
}
private void ServiceInstaller_BeforeUninstall(object sender,
InstallEventArgs e)
{
try
{
serviceController1.Stop();
int repeat = 10;
while ((repeat-- > 0) && serviceController1.Status ==
ServiceControllerStatus.Running)
System.Threading.Thread.Sleep(1000);
}
catch
{
}
}
private void ServiceInstaller_BeforeInstall(object sender,
InstallEventArgs e)
{
try
{
serviceController1.Stop();
int repeat = 10;
while ((repeat-- > 0) && serviceController1.Status ==
ServiceControllerStatus.Running)
System.Threading.Thread.Sleep(1000);
}
catch
{
}
}
private void ServiceInstaller_AfterUninstall(object sender,
InstallEventArgs e)
{
// Does not really work.
//ServiceProcessInstaller = new
System.ServiceProcess.ServiceProcessInstaller();
//ServiceInstaller = new
System.ServiceProcess.ServiceInstaller();
//ServiceProcessInstaller.Account =
System.ServiceProcess.ServiceAccount.LocalSystem;
//ServiceProcessInstaller.Password = null;
//ServiceProcessInstaller.Username = null;
//ServiceInstaller.ServiceName = "Service";
//ServiceInstaller.StartType =
System.ServiceProcess.ServiceStartMode.Automatic;
//ServiceProcessInstaller.Uninstall(e.SavedState);
//ServiceInstaller.Uninstall(e.SavedState);
}
}
}
|
Similar Threads
