I have shortcut Program menu -->Company Name --> Product name.
My requirement is the product name should be localized when locale language (operating system) is Japanese.
How is this possible in Install shield 2011?
Please help.
Windows Installer only supports localizing shortcut names in two ways. One is via language transform, which would then reflect the language chosen during installation as the sole name of a shortcut; this works with all versions of Windows Installer, but is only available in the Premier editions of InstallShield.
The other is through MUI properties. By setting the Display Resource setting of a shortcut to reference a multi-lingual resource dll, the name is updated to match the user's preferred language. This approach only works on machines with Windows installer 4.0 or later.
Related
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?
I am struggling to find an answer to this online.
I am using Inno Setup to create an installer for several files. I know InnoSetup can check file versions and wont overwrite with old versions which is brilliant.
However, I cant figure out how to make tortoise SVN add the "Version" property to its files.
I would rather not use the "touch" flag in Inno Setup for all the files.
I am fairly new to versioning (the creation of version ID's), and any 'usefull links' would be greatly appreciated on this one
That's not the kind of "version" Inno Setup checks.
Inno Setup checks the executable (.DLL/.EXE) version info (it's a Windows resource embedded in the file - see Version Info Resource at MSDN for details), like you see if you right-click an application in Windows Explorer, look at Properties->Details, and see things like:
File Description Some Application Description
Type Application
File Version 2.5.1.247
Product Name Some Product Name
Product Version 2.0.0.0
Copyright © 2013, Some Company Name
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.
I have some projects built with different versions of VS2005 that require different run-time version. i need to display the assemblyIdentity to see which run-time is required to run the program. I need the information to include the specific VC80 runtime MSM in my WiX installer project.
{Edit}
While the binaries have been built with Visual Studio I don't have a VS on the PCs where WiX shall be used. I am reluctant to install an Express version, since I am a guest on that PC.
{/Edit}
How can I conviniently display the embedded manifest? Preferrable with a small tool, command line tool would be OK.
Manifests are stored as resource in executables/DLLs. These are stored under RT_MANIFESTresource type. Open the resources under it and parse it as XML.
One example is pasted below (I opened one of my EXE using VS resource editor):
The PeStudio is a small tool that does the job. Including displaying the manifest in clear text.
Additionally it displays all DLLs that must be present on target system. That helps to author the installer.