Presently when i uninstall a .net clickonce app, it doesn't check whether the App is in the running state. Also it doesn't delete files on PC restart also.
So I am planning to overwrite the uninstall method to handle this situation.
Which is the class and method gets called on uninstall? Inplacehostingmanager class has only install related functions.
You cannot implement the functionality for uninstall actions in your main application.
You need to overwrite the registry entries, written by the setup, to run a custom executable. This will then check if your application is still running and remove the files that you might have stored in a custom application folder. Then you call the real ClickOnce uninstall routine and you're done.
A very good tutorial can be found on www.codeproject.com.
Related
Asking similar question because no one answered previous question asked
I have a solution with a class library project, a WPF project (start up project) and a Windows Service project. I would like to create one installer so that when the user installs the application then both WPF (UI) and Windows service gets installed.
Most of the resources I found online only talk about one or another but not both. For example this:.
I checked some question on stackoverflow but either they are not answered by any one or vague answers like this question or this one.
Any suggestion how to achieve this?
I'm not an expert on various installer solutions, but yes, this can be done. I know because my project does it.
We've historically used InstallShield, but we are actively moving to InstallAware for reasons unrelated to this discussion. Frankly, I suspect any installer solution (e.g., InstallShield, InstallAware, Wix, etc.) could be used to do this providing that it has the means to execute a batch script as part of the install process (more on this in a moment). In fact, while we are building our new installer using InstallAware, we are temporarily delivering our WPF-based application and Windows Service using a WinZip self-extracting executable. The WinZip self-extractor puts the WPF application in the C:\Program Files\<application>\<version> folder, puts the Windows Service in the C:\Program Files\<application>\Common folder, and then installs and starts the Windows Service.
The trick to all of this, of course, is getting the Windows Service installed. Initially, we used the InstallUtil.exe utility to do this, but we had to err on the side of caution and deliver it with our installer because we couldn't verify whether or not we could depend on the utility being available on the target system. At some point along the way, I read this answer by #Marc Gravell. This provided the springboard to my answer here, which provides detailed instructions for having your Windows Service install itself from the command line without the need for InstallUtil.exe.
So as a set of instructions...
Update your Windows Service based on the details here.
Create a .bat file with the following commands:
cd <PathToWindowsServiceInstallationFolder>
<YourWindowsService>.exe -install
Build the installer for your WPF Service and Windows Service. Note that this should focus on deploying the files to their correct locations. You'll need to include the .bat file as part of the installer. If your installer solution allows you to copy files to a temporary folder that gets deleted at the end of the installation process, copy the .bat file to that location since you won't need it after the installer is finished.
Finally, execute the .bat file from your installer during installation. This will install the Windows Service.
It's really not that complicated all things considered.
The one thing to be aware of is that your users should plan on running the installer as an administrator. Since installing the Windows Service updates the registry, users without administrative privileges might run into problems when trying to install your product.
HTH
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 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.
VS 2008 SP1
I have created a application that I have installed on the user computer. However, I want the application to be self-updating. But I am not sure if this would really update the application.
The application will download all the files from the web server, and replace the files in the directory where the program as been installed to. The user will restart the application.
I am just want to be sure, because I can't replace the installed files with the updated ones. As the application will be running. So really the application cannot delete/replace itself.
So, I was thinking that I could download into another directory, if the program is installed in this directory 'program files/application/1.0.0' then I could download the files to 'program files/application/1.0.1'.
However, when the program restarts, how can it know that it has to execute from the 1.0.1 directory?
I can't use clickonce or the updater block for this.
Many thanks for any advice,
A good option is to make an independant Updater application.
The updater will download the newest version and kill/replace the old.
I think this is the best option, because you can execute the updater within the main appication (so you can say that it´s self-updating), or directly by the user with a shortcut.
The updater can check if the application is running and ask the user to exit the application or kill it by itself.
Forgive my english...
Good luck
All of that is already done for you if you use ClickOnce deployment (Project properties, Publish).
You can wrap the application with a small loader program which will do a version check. If it's out of date, download the newer binaries and overwrite the old ones. If you want to maintain all version you might end up with:
c:\program files\mycompany\myapp\loader (the newer version will point to the latest directory)
c:\program files\mycompany\myapp\v1.0
c:\program files\mycompany\myapp\v1.1
If it's on a LAN, you might be able afford the bandwidth of just re-downloading the binaries on start up instead.
Use Windows Installer for the installation and updating. If you sign your installation packages the user can update your application without needing any administrator privileges.
I've made a website and an application that demonstrates the functionality of what you want on my website.
Wix Clickthrough might meet your needs: http://wix.sourceforge.net/clickthrough.html
I would look into ClickOnce. It can be configured multiple ways, to check for updates before the application runs, to download from the server each time it's run, or check for updates after the application has started.
I have done ClickOnce Deployment and an independent updating application, they both work well. You obviously will have more flexibility over an updating application that you create yourself, however tho, ClickOnce can also be configured to install prerequisites such as the .NET Framework, Windows Installer, etc... for your application to run.