We encountered an issue for our multilingual installer(bundled with 2 MSI).
For MSI1, we set the Product Id, the same for all languages in the package.
For MSI2, we set the Product Id="*" for all languages in the package.
Installation was successful on the installer(2 MSIs were installed successfully).
The issue happened on the uninstallation part where MSI2 was not uninstalled if the Regional Formatting in Windows 10 is not in English (example: in German).
No uninstallation problem for MSI1, regardless of Regional Formatting.
Would like to confirm if setting the same Product Id for all supported languages in a package is the correct way to implement in a multilingual installer in order to resolve the uninstall issue?
Related
Hi we are currently using Quickbuild for our Automation Jobs,apparently as we tried to deploy some changes we are unable to proceed due to this:
Does anyone know how to fix this? I have tried updating our git version to the latest, and I have also tried to install a cygwin latest version, none of this has solved our problem.
https://www.cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
4.45.
How do I fix find_fast_cwd warnings?
Older Cygwin releases asked users to report problems to the mailing list with the message:
find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report
this problem to the public mailing list cygwin#cygwin.com
Recent Cygwin releases changed this to the message:
This typically occurs if you're using an older Cygwin version on a newer Windows.
Please update to the latest available Cygwin version from https://cygwin.com/.
If the problem persists, please see https://cygwin.com/problems.html.
This is not serious, just a warning that Cygwin may not always be able to exactly emulate all aspects of Unix current directory handling under your Windows release.
Unfortunately some projects and products still distribute older Cygwin releases which may not fully support newer Windows releases, instead of installing the current release from the Cygwin project. They also may not provide any obvious way to keep the Cygwin packages their application uses up to date with fixes for security issues and upgrades.
The solution is simply downloading and running the Cygwin Setup program, following the instructions in the Internet Setup section of ``Setting Up Cygwin'' in the Cygwin User's Guide.
Please exit from all applications before running the Cygwin Setup program. When running Setup, you should not change most of the values presented, just select the Next button in most cases, as you already have a Cygwin release installed, and only want to upgrade your current installation. You should make your own selection if the internet connection to your system requires a proxy; and you must always pick an up to date Cygwin download (mirror) site, preferably the site nearest to your system for faster downloads, as shown, with more details to help you choose, on the Mirror Sites web page.
The Cygwin Setup program will download and apply upgrades to all packages required for Cygwin itself and installed applications. Any problems with applying updates, or the application after updates, should be reported to the project or product supplier for remedial action.
As Cygwin is a volunteer project, unable to provide support for older releases installed by projects or products, it would be helpful to let other users know what project or product you installed, in a quick email.
I used Flexera's InstallShield Express to bundle my software into a Setup.exe file. I included .NET Framework 4.7.1 redistributable (2. Specify Application Data > 'Microsoft .NET Framework 4.7.1 Full' is checked and highlighted in middle panel, and says 'installed locally' > 'Install before feature selection' is checked on bottom panel).
I went onto my fresh installed Windows 7 computer with no internet access and attempted the install. It gave me the error:
"An error occurred while downloading the file
http://saturn.installshield.com/is/prerequisites/Microsoft.NET Framework 4.7.1 Full.prq"
I then connected to the internet, and it was able to go through. I looked for a text of the prq. There may be a way to find it thru InstallShield, but I found a forum post from community.flexerasoftware.com asking about 4.7.2.
The two parts of interest are:
<file LocalFile="<ISProductFolder>
\SetupPrerequisites\Microsoft .net\4.7.1\Full\NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
URL="https://download.microsoft.com/download
/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe"
FileSize="0,0"/>
and
<properties Id="{BFF4A593-74C5-482F-9771-7495035EBBB0}"
Description="This prerequisite installs the .NET Framework 4.7.2 Full standalone package."
AltPrqURL="http://saturn.installshield.com/is/prerequisites
/Microsoft .NET Framework 4.7.2 Full.prq"/>
The fact that the file reads '4.7.1' is another can of worms I need to explore (not in the scope of this question). I'm assuming all prq files have a common structure. I believe that this information tells me the URL (download.microsoft.com) was skipped and the AltPrqUril (saturn.installshield.com) was used during my install. But even if the URL were not skipped, it would still looking at a page on the world wide web.
Question
Why do I need internet connection? The 'Full' version is specifically different from the 'Web' version in that you do not have to connect to the internet to install it.
Avoiding Internet Connection Requirement
To embed runtimes in the setup.exe and hence avoid the need for
an Internet connection, you can try to set the option "Extract
prerequisites from setup.exe" in the setup.exe tab in the
Release view as illustrated in the second screenshot below.
Then you select the "Full" .NET Framework version in the
Prerequisites View. Not 100% sure what features the Installshield Express version has vs the full versions. The below is from the Premier version.
You can check your finished bundle, by doing a "setup.exe /a" -
from a command prompt - on the final
setup.exe and extract the files to see what is really included in the bundle.
Quick Reminder
I think you should generally call Installshield support if you have a support agreement, or check their own community at: https://community.flexerasoftware.com.
Just mentioning this since people sometimes forget to check whether they have support agreements and support & community might resolve your problems in 5 minutes - if you don't get answers here.
Release Wizard
However, just shooting from the hip I would propose that the cause could be this setting that is available in the Release Wizard in the regular version of Installshield 2018. It is probably similar in the Express edition:
In the Release property pages, it seems this setting is under the Setup.exe tab and it is called "Installshield Prerequisites Location":
[
Prefer Download
For what it is worth I really dislike old, outdated runtimes included in bloated setups. This has to do with my experience as a corporate deployment specialists where much of the day consisted of extracting outdated runtimes from vendor packages.
I would always suggest you download very common runtimes from the web, or allow them to be installed via Windows Update. That includes basically all Microsoft runtimes.
I only like to bundle runtimes if they are 1) Rare and special, 2) Stable and well tested, 3) Small and well-behaving. Even then I would prefer them downloaded and installed separately - to allow security fixes to be installed without rebuilding your whole setup - you just put up the new runtime version on your server (marketing will want a new build for physical release - that is just added risk if you ask me).
War story: the SOAP merge module - back in the day - almost destroyed my package with global deployment scope. Deployment errors quadrupled. Prerequisites can really ruin your work, and you will face little understanding for the problem seen. Try to make it clear what breaks and why. And get rid of all prerequisites you can (pie-in-the-sky thinking, I know). Certain runtimes are unavoidable of course. I just ramble on :-).
Microsoft's vexing dumping of vdproj install projects in VS 2012 leads one to try Installshield LE which is sort of built into VS2012. Sadly, it creates installers that do not work in any way shape or form with 64 bit.
So for instance clicking the Office 2010 installed checkbox only makes a prerequisite for 32 bit Office. It fails to detect 64 bit.
After a lot of chickenless head exploration of Installshield the bottom line is:
1) You need the Professional or Premiere version in order to deal with 64 bit.
2) You need to edit their provided condition to make a compound one that ORs all the guids of Office that you are interested in together as it only checks for one of the many out of the box. This details the structure of the GUIDS: http://support.microsoft.com/kb/2186281?wa=wsignin1.0. I found it helpful to install various versions in a VM and then using regedit to see what the GUID ends up being.
This post is so that someone can actually discover this with a Google search, instead of it being hidden behind a paywall / private support site.
Update October '13 AlBear
There is a beta version of installshield LE for VS2012/13
To build x64 installation packages check on the help files
Look for "64 Bit" .
The way InstallShiel LE recognizes x64 target is by either defining the [INSTALLDIR] property as one of the 64 bit Folder or by defining at least one of the setup components as 64 Bit.
This works as I built an Excel 2013 Add that loads at startup and works fine.
For the Prerequisite for VSTO to work: You need to change file size and hash a it looks like the recommendations from Microsoft article "Deploying Office solutions vsto 2013" are outdated and the XML code recommended has the wrong file size and hash. Not too difficult to fix. However I think that Microsoft is unfortunately going through a period of crisis and this failure to provide reasonable support is uncharted territory .......
Cheers
InstallShield and WiX is like Visual Studio using VB.NET and SharpDevelop using C#. Just as those tools both create EXE's and DLL's using IL code but different language providers,
InstallShield and WiX both create Windows Installer databases using different languages. Just as a VB EXE can consume a C# DLL, an InstallShield MSI can consume a WiX Merge Modules. This gives you the best of both worlds.
The thing to understand is a VSTO AddIn installer isn't a 64bit MSI, it's a 32bit MSI that deploys an AnyCPU DLL with registry entries for either 32bit or 64bit Office. It's the bitness of Office, ultimately, that determines the bitness of your AddIn.
I have a template that I've used for a dozen customers. It uses InstallShield Limited Edition and it's Preq Bootstrapper to lay down all the dependencies and consumes a merge module authored is WiX and IsWiX (CodePlex). Otherwise ISLE is just a container for the UI and it's one feature.
The merge module takes care of all the dependency detection, gating logic, laying down files, installing certificates, setting registry values and so on.
Some more details can be found at:
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
Apparently the small print referenced here should have been one clue: Does InstallShield Limited Edition Support 64 bit Installer?
The current Office prerequisite in Installshield is also misleadingly worded. It should really be "Office 2010 Home & Professional 32 bit".
Perhaps they intend to upgrade it over time to be comprehensive or perhaps everyone has to go through the same hassle to fix it for a few cases they care about. The support guy claimed there are too many GUIDS for all the combinations of versions, bitness, releases etc.
Home & Student, Home & Professional, Professional, Office 2010 Professional Plus License
32bit, 64bit, Languages mangled in there, Service Packs, etc. Depending on the set you care about the number of GUIDS is rather large.
I have multilingual installation setup program, where user can select 5 different language. Consider I have installed application in German language. whenever I am uninstall the application or update the previous setup it is launching in German. I would like to know how setup will detect the older installation product language.
In my case I have created a upgrade only installation where it will detect the previous version of the installation and do the major upgrade. In the major upgrade I don't want to display the language dialog. The update should happen in the earlier installed lanugage.
Does installscript has any API to detect the earlier installed applications product language.?
I belive there should be some way to do like that as uninstallation does, Can any body give me some suggestion.
Thanks in advance.
For a pure InstallScript installation, this is tracked in the uninstall key's command line. Look for the /L parameter.
For Windows Installer-based installations, this is remembered automatically by Windows Installer tracking which transforms are applied at initial installation. This includes the language transform.
We've installed a sharepoint server at our institute and created to portals one arabic and one english. We installed SLK (using Addsolution, Deploy, etc) and it worked fine. Then we installed the Arabic language pack , hoping we could choose the arabic option on the arabic sites but the language pack is installed in the same manner as the initial English version and overwrites everything, so then we have arabic only.
Now I'm not that technical regarding deploying solutions, but i wanted to know is there away of installing two separate solutions (language wise) on the same server for different language portals?
Did you install WSS or MOSS?
MOSS is able to work at Multi-language platforms, but wss you can't do this.
As you can see in this picture, MOSS give you the chance to select the WebSite language.
(source: fivenumber.com)
Guilherme Ferreira
http://guilhermeferreira.wordpress.com/