We have a software that has couple of executables inside. One of the executables is Windows service, and it doesn't change that often, usually we release many updates to the main executable, but the service version is same inside installer.
When service is installed first time or upgraded with newer version, we need to run custom action. We managed to solve first install part, but we don't know how to determine that version we're installing now is newer than one that already exists. Sort of if(newver > oldver) run custom action.
Thank you in advance
- Jack
You can try using the upgrade rules of your package. More details here: How to implement WiX installer upgrade?
Rob Mensching (the second answer in the linked thread) shows an example for upgrade rules. You should first familiarize yourself with the Upgrade table and how upgrade rules work. There isn't an easy answer or a quick fix for this in WiX.
Basically, you should have 2 upgrade rules
the first sets a property when an older version is found
the second sets another property when a newer version is found
After that you can use the older versions property to condition your custom action. For example, if the property is named OLDERVERSIONFOUND the custom action condition can be:
OLDERVERSIONFOUND
or something like
OLDERVERSIONFOUND > "1.0.0"
Your best bet is to store the "service" version somewhere in the registry, search for that registry value during upgrade and run your CA if newver > oldver (and the CA should also update said registry value to newver)
Note that Custom Actions are (generally) an admission of failure. I always try to separate out the configuration portion of setup to a pre-install (for sysadmins doing deployment) or post-install (for interactive installations) step - often a separate executable.
Declarative installations with no custom actions are much more reliable - if you can figure out how to rewrite the service so that your custom action is no longer required, you'll be much better off in the long term (this doesn't help when you're under pressure to release now, but it's something to think of for future releases)
Related
I have an question regarding updates to the framework of a Laravel application.
Normally I run the composer update command to update all of its dependencies. For the laravel framework the package laravel/framework is used.
But they made some changes in this package which require you to make changes in the core application (not in composer). The core application is the package laravel/laravel.
For example, in this commit they have made a function called confirmPassword() which refers to a file ConfirmPasswordController.php in the package laravel/laravel.
But this file didn't exists on my application because my application is not up-to-date.
My question
How do i keep my core application up to date?
Errors
See a typical example of updating the dependencies but not the application here.
First of all... This is not an easy question and IMO there are MANY possible scenarios... Depending on the code you developed, the packages you're using, the version you want to use, and so on...
Anyway This is what I would do in this situation:
Let's say for example I want to upgrade from version X to version Z where Z is two major / minor releases ahead of X
Step 1
Follow the next steps for one major / minor realease at time. Once I've tried to upgrade an application from Laravel 5.4 to 5.6 and it was completely broken. So I decided to upgrade to 5.5 and test the everything was working and, in case, block at that release. Luckily when I've upgraded from 5.5 to 5.6 (after code fix) I've managed to make everything work as it should.
Step 2
Upgrade the core framework and the plugins, check for errors during the upgrade and ofc, check the official documentation for any kind of compatibility problem
Step 3
Laravel has it's own upgrade guide that should be followed step by step. A good chunk of errors can be solved simply following that guide. There may be some plugins that doesn't provide it but usually the problems are releated to new features... It's hard that a method, class or trait has completely changed from one version to another.
Step 4
This step can be omitted, but from the example you've provided maybe it's better to add it. When there is a new feature that requires a specific class or trait or whatsoever, the simplest way to check if the error is thrown because of a file missing (and that is part of the "boilerplate") or has a different nature, is to create an empty project with that specific version and make a comparison with the "default" files.
For example, if you made no changes to the LoginController, checking if the new version has any kind of updates, may be the solution.
You can do this manually, following the upgrade guide for the version you're upgrading from/to, for example this one.
Alternatively, Laravel Shift is a paid but fairly inexpensive tool that will do it for you automatically. Since it's making changes to your project, you should carefully review everything it's done.
I know that the 5.0 release note say "After the migration, source syntax-highlighting won't be available on a project until it has been successfully analyzed"
BUT, i can't imagine that there is no way to activate just by running another analysis. In fact, when you have thousands of components (it's our case), you can't plan 4500 analysis just to "restore" a basic but helpful functionality ! And it's more true when you know that the majority of theses components wasn't changed since a time ago... :(
So, please, say me that we can write a little batch or program that will do the job without need to pull all the sources ! I don't know how because i don't' understand this limitation of this upgrade (why sources aren't accessible)
You should trust the release notes. Information required for syntax highlighting is computed during analysis. Note that it also requires the language plugins to support this feature. I suggest to upgrade them to latest versions.
Lets say my current production version is 1.2.3 and the new product version is 1.2.3.4.
Now, during installation, it will throw a warning message saying something like "The setup has detected the version 1.02.003 of...... already installed. This setup updates ..... to the same version that is already installed, therefore this update is not needed. Do you want to install the update anyway? "
This will be very misleading. Does anybody know a solution for this?
It is not InstallShield, but rather Windows Installer, the underlying technology has the behavior you observe. Take a look at this article, which explains how Windows Installer treats versioning.
The important part for your case is this:
Note that Windows Installer uses only the first three fields of the
product version. If you include a fourth field in your product
version, the installer ignores the fourth field.
This explains why it considers the new one to be the same version. So, the suggestion is either change the third digit, or go with small updates instead. Here is how you can apply small updates by re-installing the product.
For moderators: this question is about development of RPM based installer.
I'm developing packaging system for our software. We've designed our update management so that when we want to move to the new major version, we change RPM package to install all files into another directory (with another suffix) and change the package version. We keep the same name for the package (like: a-package-1.0.0 --> a-package-2.0.0). We want to install the new package keeping the old one to make user able to continue work with the old version while he moving to the new one.
So there is no file conflicts between our packages and RPM utility install them simultaneously without any issues (rpm -ivh ...). But Yum thinks that the new version is an update for the old one.
Is there a way to produce such RPM packages to make 'yum install a-package-1.0.0 a-package-2.0.0' installing them both? Maybe some flag in the package have to be set? I've found nothing.
Seems there is no way to install two RPM packages with the same name and without file conflicts usnig Yum.
So in my case I need to use some version suffix included into the package name.
I called RH and their preliminary answer is that there is no way to do this in YUM/RPM as this might cause confusion. After some discussion among their engineers, there does appear to be a way to do this, but they said it is cumbersome. I've asked them to send me their documentation (if any). I'm afraid you will need to call their customer service line and make the same request.
Here is the response from RH.
Thank you so much for your time on the phone today. You called asking if there was a way of installing different versions of tools like maven or java using yum to install them. After the engineers discussed it they have provided a document that shows you how to do this. I must say, if you do not have a log in to the customer portal, you will not be able to view the whole document.
How to switch Java Environment in Red Hat Enterprise Linux 5 and 6?
- https://access.redhat.com/solutions/21059
The engineers have also provided additional documents just for general use with Developer Toolset and Software Collections:
How to use Red Hat Software Collections (RHSCL) or Red Hat Developer Toolset (DTS)?
- https://access.redhat.com/solutions/472793
Developer Toolset and Red Hat Software Collections use in Red Hat Enterprise Linux 7
- https://access.redhat.com/solutions/915023
What's the difference between /etc/alternatives and the dynamic software collections framework?
- https://access.redhat.com/solutions/528643
If you do require further assistance, please provide me with a valid account number, login, or contract number, and I can get a case started and you will be able to be in direct contact with one of our Red Hat engineers.
My company is creating a cheaper version of our product that will only upgrade from an older version. To accomplish this, I would like to create an installation that will ONLY upgrade from a previous version. It will not install the full product.
Is there a straightforward way to do this? I have considered:
1) Creating a custom action that checks the registry for the old version first;
2) Creating a patch/hotfix installation
Is there a better method to do this? If not, are there any large pitfalls and drawbacks to these methods? Method #2 seems like the easier method, but this is a pretty big upgrade (though not a "major upgrade," from a technical standpoint). I don't like the appearance of a hotfix when the upgrade is no such thing.
By the way, I am writing the installer in WiX.
This really boils down to one question: does the upgrade move or remove files?
If it does, you need a major upgrade. In this case just make sure that your new version uses the same Upgrade Code as the old one. Windows Installer will take care of the old version removal.
To prevent the package from performing a standalone installation you can use an upgrade rule. You can define a rule which detects older versions and saves them in an installer property. This property can then be used as a launch condition.
If the upgrade doesn't need to remove files, you can use a patch. In this case you don't need to worry about standalone installations.