I am a developer who is using python. All my code runs as a pyinstaller - made app.
Can any of you tell me how to update the app when the code is changed without having to reinstall it?
I use EMCO MSI Package Builder to pack my files into MSI package. When I need to update my application I update the MSI with new files, change its product code, version (without changing upgrade code) inside of EMCO software, and build new MSI. After that I update MSI in SCCM (or it's possible to use group policies) and wait when users get it on their PCs.
Related
I'm having a weird problem...
I created a basic WinForms app in C# using Visual Studio 2013, and I added a Setup & Deployment project to the solution to build my .msi installer. For the Setup & Deployment Project's properties, I have the DetectNewerInstalledVersion to true, and the RemovePreviousVersions set to true. Then, with every build, I'll increment the version number and let Visual Studio change the ProductCode. Lastly, I'll make sure that the UpgradeCode stays the same.
In this configuration, if users run the .msi with a previous version installed, then it performs an upgrade. Everything works (as in all files are updated to the new versions, etc.). But, when they open Add/Remove Programs, the icon for the old version(s) is still there, as well as the icon for the new version.
For example, if they used the .msi to install MyApp version 1.1, then used the .msi to upgrade to 1.2, then again to 1.3, then MyApp will correctly update to version 1.3, but the user goes to uninstall it in Control Panel->Programs and Features->Uninstall a program, there will be three MyApp icons (one for each version). And to properly uninstall MyApp, they must right-click/uninstall all three. If I delete the old versions from the registry (the usual fix for stale icons), then MyApp will not uninstall correctly. The uninstall will go through the motions without error, but the program files and icons will remain, and the application will still function like normal. To troubleshoot, I've made a series of builds with sequential version numbers, then opened each build's .vdproj file in a text editor to ensure that the ProductCode and PackageCode have been updated, but the UpgradeCode remains the same. They do, so it's not a problem of the UpgradeCode changing. I've also tried deleting the registry keys for the old icons. This gets them out of the Programs and Features uninstall list, but it prevents the program from being properly uninstalled this way, so this isn't an option.
Anybody have any ideas?
This will happen when the first install is (say) Everyone and the upgrade is installed Just me (or vice versa). One type will not upgrade the other, so files will be replaced if installed to the same location, but there will be an entry for each in Programs&Features. They all must be Everyone or Just me to replace previous products.
You can install the upgrade with msiexec /I [path to msi file] /l*v [path to a log file] to see what's going on. If you search for occurrences of FindRelatedProducts you should see something about what it found and if it was the right context.
Note that Visual Studio setups can change the context if you do not have administrator privileges. You might specify an Everyone install but Visual Studio will change that to Just me if you don't have the privileges.
Ok. Weird...
The issue comes from the way that it's run. Once installed, the program checks the network share for a newer .msi, and if it detects one, it downloads it, then launches it with Process.Start and command-line args. The StartInfo.Arguments string looked like:
startInfo.Arguments = "/i \"[MSIPATH]\" /log \"[LOGPATH]\" TARGETDIR=\"[APPPATH]\" /qr+";
I guess someone fat-fingered the UI mode switch at the end. The "/qr+" switch should be "/qb!-". When I changed it, the problem stopped. I don't think that "/qr+" is even a valid switch, so I'm not sure why the install didn't just fail outright??? Anyway, that was the problem should anyone see something similar.
Special thanks to PhilDW for pointing me to the logs. :-)
I'm trying to make an installer using the Qt Installer framework and when an upgrade is available in the software (checked through our rest API), our software will download the new installer and run it.
This should of course uninstall the previous version first, however, it seems just running it will give you "The folder you selected already exists..." error.
I thought using the maintenance tool that is generated would provide a solution, however, it seems that there is no way to run this with a switch to just do the uninstall. It shows up with the dialogue of uninstall, upgrade... which would confuse the users.
Is there a way to get the maintenance tool or otherwise to uninstall the program, so the update can be run?
EDIT:
If this cannot be done, can anyone suggest a good cross platform installer framework?
Do not try to run the installer again, run the maintenancetool.exe to update. You can make a "silent" update by passing a script to the maintenance tool like this:
#echo off
maintenancetool.exe --checkupdates > checkUpdate.txt
findstr /c:"updates" checkUpdate.txt
if %errorlevel% == 0 maintenancetool.exe --script=script.qs
http://doc.qt.io/qtinstallerframework/noninteractive.html
I would like to run some shell commands during using the QT Install Framework in order to recover information required to configure the installation itself (e.g listing the network adapter).
Currently IFW seems to allow one to prepare canned shell operations (addOperation, addElevatedOperation) that run only after the installer configuration process.
I would like, instead, to run them during the installation set-up. E.g. running an operation in one of the installer page and retrieve the result.
Something like:
Component.prototype.pageChanged = function (page) {
if (page === QInstaller.ReadyForInstallation) {
component.runOperation(...)
}
};
QT Installation Framework installer provides a way to solve this issue.
You can use installer.performOperation running a ConsumeOutput operation.
ConsumeOutput allows one to run an external process and store the process output into an installer key.
I would like to run an external process and wait on its result in my
installer based on Qt Installer Framework. How can I do that?
This can be resolved either with native API (Windows example) or with Qt QProcess::WaitOnFinish (more universal). So, likely you need to somehow work around the installer's API with C++ code.
Many applications have this functionality now, but a good example is the Spotify client.
The app discovers there is a new version available, downloads it in the background then prompts the user to restart to get the new version. When the user quits the new version is installed (or the installed version is patched) then the application is restarted, all without further user interaction. In fact, the user really doesn't even have to do anything the app would automatically update on every exit if the user was never notified.
We have a cross-platform Qt 5.3 application and our lean startup business model requires us to push application updates very often so I'd really like to find a method that works cross platform with as little platform specific code as possible.
There are multiple parts to this question.
Noticing the update, and downloading the installer. (Obvious, and not a problem)
Running the installer application. Not an issue except how does one gain privilege? Spotify never asks for privilage to install again after the first install.
Avoiding "This application has been downloaded from the Internet" approval dialogue on every update.
Restarting the application after upgrading, but only when the user responded to the quit and upgrade prompt.
Specifically are there any tools, installers or code examples that do this?
You can follow how Google Chrome and Opera (latest one, not version <= 12) do it, rougly as below:
When installing the application, create a scheduled task that runs an updater as administrator (or a user with permission to write files to your application directory) periodically. For example in Windows, you can find GoogleUpdateTaskMachineCore and GoogleUpdateTaskMachineUA entries in Task Scheduler.
Your application structure looks something like the following (Google Chrome has similar structure in C:\Program Files (x86)\Google\Chrome\Application):
C:\Program Files\AwesomeApp\launcher.exe
C:\Program Files\AwesomeApp\1.0\AwesomeApp.exe ; version 1.0 of application
C:\Program Files\AwesomeApp\1.2\AwesomeApp.exe ; version 1.2 of application
The application shortcut created by installer will run launcher.exe. This launcher.exe will run the latest version of AwesomeApp.exe available in the directory. For example in the above structure, launcher.exe will run AwesomeApp\1.2\AwesomeApp.exe.
When the updater finds an update, it will download it and add the new version to the directory in the background. After that it will tell the running application (if it is running) to notify the user that an update is ready and can be used by restarting the application. And of course your older application needs to close itself and restart by running launcher.exe too. This updater may delete old application versions and keep only the latest two versions.
I previously installed a website on the server by running an msi package and everything worked fine. Now, when I try to run the same msi file (to Repair/Uninstall), I get a message:
When I click Cancel, I get the following message:
Anybody has an idea what happened and how it can be fixed?
I would recommend that you run the MSI with logging enabled. This can be done by using the /l*v C:\mylog.txt switch or by modifying the registry. The log will provide you with more precise information as to what is going wrong during the msi process.
The articles below describe how to enable logging and the logging process in more detail
http://support.microsoft.com/kb/223300
http://technet.microsoft.com/en-us/library/cc759262(v=WS.10).aspx
http://msdn.microsoft.com/en-us/library/aa372847(v=vs.85).aspx
Once you have the log you can use a set of MSI tools like the Orca installer database editor tool on the Windows SDK to correct any issues.
This is the link for Windows 7 SDK which contains the msi tools.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Sorry for answering my own question, but I found the problem and I want to share the solution:
After I installed the old version on the server, I changed the name of the msi file. Consequently, I could not run the old version to repair/update. I could not even install a newer version over the old version, as the installer needed the old msi to uninstall the old version.
When I changed back the filename of the old version, it allowed me to install the new version.
CONCLUSION: Don't change the name of the msi file after installation.