We create our installation packages with WiX Toolset. I'm trying to enable 4-digit product versioning (like 4.0.0.195, 4.0.0.196 etc). The problem is that when product is upgraded the previous version is not uninstalled.
I am aware of ProductVersion limitation. And my current approach to the problem is writing a C++ custom action. This action successfully detects the installed product, I have its upgrade code. The custom action is also capable of setting MSI properties through MsiSetProperty. But what do I need to do to force removal of the installed product?
Per this link I see that in MSI there is Upgrade table that I might have to modify. But how do I do it for running installation? MsiGetActiveDatabase gives a read-only handle. MsiOpenDatabase opens MSI files by path.
Am I going the wrong way?
Yes. You are going the wrong way. Use the first three parts of the ProductVersion so upgrades can work correctly.
Related
I made a laucher application in c++ that use direct 2d and 3d. Now i making a installer for this. I followed microsoft docs and i made it but there is a issue.
I use 'Microsoft Visual Studio Installer Projects' extension to make that.
The issue is if i already installed my launcher with a previous installer msi file, if i rebuilt a new installer msi and try to run it it show me this error
This is the microft docs i followed to make this: https://learn.microsoft.com/en-us/cpp/ide/walkthrough-deploying-your-program-cpp?view=msvc-160
In the future maybe i need make a update for my laucher. It isn't good idea everytime need go to control panel, search and delete the previous application and install the new one manually.
Anyone know how can i make it automatic remove old version and install new one? Maybe there is a better way to create a installer?
Major Upgrade: In order to upgrade properly, you need to use a major upgrade so that your new version uninstalls the old one and then installs itself (this can happen in reverse order too: new version installed and old remnants deleted afterwards, but this is another story). There are further upgrade types, but stick to major upgrades for simplicity.
The message you are receiving is basically because you have a different package code for the new MSI, but not a new product code or version number (or just one of those problems). You need to get the settings straight.
Recommended step-by-step:
Set "RemovePreviousVersions" to True in the project properties.
In the same place: bump up your version number (one of the first 3 digits)
Answer yes when asked to change product code, or do so yourself manually.
Keep the UpgradeCode the same - it needs to be stable across releases.
Rebuild your setups. Clean out your box of old remnants before testing or test on a virtual.
Testing: Remember to simulate your full upgrade process from first version installed to the new one with different version numbers for a few core files and also try to add a few files and such things. Very important to verify.
Heads-Up: Before ending, it is standard procedure to warn about the potential limitations of VSInstaller Projects (shorter list form).
MSI Tools: Here is a short "review" of other MSI tools.
MSI Upgrade Types: Shamelessly stolen from the InstallShield help file (towards bottom):
I created the MSI build package for our application. After this installation, we triggered another dependent driver software in the separate process in a committed event of Installer class like below,
Process.Start (" Path of driver software ")
We are facing an issue, installed directory ( It's empty ) folder is not removing while un-installing the same. Actually like installation, we triggered the un-installation of dependent driver software in the separate process by overriding the Uninstall method of installer class.
Anyone, please help me to overcome this issue? How could I remove the installed directory?
I can't change the installation procedure, since we are aware that we can't process another installation/un-installation when another one is going.
You are running a non-MSI driver install EXE from within your MSI? Correct? Or maybe it is an MSI wrapped in an EXE?
Do you have Installshield Premier? Could you use a suite project and install the EXE via the bootstrapper before (or after) the MSI install? I have honestly never used this feature, but running setups in sequence is what it is for. Embedded custom actions in MSI files kicking off EXE files are notoriously unreliable. This is - in my opinion - especially true if you are running with managed code as well (which I think you are).
In the long run managed code may yield safer custom action code (security-wise based on CAS), but for now it seems to cause unwanted runtime dependencies - especially for very large-scale distribution (global distribution) targeting diverse Windows versions (Vista, 7, 8, 10).
I am told it takes a while to get used to Installshield's suite feature, but maybe it is better for you? You can run EXE files, MSI files, patches and zips in sequence. Some fiddling to define uninstall and upgrade behavior I guess and lots of testing. I am pretty sure corporate application packagers would be happy to see a suite rather than an MSI with lots of strange stuff embedded in it.
UPDATE: Once you have compiled a suite setup.exe file it can be extracted as described here: Regarding silent installation using Setup.exe generated using Installshield 2013 (.issuite) project file
Alternatively you could try to extract the setup.exe files for the driver setup and install the drivers as regular MSI components and run DPinst.exe to install / uninstall the drivers (tool from DIFx). Also quite clunky - especially when you need to include uninstall.
Your driver setup likely uses DPInst.exe already. I would check if you can extract an MSI from the EXE and use it instead of the EXE to include in the suite project. Some hints for how to deal with setup.exe files (extraction, runtime paramenters etc...): Extract MSI from EXE.
WiX has the Driver element in one of its extensions to deal with driver installs. I have never had the chance to test it.
I had errors installing VS2017 with
Package 'Microsoft.PortableLibrary.TargetingPack.Msi,version=15.0.26004.1' failed to install
The actual IDE will open but I don't have any XAML functionality - it appeared to fail the installation before this component was installed. XAML files won't load and there is no XAML listed under 'Text Editor'.
How to fix this error?
After several hours finally managed to get it to work:
Still not sure exactly what a targeting pack is - and why VS couldn't install it but I manually installed this package and managed to get it to work:
Manually installed:
Microsoft .NET Framework 4.6.2 Developer Pack and Language Packs
https://www.microsoft.com/en-us/download/details.aspx?id=53321
Other things I did that may have contributed to the solution:
I rebooted
I removed all files in C:\ProgramData\Microsoft\VisualStudio\Packages - actually I moved them to an OLD folder and later deleted them. You will see packages downloaded here after you restart the install.
I had previously created a symbolic link from %ProgramData%\Package Cache to another drive to save space (https://superuser.com/questions/455853/can-i-delete-the-folder-c-programdata-package-cache). This symbolic link didn't seem to work anymore leaving me with some files in %ProgramData%\Package Cache and the rest in the other drive. I moved them over and recreated the link. If this is something you did to save disk space and forgot then that could contribute towards a failed solution.
Something above fixed the issue and I now have XAML back again.
Note: The VS2017 RC1 does not support offline installation so that was another avenue I explored and gave up on. The command line switches currently do NOTHING.
I believe the package I needed is the following one but not absolutely sure.
C:\ProgramData\Microsoft\VisualStudio\Packages\Microsoft.PortableLibrary.TargetingPack.Msi,version=15.0.25719.0
This ought to be simple, but seems to be anything but.
I wish to create an installer that can be used by those using group policies to install products. I do not know then if this must be an MSI, or an EXE. Can an EXE install be installed via a group policy? I chatted with another Wix novice who seemed to think it was a bad idea to have an install that was a plain MSI file.
My product uses the Visual C++ 2010 redistributables. I do not wish to use merge modules. Both this and this link give some of the disadvantages of using them. I object to 1) installing things that the user has not consented to, and 2) not having a control panel uninstall item with a version number that users can inspect and see if they have the latest version of. Thus, I am not interested in responses consisting of people lecturing me on why I ought to use merge modules. If what I am asking for is truly IMPOSSIBLE without merge modules, then please explain why.
I do not know if it is necessary to use a bootstrapper to kick off an EXE install. I gather that it is, but it seems bizarre for me, for an MSI with such involved tables and descriptions, not to be able to kick of a mere EXE, ON THE CONDITION that the redistributable is not installed already.
If it is necessary to use a bootstrapper, I would like to know if anyone can find a complete example, with both bootstrapper and Wix code, for an example of a product install; ideally, together with the command lines necessary to compile them, for such a common case as installing a VC++ 2010 (or possibly 2012) program, together with its redistributable - with the latter being installed as the EXE.
I have found this to be straight-forward and easy to do in Inno Setup Pascal - except for the Group Policy part. I have found anything but COMPLETE examples and/or straightforward explanations to accomplish this using a Microsoft installer. No matter what Microsoft says, I would consider such an installer to be best practices. My code is not managed, and I would like to support XP. Thus, a bootstrapper that requires some .net to already be installed would only add another unsolved layer of complexity to the problem. One that statically links to a .net library might not be too bad, if it did not create very much overhead. My MSI install seems to work pretty well. I did not realize that installing a vcredist_x86.exe would be a problem with such an elusive solution. I do not have Visual Studio. I am using the Qt framework, and have Visual Studio installed only to compile my application. If you have a bootstrapper solution, please specify which bootstrapper you are using. Ideally, the same idea could be extended to more than one prerequisite, and the same coding pattern could be used. If there were a way to use a merge module or additional MSI so that the redistributable would have its own control panel entry, that could be acceptable.
Brownie points for suggesting a mailing list, forum or well-populated chat channel to talk about Wix that does not require one to receive a lot of unnecessary mailing list traffic.
Group Policies by default don't allow EXEs to be installed. I did read about some admins that repackage EXEs into MSIs to deploy them via GPO but that is rather hacky. There is also the possibility to script the deployment - GPOs support script execution, machine or user level.
You can't embed an MSI within another MSI either because only one installation can execute at any time (Windows Installer design).
I don't know how you will be providing your product to your customers but vcredist_x86.exe (I am trying this with the v100 version) uncompresses into the root folder and generates an msi and a cab (vc_red.msi and vc_red.cab) among other files. If you provide these to your customers they can add them to the same GPO used to deploy your product.
My Windows XP workstation at the office had several old versions of the Java JDK installed on it. Today I decided to install the newest Java JDK and uninstall the older ones. BIG MISTAKE APPARENTLY!
I don't understand why, but XP seems to think that one of the removed JDK installations is the one that it wants to use. Not sure if it is relevant, but it was JDK 1.6.0_13. I uninstalled it earlier using the XP "Add or Remove Programs" from the Control Panel. The JDK folder is gone (as one would expect) but apparently not forgotten. Here are the symptoms:
Eclipse will no longer start up and use the new JDK that I installed. Eclipse acts as if there is no JDK available on the system.
When I type java -version at a Command Prompt I get the following response:
Error: could not open `C:\jdk1.6.0_13\jre\lib\i386\jvm.cfg'
(Gee thanks. I never would have guessed that the uninstalled JDK could not be found...)
When searching around on the machine I found a system service named "Java Quick Starter" that is pointing to the removed JDK directory.
Now I know what some of you are probably thinking. He has a JAVA_HOME system variable pointing to the old location and/or has the old location in his PATH system variable. Not the case! There are no system variables that reference this old JDK and neither does my PATH. In fact, I have already defined a new JAVA_HOME for the new JDK that I installed this morning and added it to the system PATH. I was sure that would at least give me success from the Command Prompt, but no luck.
And in case you're wondering if I have rebooted after the install/uninstall/system variable changes, yes I have.
QUESTION
Does anyone know what I did wrong here? How do I purge these references to the uninstalled JDK from my system so it can start using the newly installed one?
EDIT 1
I checked the registry as duffymo suggested. There was some stuff under HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft that did not look right. An entry still existed for the 1.6.0_13 JDK that I had deleted, and a number of the newer JDK installs had entries here with their JavaHome attribute set to the path for the old 1.6.0_13 JDK for some inexplicable reason!
I uninstalled all of the JDKs on the machine, but still there is a remnant of the old 1.6.0_13 JDK in this registry section.
Also, a 1.6.0_21 JRE is still listed in the Add and Remove Programs list that gives an error if I try to uninstall it. That one is also shown in the registry and has a registry "JavaHome" key with a value that points to the no-longer-existing JDK 1.6.0_13.
Check the registry to see if something is hanging around there to point to the old JRE.
Look at HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft. You'll see Java Development Kit and Java Runtime Environment there. See what they say.
Now that you've found that the registry values are incorrect, I'd recommend either modifying them to point to the correct values OR remove them, uninstall the JDK, and reinstall.
You could also maybe try disabling the service from starting.
Copied from my repost of this quesiton on www.superuser.com:
https://superuser.com/questions/203143/cannot-install-java-jre-on-windows-xp-workstation-possibly-due-to-previous-faile
I tried CCleaner on the registry, but it didn't solve the problem. I was feeling pretty desperate at that point and decided to search the registry with regedt32 for instances of "jdk1.6.0" and delete everything that was obviously garbage. Any registry references to JDK/JRE instances that I knew no longer existed got deleted. Usually this meant deleting the whole key, but there were a few keys where I just had to delete an individual value/data pair. I rebooted after I was done performing meatball surgery on my poor defenceless registry.
DISCLAIMER: I don't recommend that anyone start messing with random keys in their registry as the primary way to solve a problem! This was my last resort before considering the option of re-imaging my workstation and re-installing EVERYTHING.
Having said that, this approach did solve my problem. I was able to install the JRE and then things like Eclipse started working normally once again. I next installed a JDK of the same version without incident.