Using power shell to install service creates issues.

[peterkottas]

Using power shell to install service creates issues.

[gitfortee]

Ok. this is what i found out.. the service started working once i upgraded to .net core version 2.0 !!! To recap, even with .net core version 1.1, there was no difficulty in running the application stand-alone or as a service with a "local system" account. The service started to fail only when i configured it to run using a service account..

However, with the same service account and after upgrading my projects and libraries to core version 2.0, the service is working fine.. strange.!!

For your Ref: #45 (comment)

[gitfortee]

@ragnarol @xVishera @kmcgain @andymac4182 @PeterKottas tagging folks hoping they can take a look at the issue..

@andymac4182

I have this working with sc.exe using a standalone app. I am sure you could get the same working with New-Service

can you please share the script that worked for you.? were you able to specify a service account while installing the service using sc.exe.??

TIA.

[xVishera]

@gitfortee Remove "PlatformServices.Default.Application.ApplicationBasePath" from your path.combine and your application should write the logs.

After that, try installing the service just with "myservice.exe action:install"

[gitfortee]

@xVishera I would also want to specify an user account for the service. when i use "myservice.exe action:install" and specify a user name and password, it will appear on the 'Path to executable' property of the service. which i can't allow.

Meanwhile, removing "PlatformServices.Default.Application.ApplicationBasePath" does not still write log files. I expect the files to be created under "C:\Apps\ServiceApp\logs" which did not happen..

I guess will still need "PlatformServices.Default.Application.ApplicationBasePath" such that the "logs" folder is created in the path where the "ServiceApp.dll" is present. ??

[gitfortee]

Meanwhile, i tried using sc.exe but ending up in the same kind of issues. the script looks like below. I put these inside a batch file but the results are the same even when i tried to run each of the commands separately from the command prompt.

I made sure to run the command prompt as "Administrator". Also added the service account to the "Logon As Service" rights.

sc.exe delete "ServiceApp"

sc.exe create "ServiceApp" binPath= "C:\Apps\ServiceApp\ServiceApp.Console.dll action:run" DisplayName= "ServiceApp" start= auto

sc.exe config "ServiceApp" obj= "domain\serviceaccount" password= "somepassword"

[xVishera]

@gitfortee If you run the .exe instead of installing, it works ?

[gitfortee]

it works perfectly when :

I ran it with the command "dotnet ServiceApp.dll"

Or when

I used a batch file with the command "dotnet ServiceApp.dll action:install"

However.. I also need to specify a service account to use. At this time, I have to manually go to the servies.msc to change the Logon property of the service. Which is an overkill and more manual intervention every time i need to deploy a new version of the service.

I do not intend to expose the password by using "dotnet ServiceApp.dll action:install username:<> password:<>". Since running this command exposes the password via the 'Path to executable' property of the service.

[gitfortee]

@xVishera this is how the "path to executable" looks like "C:\Program Files\dotnet\dotnet.exe "C:\Apps\ServiceApp\ServiceApp.dll" action:run" when i used

C:\Apps\ServiceApp> dotnet ServiceApp.dll action:install

Notice that the action:run is outside the double quotes.. is this still OK?

[gitfortee]

I guess your comment on removing the "PlatformServices.Default.Application.ApplicationBasePath" DO write the logs However I could not find useful information from the error log.

I also think to check if everything is OK with the service account that i am using. will keep you posted.

[xVishera]

@gitfortee It's hard to tell because I never needed to install this way, But I would give a try with

C:\Program Files\dotnet\dotnet.exe "C:\Apps\ServiceApp\ServiceApp.dll action:run""

Because "action:run is part of the command to ServiceApp.dll

[gitfortee]

@ragnarol @xVishera @kmcgain @andymac4182 @PeterKottas

Folks, once again.. the issue still persists. there is no way for me to capture a global exception handler in order to get more details about the

Faulting module path: C:\windows\system32\KERNELBASE.dll 
Exception code: 0xe0434352

looks like when i specify the service account, i am getting into this error. Meanwhile i check the service account, any help that you could provide is valuable.

thanks.

[ragnarol]

hi @gitfortee

I install the services using the following powershell:

& dotnet $exe action:install name:$serviceName username:$username password:$password

And neither the username or the passowrd get exposed in the Path to Executable.

[gitfortee]

@ragnarol thanks for the response.. do you suggest to create an .exe? meaning a self-contained exe.? at present i have a .dll as a framework dependent deployment. I can try creating an .exe and see how it proceeds.

Also, the $exe in your power shell command.. should it contain the absolute path to the .exe ? such as C:\ServiceApp\ServiceApp.exe ?

[ragnarol]

Hi, sorry it's not an exe it is a dll. The powershell variable is called exe because I copy that bit from another project.

I run the script through octopus deploy so I understand that it runs it from the folder where the DLL is, so no need of using a full path for it.