I have a windows service project in Visual Studio that I inherited from another developer, and I'm struggling to deploy the service to our server.
Is it possible to copy the build files from the Release folder to the server, and then run installutil on the exe?
I've tried it, and although the service install successfully, I'm getting an error 1053 when I start the service that
The service did not respond to the start or control request in a
timely fashion
Or is a setup project the only way to go?
If you just want to install a service some way other than an install utility, you can copy the output of the release folder of a windows service project to a directory and register the service using a Powershell command.
Related
At the moment I have a Windows Service and App (Desktop Tray Win Form App with Stop/Start buttons to stop the service and a PING to check the 3rd party API it uses it working and obtain the current balance - It's a Betfair Betting app)
At the moment I am running this off my Win 7 64 bit Desktop but we are moving to a dedicated server Win 2012.
Both the Win Service/Form are in the same project and they reference a DLL which I made that has all the code inside (connects to the DB, 3rd party Betfair API, gets runner/winner info, renews session info etc).
The Windows Server does NOT have Visual Studio on it.
Can I just copy my DLL up to the server, put it in Windows/System32 and Regsvr register it and then copy the .EXE for my Form and Service up to the server?
Also without having the VS Toolset to register a Win Service on a machine what commands do I need to run to install the Windows Service on the Server.
These are 2 distinct solutions, one with the DLL code, one with the Service Project and Win Form Project.
I just want to know the best/quickest/easiest/proper way of getting it to work on the new server without having VS on it to register the service.
Can I just copy the code up to a folder (should it go in a specific folder on the server - the log files are piped out into it's own sub folder of /programdata) and run installutil [PATH TO EXE] to install the Service or is there something more I need to do.
As there are two solutions I can't (or don't know how to) create a deployment package with all the right links and references in across solutions.
However should it be more complicated than..
-Copy DLL to System32
-Regsvr my DLL
-Build the service/win form project on my computer then copy the .EXEs up somewhere
-Run installutil [PATH TO EXE] to register the service
-Double click the windows form to open it (should auto start on reboot and sit in desktop tray)
All in .NET 4.5, Was built in vs 2012, 64 bit, C#
Thanks for any help in advance
Creating a deployment package is the better option, but, because it's not a option for you, the regsvr32 and installutil option should do the job.
Hope it helps!
I am trying to run Visual Studio Team Services automated build and deploy but having trouble with copying built windows service to Azure VM.
These are my steps:
Build
Tried with Windows File Copy
Tried with Azure File Copy
When I copy files from web projects (ASP.NET MVC 5) with Azure File Copy, everything works fine and the files are transfered. When I try to copy Windows Service built files, it failes silently. The task passes successfully but when I open the VM through remote desktop, the folder is empty. Any ideas?
Windows Service project is different with Asp.Net MVC project. With the arguments you specified in "MSBuild Arguments" of "Visual Studio Build" step, there is no file generated in "$(build.stagingdirectory)" folder. So "Azure File Copy" task just passed and copied nothing.
To fix this, changing the argument to following and then try the build again:
/p:outputpath="$(build.stagingdirectory)"
I have a process that is going to run as Windows Service.
I have successfully installed it as Windows Service and everything works.
My question is what are the guide lines for process directory.
On the machine Im going to deploy it, does the setup need to copy the .exe to Windows/System32 and then install as service ? Or i can deploy it to C:\MyApp\MyApp.exe and install as service from there.
It is not required for the .exe to be in /Windows/System32/ but is it "Best practice" ?
No. You shouldn't install anything to the Windows System folder. That's for operating system code.
You should install to your own application folder within the Program Files folder, and register as a Windows service thereafter.
I have made a Windows Service that reads an excel sheet and updates the values in database. The service just works fine when I install it from the visual studio command prompt.
I have also made an exe file using the other projects option in Visual Studio. When I install that the exe I made, I cannot see my service in services panel of control panel=>System and Security=>Administrative tools=>Service.
I've run into similar issues with production services I've made.
Carefully follow the solution as described here:
http://msdn.microsoft.com/en-us/library/zt39148a(v=vs.80).aspx
Note that the key is creating the "installer" service class in the service project. This creates the output you will have the MSI "install" and will specify what account will be used to run the service, etc.
I created a web service in C#, using Visual Studio 2010 ( Framework .NET 3.5). In debug mode it works great, but now I must publish it on the internet, so that I can consume it in remote (the app that will consume the web service is an android app).
So the question is: how do I publish my web service on Internet so that I can consume it in remote?
Thanks in advance; this is a work for taking my degree!
A simple way: you switch to release mode, update your web.config for production, right click on your service project and from the menu select publish. Then you publish it to the local folder. This way it copies only the files needed. Then you copy the contents of the folder to your remote site using ftp, for example, your hosting provider should have given you the credentials.
for some hosters it is also possible to publish directly but I don't use this.