I'm using Installshield 2010 premier edition.
When I try to install our software with an installation package, Installshield always terminates abnormally. The reproduce sequence is following:
Set Windows(7 or 8) Locale to English
Install Korean Language Pack for Windows
Change Windows Locale from English to Korean
Create a Windows user account with Korean Characters
Login to Windows with the new user account
Change Windows Locale from Korean To English
Launch the installation
The installation is terminated abnormally
The installation worked just fine with the above sequence if I built the installation package with Installshield 2011. I found out the article on your Installshield release note that setup within unicode paths is only supported Installshield 2011 or after. (http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q208910)
Is there any work around to make Installshield 2010 support the setup within Unicode included paths?
You didn't mention which kind of installation you're running (InstallScript or Windows Installer). For Windows Installer setups before we introduced proper Unicode support, sometimes you can get away with creating a single .msi file for installation. (Most of the difficulties related to non-codepage Unicode paths were within setup.exe, so bypassing it alleviates many of them.) If you're using an InstallScript installation, this isn't an option, as it requires the setup.exe launcher.
Related
I have a universal windows application for windows 8.1 and windows phone (WAP)
But my customer doesn't have access to the windows store, there's a way to use Installshield or something similar to generate a Setup Installer?
At the moment i have to type some code in powershell and it's really annoying and unprofessional.
There's a workaround for this situation?
The Suite/Advanced UI project type (Premier edition of recent enough versions—probably 2012 Spring) has support for side-loading .appx packages. More recent versions (2016 or so) add support for Windows 10 UWP App Packages.
I am looking for the safest way to detect what components of Microsoft Office, if any, are installed on a given workstation. I realize this could be seen as a question for Serverfault as well, but since I'll be using this in a script and many people here are more familiar with the inner workings of Office, I thought this would be the best place to ask.
I've looked at the uninstall key, but it shows components that do not actually exist on the system. I believe this has to do with the way Office can install a component on first access. I'm not fond of looking for executables as the path can theoretically change.
I ended up testing for specific registry keys, taking into account the differences between 32 and 64-bit Windows installs. I'm paying attention to the following registry locations/values:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\12.0\—The base Office12 key on a 64-bit Windows install
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\—The base Office12 location on a 32-bit Windows install
Office base path\Outlook\InstallRoot\Path—Key signifying Outlook installation path
Office base path\Registration\{90120000-0012-0000-0000-0000000FF1CE}—Key for Office 12 Standard GUID
Office base path\Registration\{90120000-0011-0000-0000-0000000FF1CE}—Key for Office 12 Professional Plus GUID
With these locations I've been able to:
Detect whether Office is installed.
Detect the version of Office that is installed.
Detect whether Outlook is installed.
I have not attempted to get any more granular than this.
If you really think you cannot rely on paths to exe's or dll's, I would diff the registry (many tools for this exist) of before and after snapshots of installing the various components. In my experience however, I find it necessary to test existence of dll's and other files for detecting installed components for Office (I had to test for VBA dlls to detect presence of visual basic module installed, for example). The paths of files can only change so much. You just need to be cognizant of 32-bit and 64-bit patching, and winxp and win7 pathing.
I am currently using the Visual Studio 2010 Setup Project to deploy my application to an MSI installer file, which includes a Windows Service and a Windows Forms application. But I am disappointed with the performance and compatibility of this form of packaging.
My application is compatible with Windows XP and upwards, but several older XP user-testing boxes simply don't have the right version of the Windows Installer or the necessary service pack installed. (Un)installation can take dreadfully long for a program under 1MB in size and many systems do not support it. InstallState errors can crop up and ruin the (un)installation if the service has been deleted or already installed, or if any program files are missing (for uninstall).
What I need from an (un)installer:
Manage .NET dependencies.
Copy/remove my application files to a folder.
Add/remove menu and shortcuts to the desktop and Start menu.
(Un)install a Windows service, though I can also do this from my application. The stop and uninstall part is important.
Run my application when it's done.
This question's answers recommend NSIS (which I have used with good results) and WiX. Ironically there is no easy link to simple installer for WiX on their website.
Am I missing something with VS2010's setup project? It is optimized for speed, but it's just too slow.
You should run the installer/uninstaller explicitly with
msiexec /x thefile.msi /l*v thefile.log
(/i for install). Then inspect the log file; it will have time stamps telling you what action took what amount of time. Of course, the logging will affect that, but you should get an idea what makes it take so long.
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.
I have a product which has been traditionally shipped as an MSI file. It is deployed through some sort of SMS push to thousands of desktops by our various clients. The software we use to create these installers is getting long in the tooth and we are looking to replace it. We have already standardized on InstallAnywhere for most of our products as we support many operating systems. Unfortunately InstallAnywhere cannot produce MSI files.
I am wondering if it is required that SMS use MSI files or if it can handle other installer types (.exe). If not, are there any open source programmes for creating MSI files?
If your clients are using SMS then you're in the clear... SMS supports EXE. You enter a command line when creating 'Programs' and clients are probably already calling msiexec to launch the MSI. Also I'm pretty sure SMS predates the MSI file format :)
However if they're using Active Directory / Group Policy Objects.. then you're SOL as that does depend on MSI format for deployment.
If you do want to stick with InstallAnywhere, there are a number of "MSI repackaging" tools available. Assuming you're looking at a basic application (device drivers might be an issue) then repackaging should be a fairly painless process.
If you want to create MSI files, try WiX: Windows Installer XML (WiX) toolset.
It's an addon to Visual Studio 2005 and 2008, is open-source, and Microsoft developed. You can use XML to specify and create MSI files. There is a wealth of resources available on it, and WiX 3.0 is, although in beta, is very complete.
Also, note that you don't have to start from scratch, you can decompile an existing MSI using the WiX Dark utility, modify the XML in any way you like, and then recompile it into an MSI.
Actually, with group policies, there's the ZAP file alternative, but I would recommend regardless that you learn MSI. It's not that hard, and very flexible.