I'm trying to create patches using the method from this tutorial. An issue I'm running into is that I can't install a new patch on top of a previous patch.
I can full install Version A,then patch to Version B. After that I can't patch to Version C.
I can full install Version B, then patch to Version C.
Currently we just do full installs with major updates each time which is working fine, but because of the frequency of our (internal) updates the file size and update time is becoming a burden so we're looking to reduce the update time (both downloading and installing) especially when most of the files don't change.
Edit: Another requirement is that at any given time a full install can be done instead of a patch. The solution I came up with setting a static product code made full installs on top (without manually uninstalling) doesn't work.
If you're not doing a major upgrade, but you are changing versions, you're doing a minor upgrade. To be able to install the next version .msi file over an existing installed previous version, you're going to have to set REINSTALL to a list of modified features somewhere (or to ALL if you're lazy and willing to put up with Windows Installer doing extra work). Often setting REINSTALL handled by the bootstrap, but it is possible to set it in the .msi and reset it to empty ({})when the previous versions are not installed (condition Not Installed).
Looks like the issue was that I was previously making all upgrades major upgrades, but that's not supported with patching. Changing to a static product code rather than auto-generate fixed it.
Edit:
Looks like it solved the first problem of Install A Patch B Patch C not working, but now trying to do a full install of D on top doesn't work.
Related
In the given scenario, new Dev A has a new version of npm (8.3). He does a clone of the repo and npm says the package.lock file needs to be upgraded from lockFile version format 1 to version 2. Then he checks that in. So now the repo has a lock file with format version 2 and other devs pull that down.
Time goes by with no problems. Then Dev B, who's on version 6.13, installs a package. Is it normal that the lock file will change back to version one FROM version 2? In other words, each time a dev with a different version of npm that employs a different format, upgrades or installs a package, is it normal that it changes the lockfileVersion format over and over depending on their npm version and its format? Or should it stay with lockFileVersion 2?
Trying to identify what happened recently with our packages, and I'm looking to exclude this as a possible issue.
From what I read fileLockVersion 2 is supposed to be backwards compatible. But is it supposed to change back and forth like that? I wouldn't think so because how can someone with version 2 (Dev A) use version 1 if it was required to upgrade to version 2 in the first place?
So am I correct that once it's on version 2 it should stay that way? And if so, what would cause it to go back to version 1.
Thanks
No, it's not normal for developers to keep flipping versions like that, but it's fairly common for it to occur. We also had this happen specifically with package-lock.json so we told everyone to upgrade, and we made sure to upgrade all of our build agents. Similarly, in Visual Studio solutions some developers occasionally changed the version of VS back and forth from 2017 to 2019 a few times before we told everyone to just upgrade to 2019.
Generally it's best to avoid it if possible.
what is the best practice to upgrade the dependency v-calendar from beta to the latest version v2.3.0?
I know the question is opinion based, but I am new to the field, what are the pros and cons of the way to do the upgrade.
We use "v-calendar": "~1.0.0-beta.14" in production. The latest version is currently v.2.3.0
I can think of two ways:
update to the latest version with yarn add v-calendar#latest?
upgrade incrementally until the latest version is reached with yarn upgrade "v-calendar"?
What should I do to reach the latest version? thank you
ps. we are using vue: ~2.6.10
Unless the package you are using has an upgrade guide (99.99% of them don't), there is absolutely no point in doing an incremental upgrade. If it has an upgrade guide, read and follow its instructions.
The easiest way to upgrade is to change the package version to latest (in most IDE's if you press Ctrl/Cmd and hover the package number shown in package.json a tooltip will show you currently installed version, latest wanted version and latest available version). After you changed it (by typing the latest version in), run yarn install.
In the vast majority of cases, that's all you need to do, because most packages are built with backwards compatibility (existing features remain and new features are being added). If that's not true in your case, you'll have to reimplement it following their documentation. Typically it's no big deal.
Also, note there is no risk in attempting to change to a newer version. If things break, you just go back to package.json, change version back to lower, run yarn install again and everything is back to square one.
I had an MSI with a CA type 1. Later on, I realized that CA had to be changed so I updated it and created an MSP.
Q1: If I install the MSI and then apply the MSP, I don't think the cached MSI (one in Windows\Install directory) contain the updated CA, right?
Q2: If I uninstall this MSI, does the installer uninstall the MSP first and then the MSI?
Q3: Which CA would be performed during uninstallation? An updated CA or the original CA? Or an updated CA first and then the original CA?
Thanks in advance.
In (typically) the \windows\installer directory there is the cached MSI and any patches that have been installed for that product. When some installation action is performed the cached MSI and all its related patches are "merged" to create the view of the actual currently installed patched product, so:
So Q1 doesn't really apply because nothing is done with the cached MSI on its own. If you look at it with Orca it won't reflect the patch, because that's in a separate MSP file.
Q2: There is no first and last because the (MSI+Patches) is what is uninstalled, followed by clean up removing the files that are no longer needed.
Q3: There is only one CA in (MSI+Patches) and that's what is called.
PhilDW has attended to your specific questions, maybe I can make a few guesses as to what the underlying problem really is.
Is this a minor or major upgrade MSP? A minor upgrade patch can be used to "hotfix" errors in the installed MSI's uninstall sequence - if that is what you are really asking. I have done so many times, and when you install the patch first and then uninstall, what is running on uninstall is what you included in your MSP - the new CA - provided you installed everything correctly (command line, etc...). The MSP is merged to the cached MSI - as Phil states - at runtime. What I am a little fuzzy on, is how any applied transforms are handled - this is something I have never had the time to test. Are you using transforms?
This approach is frequently used when you discover an error in the installed setup's uninstall sequence which prevents a major upgrade from running correctly. In a regular major upgrade the old custom action may or may not run from the old setup depending on how it is conditioned (see link for some conditioning cheat sheets), but typically it either runs undesirably, returns an unexpected error that triggers an undesirable rollback or the whole custom action crashes, causing a failed major upgrade (or failed uninstall).
The above yields a catch 22 situation where your existing install appears un-uninstallable and un-upgradeable - but a minor upgrade can come to the rescue (a regular MSI installed as a minor upgrade should also work - it shouldn't need to be delivered as a patch, provided that you properly re-cache the new MSI from the command line - a patch is merely a distribution mechanism for an upgrade that is already working).
A major upgrade patch (MSP), on the other hand, will not allow you to fix errors in the uninstall sequence of the existing installation since it triggers the uninstall sequence of the pre-existing install and just tells it: "uninstall yourself" - as part of the major upgrade operation. When this happens, then the old CA is used - which is embedded in the cached MSI for the old setup. It is the old setup running - unchanged.
It has been over a decade since I made a major upgrade patch - I find them pretty bad and I avoid them if possible. There are too many problems - and honestly: a few serious logical flaws (for example the fact that the product you are trying to patch may already have been uninstalled - if you schedule RemoveExistingProducts early - see below - a rather ridiculous error, one would have to say). I have never made a major upgrade patch using WiX, but I tried with Installshield and briefly with Wise. In order for them to run at all, you have to set the uninstall of the old version to happen after the install of the new version (so the old version isn't already gone by the time you try to patch). This means RemoveExistingProducts must be late in the InstallExecuteSequence - which makes the setups vulnerable to component referencing errors (another common problem).
UPDATE: I should also add that my major upgrade test - done many, many years ago - also had problems with feature state migration (MigrateFeatureStates) - the patch caused all features to show up in an unknown state. To this date I have never had the time to figure out exactly what happened, but I think it may have been my own doing. I did something funky with the Preselected property (I think it may have been related to a merge module doing something stupid - and I tried to "fix" it - with another fix that didn't fix anything, but caused new problems - and such forth and whatnot :-) - deployment is fun). Just reporting the failure, and whatever intel I have - not claiming to have any solutions. There were also other problems - but most of them were Installshield specific I think. WiX might do a lot better. Wise was sensationally good for minor upgrades (they really did work), but I never used Wise for a real major upgrade.
A typical major upgrade custom action problem is that the custom action is erroneously conditioned and will run in both the old version's uninstall, and the new version's install. There are many modes to test your conditions in, and you will be surprised if you take the time to do so: install, repair, modify, uninstall, patch, etc... And you will often find that the custom action runs unexpectedly on modify or repair operations or similar. I linked to a couple of cheat sheets for conditions above, here it is again: Is it possible to run a custom action only in repair mode.
UPDATE: And a common patch problem is that custom actions may run unexpectedly because they are not conditioned with NOT PATCH. Rant: I wish patching would be its own thing in MSI and not just a delivery mechanism for a regular update, and that it would target files only and have its own installation sequence (like admin install has). This would allow "targeted patching" and small hotfixes for huge products - which really need some working, down-to-earth patching that is not overambitious and over-complicated (which is what patching in MSI currently is - in all honesty).
Advice? Use a minor upgrade patch or a regular minor upgrade (not delivered as a patch) to fix the uninstall problem, and then proceed to use your normal upgrade approach. It should be possible to deliver all this in a WiX Burn bundle - but I have never had time to test it.
My 2 cents? Forget patching if your product is small, and just use a regular minor upgrade MSI. If your product is huge, then use a patch package (or your download bundle will be a lot larger than necessary). Be aware that your future setup bundles should also contain the "hotfix" patch / MSI to allow users with older installations to fix the uninstall error before installing the latest version. A little clunky, but it should be manageable. If your old setup has a working uninstall, but fails as a major upgrade (because of an insignificant error in the uninstall sequence making the whole process fall over), you can uninstall the old setup with a regular uninstall command passed to msiexec.exe and then install the new version afterwards (avoiding the major upgrade scenario by performing a manual uninstall first). I haven't tested this with Burn yet.
I have an installer for Wix which installs the program to be version I have successfully made patches to achieve the following upgrading:
1.0.0 -> 1.0.1
1.0.0 -> 1.0.2
1.0.1 -> 1.0.2
This works I've had to make new .msp files from 1.0.0 to the target build number each time. So from my understanding how the patching works behind the scenes, is that if I had initially a patch from 1.0.0 to 1.0.1 then I created a new on to go from 1.0.0 to 1.0.2, if I were to run the new patch, the old patch would be uninstalled and the new one would replace it.
If my understanding is correct then this means that patch files would continue to increase in size the more you change code, so I would like a solution to counter this, where at some point I would increment the minor version, and start the patching process over.
For example I would like to do this:
1.0.0 -> 1.0.12 could be handle with patch1.msp. Then I create a patch2.msp which would start creating patches based off of version 1.0.12. An example upgrade path might then look like:
1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x
Is there any way to accomplish this? Or would I need to reinstall with a .msi file and continue to patch from there?
First, installing a superseding MSP does not remove superseded MSPs. The superseded MSP is simply marked as superseded (inactive). Should you later remove the superseding MSP, the previously superseded MSP is reactivated.
In order to remove MSPs, you need to use the older obsolescence method, but I really don't recommend that. Not only is it difficult to manage, it also means that, for example, if you fixed a security bug in a previous patch that was removed, when the newer obsolescing patch is removed the security hole is unpatched. That's the beautify of supersedence, which has been around since MSI 3.0.
To your question, though, I don't recommend it. It's best that MSPs target the baseline. Yes, they could potentially get a little bigger, but only if you're adding content. If newer versions are just updating sets of files or other resources, an MSP targeting a single MSI should never grow larger than the base MSI (well, MSI + external CABs, since CABs are embedded in the MSPs and always should be). See https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/ for more about small update MSPs, and https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/ for how to support targeting a single baseline with minor update MSPs.
It is possible, though. You need to save the upgrade MSIs when building each patch, so when you create your 1.0.1 MSI to effectively diff against 1.0.0 to build your MSP, then when you build your next MSP you need to diff 1.0.1 against 1.0.2. These MSPs must be minor update MSPs, though. That means that the ProductVersion property is included in the patch authoring transform; otherwise, the MSI 1.0.0 + MSP 1.0.1 view won't change the ProductVersion, so MSP 1.0.2 would never be applicable. You should start to see where this gets difficult to maintain for you (not to mention forces the customer to have to install every previous version MSP, which is not a great experience for them either if they are just starting out from your RTM).
In summation, keep it easy for your customers. Just target the same baseline using the MinorUpdateTargetRTM property in the MsiPatchMetadata table of the MSP itself.
In my experience the usual path is that at some time you create a major upgrade MSI (see WiX majorupgrade element). This MSI with new ProductCode and version greater than the last patch version (e.g. 2.0.0) will upgrade all versions betweeen 1.0.0 and 1.0.12. Then you start patching based on the 2.0.0 product.
There are options in patches to patch by replacing each entire file or by binary patching of each file - I'm not sure which you are using, but obviously if you make a small patch to a huge file the patch will be larger than if the patch is a binary update to that file.
The execution of a wix package from a bundle outputs "error 1316: The specified account already exists" during upgrade. How can a windows installer output this error code? I'm afraid there isn't much documentation about it.
We previously released a product consisting of a single msi package, and now we are preparing an upgrade which consists of a wix bundle containing a new version of this msi package. The product code and filename between the original msi package and the update haven't changed.
Edit: The msi package for now doesn't support upgrade. When the user needs to upgrade (whenever it's a major upgrade, minor upgrade or small update), he must first manually uninstall the previous package...
Edit 2: I just removed the references to util extension for compilation and the installer seems to work fine... I still need to fully test it though.
Like MrFusion, I ran into this problem with the uninstall/install of another program. Unfortunately, the link in that answer is no longer valid, and redirects to a page that lists many easy fix solutions, except for the only one that will help. That one, "Program Install and Uninstall", is currently available at: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
It solved the problem for me.
I had his same issue and since win10 doesn't allow you to run the fixit tool from the web, I did the following hack to uninstall Asus Smart Gesture on my Windows 10 laptop.
You need to fake the MS site into thinking your pc isn't Win10. I installed a Chrome add-in that allowed me to change the user-agent of the chrome browser to thinking I was IE9 and previous version of windows: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
This allows you to see the fixit button and to download a portable version of the tool (in case you need to use it on non-networked clients)
I downloaded and extracted to my downloads library in a folder called fixitp.
If I run the exe directly, I get some nasty script error. What I did to get around that was to navigate to the Resources folder and then to the Troubleshooters folder.
I ran the Program_Install_and_Uninstall.diagcab which run and allowed me to uninstall successfully the Asus SmartGesture program.
I then installed a fresh version of ASUS's Smart Gesture from their site.
I suspect that any installed app that you can't uninstall can be resolved by this same process - just haven't run into any other that this on.
Good luck.
An upgrade MSI requires the MSI to have a new ProductCode, an incremented ProductVersion (in the first 3 fields) and the same UpgradeCode. So it's not clear to me that you're actually getting an upgrade, depending on what the Burn part thinks you are doing. It can't do an upgrade because you have the same ProductCode. (You need a MajorUpgrade element in your MSI to do a proper upgrade). So there is some doubt as to whether you're getting an actual full upgrade. If your intent is to replace the installed MSI with a full upgrade, and a higher versioned product then use MajorUpgrade.
So Burn may have decided to do an in-place update by reinstalling the MSI file (and that's more like a patch than an update), and that's relevant because you don't say whether you have any custom actions or WiX util functions (they are still custom actions) that create a user account. If you do, then the most likely reason for your error is that Burn reinstalled your new MSI as an update by reinstalling the MSI file, and some custom action simply ran again, and yes, that user is still there because there has not been an actual uninstall that would delete it. Or the ProductVersion of your MSI is the same and you got a maintenance mode repair, so a custom action would run again.
I'd get a verbose log of the upgrade to see exactly what's going on.
There's a lot of guesswork here because you say you want an upgrade but your MSI isn't built to actually do an upgrade, and you don't say if you have WiX util User in there to create a user account. You also don't say if you have incremented the ProductVersion of your new MSI either, so again that results in more guesswork as to what Burn might do. The verbose log would show whether it's a custom action issue or something else, what kind of update (if any) that you're doing.
I ran into this recently.
For me this worked for me by keeping the names of both the older version and the newer version of the installer same.
No idea why it works, but some of the best practices while working with msi is to keep the name of the installers same.
A couple of links to support the case –
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/KB2918614-td7596942.html
https://community.flexerasoftware.com/showthread.php?189045-Upgrade-failed-with-Error-1316&highlight=error+1316+account+already+exists
I had the same issue uninstalling another program. This Fix-It solved the problem for me: https://support.microsoft.com/en-us/mats/program_install_and_uninstall/en
Update note: it's no longer necessary to emulate an older user-agent on Windows 10 to download the fix-it file.
Update 2: As Chris Johnson mentioned, Microsoft has discontinued Easy Fix, so the link above does not work anymore.
You probably need to change the 'packagecode' (note: NOT 'ProductCode') for the MSI. You'll find it in the Summary Information Stream.
Just encountered this myself when trying to create an Upgrade MSI package. Using Orca to change the 'packagecode' fixed it.
For me, that happening with nodejs when I was trying to uninstall it. What solved in my case was downloading the same version of nodejs that was installed (8.11.1) and uninstalling that from msi installer file.