Let's say there is installshield project consisting of several releases using the same script. This project builds several installers, for example:
Releases:
App A - builds into AppA.exe installation file
App B - builds into AppB.exe installation file
The project also contains Major upgrade items for each of them:
MajorUpgradeA - triggers for upgrade code of App A
MajorUpgradeB - triggers for upgrade code of App B
Everything works fine if only one of the apps is installed. If user have both of the apps installed then upgrade works incorrectly. With both when user tries to upgrade AppA using AppA installer file, then both AppA and AppB are uninstalled. It should only uninstall AppA, install new version of AppA and ignore AppB when AppA installer is executed.
How to prevent such behaviour, assuming that the project cannot be split to two seperate ones for each of the apps? Doing it in several different ways failed so far:
Triggering silent uninstall from script instead of using Major Upgrade items does not work because there can be only one active msi at a time during execution stage. It could be running in UI stage but then silent install does not work because it ignores the UI execution.
Upgrade components do not have any condition parameters/settings where it would be possible to set it to run such upgrade only if currently running installation has specific product code.
Related
I am trying to deploy a Java project into Google App Engine from Eclipse and am blocked by JSPs.
Everything JSP makes my app not capable of deploying due to "'utf8' codec can't decode byte" error.
Not trying to insert any strange (not UTF-8) character, everything Eclipse is set to UTF-8.
Tried to send archives which were OK with the Google App Engine Tools for Eclipse (soon to be deprecated), won't deploy.
I've seen threads regarding reverting the Google Cloud Tools for Eclipse plugin to previous version (1.58 seemed to avoid a few problems) being a possible solution to these recent errors but I have a problem installing, the batch just tells me "Install will exit" ?!
Tried to uninstall previous (latest) versions before, made sure I was launching the bundled-python batch, still not capable of installing an old version of the Google Cloud SDK shell.
Would be glad if anybody had any suggestion at what makes my install fail.
Thanks in advance.
There are a few ways you can get older version of Google Cloud SDK.
Download versioned archive
(If you are on windows) Grab google-cloud-sdk-XXX.0.0-windows-x86_64-bundled-python.zip file.
Unzip it to some\dir
Add some\dir\google-cloud-sdk\bin directory to your system path
Restart your command prompt (or other apps which depend on gcloud) and run for example gcloud info, it should be fully functional installation, no need to run install.bat.
Alternatively, use existing SDK installation and gcloud component manager to go back to previous versions. For example
gcloud components update --version 158.0.0
target by version number using apt-get :
sudo apt-get install google-cloud-sdk=294.0.0-0
I had an issue with concurrency installation of 2 applications.
Using install4j5 created two separate .exe files (ONE.exe and TWO.exe.)
After installing ONE.exe (Not running) if I installed TWO.exe, the ONE application is getting uninstalled.
But if I tried to install TOW.exe while ONE is running, it is allowing to install both applications.
Is there any way to make the concurrent install when the other application is not running?
I want to use SqlLocalDB for my application. The application is deployed with WiX. Now, I am searching a way to install SqlLocalDB when my application is installed for the first time. How can I do that? Would it be enough to deploy some binaries with my application or do I have to install the whole SqlLocalDB.msi? - When installing of the whole msi is needed - how can I do this with WiX? - The goal is, that the result is a single msi-file which holds all what is needed for installing my application.
I'm not aware of a private deployment model for LocalDB. If WiX is your tool of choice, you'll need to use it's Burn bootstrapper feature to install LocalDB as a prerequisite. The result will be a single EXE that installs 2 MSI's.
Can you please enlighten me on my task?
My task is to create a nightly builds of MSI (done in WiX) and install it to our web server using powershell.
TFSBuild server build an MSI
Run Powershell to uninstall and install the newly build MSI.
Run Powershell to Start the windows service.
The WiX MSI contains WindowsService and a Web Application.
Below are list of what i have done so far:
Solution.sln : Configuration Manager and "x86|debug" (check all the files that needs to be built '.wixproj' already checked)
Created a build definition and set "x86|debug" for configurations to build and set projects to build is my solution file.
but after the build has completed, there is no MSI files on the binaries build folder on the build server. :(
Thanks in advance.
Few pointers:
Have you installed Wix on the buildserver?
Which version of Team Build are you using? 2010 has the preference here as the tooling has progressed a lot since 2008.
Did you configure to run msbuild in auto or x86 mode (auto can result in 64-bit which has some issues with the latest stable version of wix) link link
Is your build agent running on a 64 bit server? If so, you either need to run the build agent under an administrative account or do some mucking around in the registry to fix issues with Wix. link
To install the build using Powershell, I personally prefer TFSDeployer, which can monitor your build output and trigger powershell scripts based on the build outcome. It takes away the deployment responsibility from the build server and saves a lot of headaches around security and account configurations.
Today I created installer using Cava Packager Perl. I can install the app using the installer that I have created. But the problem is in my system that app is running fine but in other system app is not running. That is its getting installed but app is not running.
Assuming that your platform is Windows and the version of windows on which you are running the application is equal to or greater than Windows XP, you can create a diagnostic version of your application that will give full detail of the startup and loading process on the failing machine.
In the Build Options tab of Cava Packager, check the following two options:
1.Package Diagnostic Executable with release
2.Allow Loader Verbose Output in Release Executables.
Create your installer package and install on the failing machine.
In the installed bin directory, assuming your executable is called 'myexecutable' you should run:
diagnostic myexecutable.exe
You should get full details of the loading process and where it fails.
There are two very common reasons for failure when deployed to another machine.
A module you are using is linked to a dll that Cava has failed to automatically bundle
You are trying to run on Windows 2000 - which isn't supported by Cava.
Note: I'm involved with Cava Packager development.