I would like to know if there is an easier way to install or uninstall windows services onto dev or test environments without creating setup packages? I am having issues with uninstalling visual studio packages sometimes (even after stopping the service and closing the service management console before uninstall forcing me to reboot the machine). this issue can be overcome by using tools like InstallShield or WIX to create setup packages, but during development it will be easier if I can install the service (along with all the dependent files) in dev or test environment without creating a setup package.
Use installutil, which is part of the .net framework. Now you still need to copy the bin directory to the desired machine and register any COM objects if you are using any.
If remember right,( no access to my dev machine at the moment). Stop the service - and replace the exes and dlls) restart the service. You can script this. You will need to do an initial install, or use the installutil.exe
I found this much easier that installing and uninstalling, all the time.
I find the SC.EXE command to be easy to use during development. Slap it into a NAnt/BuildBuild/Perl/BAT file and instant light weight automation.
I know this is an old question, but I feel this information is highly relevant to anyone struggling with this issue:
The problem comes from a change in the Installer included in Visual Studio. I think the change occurred between VS2005 and VS2008. Regardless, after the change, to have an update installer work properly without uninstalling the prior product, it was recommended that Services be installed via Custom Actions in the Install, Commit, and Rollback phase, but not the Uninstall phase. I believe this is because the change caused the Uninstall action to occur after the new version was installed, uninstalling your service upon update. A Condition of "Not PREVIOUSVERSIONSINSTALLED" is placed on the 3 Custom Actions and Check For Previous Versions must be TRUE. This results in essentially the same result as copying the files over the old ones (but also retains any other install activity such as registering objects, etc.)
This all works great for updates; a new version will install over an existing version, the service remains registered, all is well. However, if you uninstall, your service is left registered, and a fresh install will attempt to register it again, resulting in the 1001 error. I use SC.EXE to delete the service manually when I uninstall to avoid this. You can have a clean uninstall, but it will break update installs, your choice.
Related
I've been debugging for a quite while the Windows Service I've been working with without any noticeable problems. I used to install it thourgh the installutil command and I was able to debug it (followed this MSDN tutorial).
Deploying the service to the production server meant so much pain in order to pack all dependencies, so I was encouraged to deploy it through some kind of installer.
Which one? "Quick and dirty" solution: Visual Studio installer
Everything is running fine until the point I needed to debug the installed server as I have been doing until now. I attach the Windows Service process but the debugger isn't stopping at my breakpoint.
What am I exactly missing?
While I was writing the question, I asked myself how did I configured the build properties. For my surprise, it was set to release.
I changed it to debug, uninstalled the service, installed it again and I finally had my service being debugged.
Bear in mind I always installed the service right-clicking on the project's name and clicking into "install". Seems this takes the installer placed on the specified build config.
Thing is this service is supposed to be installed uniquely on a production server. I was supposed to deploy always the release version in order to be completely clean and optimised, so I guess I will have to keep swapping this option, at least for my own workspace.
And yes, my installutil was pointing to debug build.
I'm using the Visual Studio Installer Projects extension to build the MSI-installer for my application. However, my application is meant to be running at all times, and if it's open when the user is installing a new version of my software, the open files are not overwritten, and very little to nothing is actually updated (although there are no installer-errors).
I've found that using the installer project's "Custom Actions" to run a script that closes the application doesn't help, as none of the actions are called before the files are replaced.
Is there a good way to make sure the open/locked files gets terminated before the files are supposed to be overwritten?
We had this problem, and the solution we came up with was to create two apps; the user app and an updater app. The MSI installs both. Each app checks if the other needs updating and, if it does, closes the other app, downloads the other app's updater, runs it, then relaunches the other app. Additionally, each app monitors if the other app is running and, if it isn't, launches it.
It would be useful to know more about your application and how you are doing the upgrade because:
You will normally see a FilesInUse dialog saying that files are in use, prompting the user to shut them down, but not if the install is silent.
Visual Studio setups have no built-in support for shutting down and restarting services, so if your app is a service you'll need extra work.
Files that actually do need to be replaced will prompt the user for a reboot (if they are not previously shut down) in order to replace them at reboot time.
So if you're not seeing reboot requests or FilesInUse dialogs in a UI install then something else is going on. So you need to be sure that:
a. You are really doing an upgrade where the version of the setup project has been incremented, the UpgradeCode is the same (and the ProductCode changes when you increment the setup project's version). Your symptoms could be the result of the upgrade not working and you're seeing just a repair.
b. The definition of "new version" is that you have an upgrade as in a., AND, the file versions of the binaries have been incremented. The default overwrite rules for installs require incremented file versions, so if they haven't been incremented you'll see no updates, and Windows will not attempt to show FilesInUse dialogs or reboot because there are no files that need replacing.
This isn't a solution to the problem, but rather another solution; the one requiring the least work in the end.
I ended up not using 'Visual Studio Installer Projects' for my installer. Instead I looked to Advanced Installer, which just works with no issues. Things like this is taken into account, and custom actions allow for more options.
If your project is open source, you can write to them about a free open source "professional" license, equal to their "professional" plan, which is normally $399 (onetime purchase).
REBOOT: How are you installing this MSI? What command line? If you set REBOOT=ReallySuppress on the command line, you will not be prompted for a reboot even if one is required to complete the installation of the product.
msiexec.exe /i MySetup.msi /QN REBOOT=ReallySuppress
If you are using a distribution system I suppose suppressing reboot prompts could be standard behavior. Then your product files should be put in place after a reboot (PendingFileRenameOperations or perhaps some newer mechanism).
It is also possible that Visual Studio Installer Projects do something strange that I am not aware of.
Log: I would try to create a good log file for the install, to determine what is going on:
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Log All MSIs: Personally I like to enable logging for all MSI installations - as described in the "Globally for all setups on a machine" section in the above link.
Interpreting an MSI log: interpreting a log file can be challenging sometimes. Here is an answer with some links to help with this.
Reboot Manager: Reboot management is a very complex topic, and Windows features functionality - in the form of the restart manager feature - to try to minimize the need for reboots, by instead shutting down and restarting applications as part of an installation in an "auto-magical" fashion (application listens for messages and shuts itself down gracefully when told to, and the system may restart the application after the install - if configured to do so).
Updating your application to comply with the restart manager is the only real fix for such problems that you see, in my opinon.
The section "Restart Manager" in this question tries to summarize how to implement such support (maybe just read the yellow section a bit down the page).
The Advanced Installer guys have a very nice, technical article about this:
How do I add support for Windows Restart Manager to my application? Also linked to in the link directly above - still worth a direct link here I think.
According to below link
https://social.msdn.microsoft.com/Forums/windows/en-US/0b40b367-3341-43d8-b82e-1ace546969f8/how-can-installation-stop-and-restart-existing-service-?forum=winformssetup
"There is no good support in VS installs to stop and start services. During install, the issue is that custom actions run after everything is installed so it's too late to stop a service that you are upgrading or replacing. Yes, they have names like "BeforeInstall" but they really are not before the install."
I have created a c# 4.0 windows service. I have created an installer project (.msi) for it which installs the service to a particular folder.
To automate the process fully, I would like to install the service as part of the custom actions I have for my installer.
How can I code my custom actions to install or when uninstalling the msi, uninstall the windows service?
You can use the ServiceInstaller class. A quick solution would be to find installutil tool and execute it against your Service.exe, but you have to capture the output to see whether the installation succeeded or not and you don't have much control over Install, Commit, Rollback, and Uninstall phases.
Simple answer: don't. The proper way is to install it using the MSI database itself, i.e. ServiceInstall and ServiceControl tables. Every single "convenient" IDE for MSI creation and also WiX come with primitives to make use of this builtin facility.
The very reason that this is best practice, just like including the COM registration in your MSI instead of calling DllRegisterServer of the COM (DLL) to register is that your application may be defunct at the time the user attempts to remove it.
The database actions can still be executed even by a newer Windows Installer, say after an upgrade of Windows itself, while your code may refuse to run or may not run for other reasons.
I need to create a simple installer of sorts for a different application. That other application already has it's own simplistic installer, and I don't want to meddle with it.
The reason for my own installer is to allow the user to install SQL Express if (s)he so chooses, and also to pre-install any other basic requirements for such a procedure.
At the moment, here's where I'm at:
I've created a single Windows form application, with big buttons (this is for a user which likely won't be very good with computers) to install SQL Server Express (using silent install with a predefined set of arguments) or the actual application, along with some helpful text to let the user know what's going on. Something along the lines of Visual Studio autorun window.
I've also added the standard set of pre-requirements to the application (.NET, Windows Installer).
Everything works OK if I run the app by using the executable. HOWEVER, if I publish it to create a ClickOnce application (so the pre-requisites are installed when needed) and run it, it stops running other installers.
EDIT: Apparently the problem with not being able to run other application from a ClickOnce application is only on my end, and probably deserves a new question, not necessarily here on StackOverflow (perhaps on MSDN forums?).
In your program before launching the installer you can check if .NET is installed. Its pretty easy to check if a particular s/w or a version of s/w is installed. Write a program that will check HKEY/LocalMachine/Microsoft/Windows/CurrentVersion/Uninstall and in that there will be list of programs that have been installed on that machine. If you find then go ahead with your install else suggest user that he needs to install pre req.
When you create a setup project you can right click on the setup project, go to properties, and click on pre requisites. In that you can mention which version of .NET framework is needed and then give the location of the framework. In this link look for Huggy Bears response eggheadcafe.com/community/aspnet/2/10131905/setup-project.aspx
I've settled for a "Click Once" application. It can install all required .NET components needed for it to run, thus becoming an "sure-to-run-non-native-C++-code-splash-screen".
Granted, there ARE issues with Click Once, but this is far better than nothing. It's also better than running C++ or unmanaged code applications. ;)
I am currently adding a deployment project to my C# solution which
installs a windows service and I have been trying to find a property
that will make the installer prompt the user to reboot the system once
installation has completed. I would prefer to simply set a property
rather than create a small application that I run at the end of the
install.
if there is any code to restart then where i'll use this code
in installer class or elsewhere?
If you use a MSI-based installer (which would be the case if you're using a VS setup project), setting REBOOT=Force should do the trick.
Under normal circumstances, though, the installer will itself detect if a reboot is needed: if you're not currently getting a reboot prompt, that's a good indication your service should work just fine without that reboot.
You may be able to extend your setup logic to start the service after installing it (and also to launch any auto-start GUI components if required). That's much friendlier than forcing a reboot, and you'll do your bit to help Windows get rid of its "you moved your mouse, please reboot" image problem...
Edit (December 2011) #IdentityCrisisUK: see HOW TO: Control System Restarts in a Setup Project That You Created by Using Visual Studio .NET for the exact steps involved in setting the REBOOT variable. Use of Orca is required -- not sure why that has "already been ruled out", as it's a trivial postbuild step...
Use the REBOOT Property of WIX to restart prompt in the Product.wxs file of your Setup. Syntax is :-
<Property Id="REBOOT" Value="Force"></Property>