I know how does Cask works and all the benefits I can get when using it in a brand new system, but what I want to know and I don't seem to find and answer anywhere is... would it be a good idea if I delete my previous installed software and replace them with cask versions? would I see some kind of improvement, or would it be a waste of time?
There's no real advantage to reinstalling existing binaries using homebrew-cask. It's strictly a workflow improvement for when you need to install various softwares. For instance, if you wanted to have a script to install all your regularly used binaries on a new computer, that would be more efficient than manually visiting several sites and downloading, installing, etc.
Traditional software installation on some apps have automatic updates and some require the user to visit the apps website to do an update. Once the update is downloaded the user is required to click next, next, agree etc whilst it is satisfactory to do this for a few apps it can be time consuming.
One of the advantages of HBC is that it does an install without user interaction or sometimes a prompt for admin password. So if you do a reinstall of the OS you can use HBC to reinstall the additional apps.
At present there is no provision for updates using HBC so i have written scripts that take of some issues.
The scripts will create a file that lists the files to be updated including apps that are defined as latest. You can then modify the file to suit your requirements and install updates using my olinst script.
For more information visit my github.
https://github.com/pacav69/homebrew-homebrew-caskroom-offline-installer
Related
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
Thank you in advance for considering this question. If a similar question existed, I was unable to find it.
The Issue: Our company packages an application into an MSI. This MSI when installed outside of any GPO properly updates, blocks attempts to downgrade (or move from a higher revision to a lower revision), and never has trouble uninstalling previous versions of the application regardless of how long ago those versions were created/installed. For example, we can install version 1.2.3 and then install version 2.3.4 and the application will properly install without issue. However, we work with a customer who uses GPO to deploy our application to hundreds of PC's. Each time we have provided an updated version of the application the following has been indicated:
On any machine where a previous version of our application was installed via GPO, no matter what the previous version is, the update successfully installs without issue.
On a machine where the application was manually installed (outside of the GPO), and an attempt to update the application via GPO is made - either the application is installed in addition to the old version, OR there remain registry keys to the previous version of the application and the application cannot open/run correctly. In this case the registry keys must be manually removed, and the install is then attempted again from a clean machine.
What we know is that on any machine where the application was originally installed via GPO - updating the application is no problem. On every machine where the application was not installed with the GPO in the first place, updating via GPO fails with one of the problems presented above.
My question is: Is there a technical issue with how the installation is being handled partially through the GPO and partially outside? Does the GPO need to be responsible for the entire life-cycle of the application? OR is it a reasonable expectation that the application be updated both on machines where the original version was manually (outside the GPO ) installed, and when it was installed initially from within the GPO?
One solution we are aware of is simply having all computers manage the application life-cycle (since we know updates work in that environment already), however this would mean that many computers would need to have the manually installed versions removed by hand - and then properly handle the installation through GPO which is an extensive bit of work.
We would greatly welcome any solutions, references to technical documentation that formally shed light on the proper management or expectations here, or links to information. Our research suggests that it is "best" to manage the entire applications life-cycle inside the GPO - but I have as of yet been unable to determine that it is 100% necessary to do so.
Looking forward to any assistance. If any further technical details are required to help the viability of the question, please don't hesitate to request such details.
If you end up with two versions installed in Control Panel, then all other things being correct, the most likely explanation is that you upgraded a per user install with a per machine install (or vice versa). In the GPO world that's related to assigning it to a user or to the computer, something like that. That's easy to verify by getting a verbose log and checking the FindRelatedProducts actions for an indication that another product was found but in a different context.
When you're in GPO mode all the time, I assume each one (whether it's per user or per machine) is consistent, therefore upgrades always work, but they don't work cross-context.
I believe GPO suppresses the UI in most cases, and the UI (or the UI sequence) is sometimes where per user/per machine is set. That might be something else that would cause it, depending on how the GPO publishes to the computer or the user.
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
i am having a msi setup file which installs a windows service on the system. Now everytime i install a newer version of the setup, i want that it should first completely uninstall the previously installed version and then install the current version. I am pretty new to these configuration so not having any idea on this.
Any help would be much appreciated.
Thanks in Advance!
You will have to ensure that when you run uninstall on the first version of your application that it really does leave your system in the original state you expect. Unfortunately, depending upon your setup and application, a clean uninstall is not automatically guaranteed simply because you ran uninstall on the same Windows Installer package used to install the application. You will need to test the original installation package thoroughly to ensure that Uninstallation Leaves the User's Computer in a Clean State. For example, if your application must be registered, the installation package must be authored to clean up the registry when the application is uninstalled.
If your installation package actually does always leave the user's computer in a clean state, then you can remove an application that has been installed using a Windows Installer Package by using the Standard Command Line Option with the /uninstall option, or one of the Windows Installer APIs such as MsiInstallProduct.
If you want to install a newer version of your application over an older version that is already installed, it may be better to develop an update package to update the application. There are several types of updates: Small Updates, Minor Upgrades, and Major Upgrades. See Patching and Upgrades in the documentation to determine what type of updating package you will need to provide to the users of your application.
One of the purposes of the Windows Installer is to support application servicing like this where there may be shared components and multiple updates on the user's system. This can be a more resilient servicing approach because it can require less prior knowledge of the user's computer than an approach of rip-out and replace.
I know on windows there are a bunch of installer tools you can use to create an installer, but on Mac OS I've seen two ways to install apps:
A DMG file which you download, double-click, then run an application inside - the application typically has you drag an icon to another icon (representing the Applications folder) to install the app
Another type of file which launches an apparently standard installer, which sometimes brings up a warning like "This installer may run a program to determine if you can go ahead with the install"
What's the "standard" way of packaging an app for install on Mac OS? Is one of the above the Apple-recommended way?
Thanks.
Apple is very clearly making the "standard" to be downloading a program from the App Store. This has the benefit of making application installation transparent to the normal user. And, believe it or not, normal people have a lot of trouble with the concept of installing a program. Of course that benefit comes with some costs, but this isn't the place for that debate–there are plenty of other places for that.
Assuming you don't want to or can't go the App Store route, both PKG and DMG are common ways to distribute a program. Use a PKG if you need to install files aside from your application bundle (which should not be a common use case). In all other cases use a DMG that prompts the user to copy the application into the Applications folder. But a lot of your users will not understand that they need to do that (unless your target audience is solely knowledgeable computer users). They will run your application from the disk image. Ideally in this case, your program will detect that it is running from a disk image and offer to copy itself into the Applications folder.
Packages works well. If your deployment process must be kept simple, it is great.
The Quick build consists of dragging your .app onto Package and it is done.
For advanced packaging, you can also provide a certificate.
http://s.sudre.free.fr/Software/Packages/about.html
We're discussing two things:
first and most importantly, the standard method by which the bits of an executable get laid on the disk in a way that's accessible and properly registered by the system
second, the mechanism for preparing the .app, as recommended by Apple
An older marketing page on Apple's site says it's recommended to create packages (so the Installer application can move the bits in place) with the PackageMaker application.
Its usage is described here: mactech.com/articles/mactech/Vol.25/25.03/2503MacEnterprise-PackagingforSystemAdministrators/index.html.
But as others have mentioned, the elephant in the room is the MacAppStore(MAS for short). Until it's debut, what was standard for large companies was their own custom scripts rolled into an older-style 'bundle' package or using an executable like the VISE installer. Smaller developers usually tried to make their app installable via drag-drop, distributed in zip archives or disk images(for simplicity's sake).
The MAS is different: as of 10.7 it uses a package format (which debuted in 10.5) referred to as a flat package (really a xar archive, explanation here)
which is transferred over http to a hidden folder, installs directly to Applications(after which the temporary folder it is downloaded to is deleted). It drops its receipt and a bill or materials file into /private/var/db, and is therefore audit-able by the built-in command line pkgutil tool, described here: mactech.com/articles/mactech/Vol.25/25.12/2512MacEnterprise-PackagesReceiptsandSnow/index.html
A benefit of using the flat package format is you can pull things over the network more safely and efficiently, but it isn't as easy to work with as bundle packages if you are testing and modifying the package regularly, or iterating to ensure scripts that perform actions or checks work well. Even when flat, putting the pkg in a archive or disk image is recommended for flexibility. More distribution tools expect DMG's than zip's, so there's that as well.
Besides what Apple recommends and what is standard, common practice, there's this article: https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/ which discusses the why's and hows (although mainly for system administrators) of packaging for wider distribution. It is greatly recommended to get more of a feel of how and why things go wrong, and what to avoid.
Try Iceberg!
Another one package creator.
In OS X, many applications are just created as a Relocatable
application bundles that the user just need to copy to the
/Application folder (or any other location). In other cases, when you
need to perform some operations over the machine (such as adding users
or changing permissions) you can use a PKG installer (for example built using PackageMaker), which allows
executing some pre and post install scripts and support some basic
installation configuration, like selecting the installation drive.
Sometimes, as with complex server software, you need more flexibility, for example to show custom pages to
the end user requesting information required to install your
application, like the MySQL port and password or proxy information to
download requirements on the fly (or simply to make it look fancier
:)). For this cases there are other installer solutions like our BitRock
InstallBuilder (disclaimer, I'm one of the developers).
InstallBuilder also has the advantage of generating multiplatform
installers using the same project with very little customization per
platform.