I'm developing an auto update feature for my Windows Mobile 6.5 .NET CF 3.5 application.
I haev ended up with following solution.
I use SOAP WebService to check whether a new version of application is available.
If there is a newer version, I get the URL in SOAP response, download it. The new version is simply a CAB full installation file.
As soon as the version is downloaded i call wceload with /silent and /noui parameters on the downloaded CAB. I want unattended installation because users of this application are car drivers who are not so skill-full at operating mobile devices.
The process goes smoothly with one exception - the /noui or /silent options forces wceload to not display any window. My application simply dissapears and in the background the new version is installed. The problem is the drivers sometimes try to turn the application on again too soon. Another point is I'd like my application starts automatically after the update process is completed. So I created a separate exe application that simply calls wceload and if it completes installation it runs the updated version. All works with onr exception - this installer exe is part of my CAB so it is within it and when wceload installs the CAB, it shuts down the installer (because it is a part of the CAB installer). Thus, the installation process is interrupted.
My question is - is there a way to "tell CAB" to not terminate particular exe from those one that are part of this CAB?
Regards
It is not really responding to your question but you can do the following :
launch another (small) executable showing a "Update in progress" screen.
do your stuff behind the scene
[end of setup] => it starts your updated app
[Wait a little bit] => it closes itself and the updated app is ready to use
CAB installation and WCELOAD are limited in many ways. You're after some sort of UI that tells the user that things are in progress and you're wanting to conditionally install certain pieces of a CAB and that simply isn't achievable with wceload out of the box. You might be able to hack some of this together with a custom setup DLL, but I think the "conditional install pieces" is going to still be the show stopper.
One alternative is to not use wceload, but instead create your own CAB extraction tool. You could then do all of your own UI and custom logic based on the file name, etc. I put together an SDK and sample installer several years ago that would allow this - admittely it's not free, but the lowest cost option is only $5 so it's pretty close.
Newer CABs actually contain an XML doc that describes the install actions (in addition to the older .000 binary file descriptor that the SDK I wrote decodes), so it's also possible that you could do all of the extraction just using that and save the $5.
Dont use a cab. Use a tar.gz package with an executable and the cab inside. Use SharpZipLib for decompression. Just run the executable to do the work. Use the \windows\wceload tool to run the cab install.
Related
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 created an application using c# language. this application is doing a task like report generation.i am using that application exe file directly to run the application.i never installed that application in my system. without installation of that application, i can use it in my system.then why people are installing a software/application in systems.please clarify me. so that i can differentiate the MSI installation and direct use of exe file.
Install in cs jargon means guided setup, so what you do is already, basically, installing. Installing may involve much more complicated steps than simple copy/paste of bin directory or unzipping in some folder. installation process may contain the below processes:
Controlling user license
Registry key control
Database creation
Com components registration
....
and much more.
But the core concept remains the same: guided setup of all necessary components of your program to run it properly. So, if the only thing your program needs is a binaries folder, copy/paste is your install.
What you are doing is called an "xcopy" deployment. It was all the rage when .NET came out but it has serious limitations.
Windows Installer (MSI) is a windows platform service / SDK that aimed to create a declarative framework for consistent installer behavior. Simply put instead of learning how to write script to automate install/uninstall (and making a lot of mistakes along the way) you leverage MSI to tell it I have a product named X with feature Y that has these files Z in these directories along with a shortcut and some registry entries and let MSI do the rest for you.
I want to build a Wix installer which will detect a few programs of mine and update them.
I have c# code (using another DLL) to check a few things on the system,
then I want to download a table of the most recent version of all the apps,
decide which app I need to update, and then download & update the selected ones.
So my question is, can Wix preform the following actions:
1) run another dll call using c#?
2) download a file from the web and parse it (let's say - also using c#)?
3) go to a link and download an MSI\EXE?
4) install the MSI\EXE (let's say run it on silent mode)?
5) uninstall old other apps from system?
Windows Installer has a mutex that only allows 1 execute sequence per machine and 1 UI sequence per process. One MSI cannot install another MSI due to this limitation. There are hacks around this but they don't follow good design (don't provide proper elevation support or silent install / uninstall support ).
You should use custom actions with care. A properly designed custom action should behave like the standard actions built into Windows Installer. That is support transactional installation whenever possible and be data driven via custom tables.
A better candidate for the stuff you are describing needing to be done would probably be a bootstrapper / chainer such as WiX's Burn feature.
1) - definitely yes
2)-5) you could do it but you should differ msi from "custom bootstrapper" and "custom after install configuration manager". General rule: use msi package only for resource (usually files; in more complex cases - registry, in most cases sql objects) atomic deployment; move all other functionality outside msi (means use wix ony to build msi; create custom utilities for bootstrapper and configuration tool; see wix samples how to integrate three parts together).
1) Yes but keep in mind that if you have a dependency on .NET 3.5 and you are on a box with .NET 4 your custom action will not be able to run.
Besides this your custom action dll is unpacked from the msi into the %TEMP% folder. If you have any dependency to other dlls not stored in the GAC you will fail to load. If you bring in another e.g. C++ dll you have to embed it as resource in your C# dll and unpack it as well to find it.
2) You can do whatever you have the rights for.
3) Sure
4) Only one MSI installation can run at one time. You have to spawn some child process to wait until the current installation is over.
5) Yes sure. The easiest way is to add an Upgrade table to your msi to simply uninstall any software which has this upgrade code. This is the only allowed action where two msis at the same time can be active. Look at the InstallExecute Sequence table for RemoveExistingProducts action.
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. ;)
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.