I've got a legacy application that's installed directly to the user's c: drive, in a directory (like c:\MyApp). Nasty stuff. Problem is, the user can specify to have a second installation on a second drive (like e:\MyApp), and they can have two different versions of the application installed at once in either directory. They can also decide to install the app elsewhere in the directory tree, but those are the two most common locations.
I did not write this scheme. It makes baby Jesus cry, as far as I'm concerned.
I have to write an installer to add a module to this scheme, and the user needs to be able to select which installation they want to install the module on. I thought I'd try this in WiX.
How do I do this?
I was going to do a directory search like
<Property Id="MyAppInstallationSearch">
<DirectorySearch Id="MyAppDirectory" Path="C:\MyApp">
</DirectorySearch>
</Property>
and then:
<Directory Id="TARGETDIR" Name="MyAppInstallationSearch">
<Directory Id="INSTALLLOCATION" Name="AdditionalTools">
</Directory>
</Directory>
to have an installation location.
So how do I:
Make that search be relative, not absolute? (the documentation specifies that this can be done, I just don't see how).
If the user has multiple locations, give them a choice of which installation to use?
It will be relative meaning, AdditionalTools will be under the folder found by MyAppInstallationSearch.
This will involve creating UI, which is not an easy thing in Wix, there are products that can create Wix output or WixEdit. You will need to search the directory on all possible places and show the user radio buttons (each bounded to a search results) to selected where to install the the new prodcut.
I had to implement the same thing and I used an external UI handler to completly customize the installation process. I also display a wizard page where the user can select the version he wants to upgrade from. But be aware that this isn't something you can do within a day or two.
I don't know which programming language you use, but if you want to use .NET you can the Development Tools Foundation included with Wix3. The libraries can be found in the SDK folder of your Wix installation (you'll mainly need Microsoft.Deployment.WindowsInstaller.dll), documentation is in the DTF.chm in the doc directory. You'll also need a bootstrapper to install the .NET framework.
You could also wait until Wix 3.5, which will include Burn, a boostrapper and external UI handler you can easily customize.
HTH
Related
This post is a follow up on this thread I created not long ago.
Basically I'm setting up a shared folder with WiX, and I'd like to come up with a clean and efficient way of doing it (see the link above for the best practices).
My current setup looks like this:
<Directory Id="MYSHAREDFOLDER" Name="FolderName">
<Component Id="MyShareComponent" Feature="MyShareFeature" Guid="MyGuid">
<util:User Id="Everyone" Name="Everyone" />
<util:FileShare Id="MyFileShare" Name="MyFolderName">
<util:FileSharePermission User="Everyone" GenericAll="yes"/>
</util:FileShare>
<CreateFolder>
<util:PermissionEx User="Everyone" GenericAll="yes" />
</CreateFolder>
</Component>
</Directory>
Ultimately I've ran into the good old issue of localization : the "Everyone" user group doesn't exists on non-english Windows, it is localized and translated into the OS culture.
I'm not trying to localize my msi, I just want to retrieve the "Everyone" user group equivalent in other cultures.
Now I've seen quite a few posts that could help me with this, but most of them are really becoming old, and in regard to the best practices (again, you can check Stein Åsmul's answer on my previous thread), I couldn't find any solution that doesn't involve using custom actions, or scripts or defining the user value directly into the .wxs file.
I'm trying to avoid custom actions, but most other solutions seems kind of obscure or hardly maintainable to me at the moment.
I'd like to know if, as of today, there is a better way to get the localized "Everyone" user group to pass on to the util:User tag ?
And if not, what solution should I go for then?
EDIT:
In regard to Stein's comments:
Unfortunately for me, "Everyone" doesn't translate at all at runtime, whether the OS is localized or not. I mean "Everyone" works on the english version of Windows of course, but my primary targets are foreign versions, where it doesn't translate.
I also forgot to mention originally that I considered using the built-in WixQueryOsWellKnownSID, because I saw Rob Mensching suggested it as well, however I get the following error and haven't been able to get around that (same behavior for User and Administrator):
Failed to create user. (-2147022694 BUILTIN\Users)
I've seen this post that was followed up here, but couldn't come up with anything better.
I've also checked the comments from this link where they explain you shouldn't be using a merge module, but I'm not. Everything is in the .wxs file.
As of the SDDL string, I have read the whole thing but as far as I understand, you need to know the exact location of the folder beforehand to generate the proper SDDL ? I can't rely on this solution as the folder location is decided at runtime. Unless I got it wrong of course.
I need to create a custom installer that supports French, German, Spanish, Italian, Polish, Russian, English, chinese (mandarin script), more languages to be added for a .net based application.
This installer also needs to be able to check whether the target system has got adobe installed or not. If the target system doesnt have adobe or is a lower version than required then it should install from the CD. if it does then bypass that step.
The installer also needs to prompt the user to browse to any location on the system to pick up a file which will be place in the installation folder.
The installer also need to register this program in the add remove programs list.
Is there a custom installer that can do all of these tasks or do I need to build an application from scratch for it?
Thoughts... ideas???
Thanks for your time...
Short answer : Yes, all those things can be done, most of them easily.
WiX or NSIS are probably your two best free options. NSIS uses a plugin architecture for most of it's functionality, but the plugins are text-files, so you should have no problems downloading them. However, if your company is "funny" about licensing, then check the relevant licenses for each plugin early on - most are completely free to use, but Legal can fail to understand this sometimes...
Please find below pointers to the relevant sections of the documentation, so you can get it downloaded (I feel your pain by the way!)
Language Support
See Docs
Allow user to select a file and copy it
You will need the InstallOptions plugin. This allows you to create an extra page in your install wizard which can prompt for information. It allows various controls, one of which is a file explorer control (search for FileRequest in the link).
To copy the file, you cannot simply use the File instruction, as that extracts and copies files from the installation media, and will not act on files on the target computer.
Instead, you will need a plugin - e.g. this wrapper around the WinAPI. Alternatively, use the CopyFiles instruction.
Register program in Add/Remove programs
This is standard in both WiX and NSIS.
Detect Adobe is installed.
NSIS has the ability to check if registry keys exist, or named files exist, which are the two normal methods of detecting installed programs.
I would like to build a setup, or something like that (1 file), to deliver a single file to a target system. Plugin for an application, installable to users AppData folder.
After some research I'm still not sure in which direction to look. I can create the setup project with Visual Studio 2010, but all of the options so far seem to be way too heavy or have some flaws.
SetupProject stubbornly wants to create an application folder which I don't need, and complains about installation to user folder. Cab doesn't seem to offer automatic install, oneclick is not available for the project, etc.
Is there an easier setup technology I could use?
Requirements:
Install -> Copy 1 file to a folder
under %userprofile%\3rdpartyapp\ if
it exists (xcopy).
Uninstall -> Delete the file and also
one folder with custom settings
(rmdir \s).
Distribution -> Free for commercial
use.
Maybe I should just pack the file in self extracting c++ exe?
It may be overkill for one file, but I like InnoSetup for creating setup packages. Check it out, and see if it suits you. It is very easy to use and deploy.
Take a look at WiX toolset. It allows creating MSI-based installers, and the installer could be quite simple:
Search for %userprofile%\3rdpartyapp;
Copy the file into it, if it exists;
Fail install or maybe create it, if it does not exist.
Uninstall would be very simple: it would need to remove the installed file. To remove a subfolder of 3rdpartyapp, you can use RemoveFolderEx element.
MSI registers the installed app with Add/Remove Programs Control panel. Uninstall is handled by Windows Installer service, therefore you don't need to copy any additional files or programs to support uninstall.
I think any setup technology is too heavy for one file. I'd go with creating a simple application that would extract the file from its resources stream and copy it into %userprofile%\3rdpartyapp.
Uninstall is trickier: there should be something that can handle the uninstall process. It could be a batch or script (js, vbs) file stored somewhere in user's profile, another simple application or the same one. (Installation process can also be handled with a script.)
I am developing a package using Installshield 2008 Primer Edition and Project type is Installscript MSI project.
The problem I am facing is during installation I am installing some of the files to the following location C:\Program Files\Company\SystemFiles from this location I am copying and adding the set of files into System32 folder, it contains DLLs and OCX files, copying into the System32 folder has been done using Installscript.
Due to this during uninstallation, the installed file is getting removed from System32 due to this other dependent application which requires the same set of DLLs have stopped working.
I have approached Installscript to copy files from ProgramFiles to System32 Folder rather than using built-in options because we have an issue during the upgrade in order to avoid that I am using Installscript.
Even I have tried several workarounds like setting the file attributes after file copies to System32 using Installscript like FILE_ATTR_SYSTEM which sets the system attribute but still files are getting removed during uninstallation.
Any idea how to give file attributes as PERMANENT or SHARED; will this help, and if it will, then how can I set it using Installscript?
I have 2 ideas
1)I think you can use SHARED option as this wont remove the files while uninstallation.
2)Also when i was facing similar issue , what i did was putting all the required files in the installation directory itself so that while uninstalling only the installed files will be removed.(I know this is not a best solution)
(NOTE:I have worked on Install shield some 6 years back and so remember only certain things)
You can also disable logging from Install Script. This will make the installer "forget" that it installed specific files groups or features.
You should make sure to enable logging once again after you have copied the files that you want to permanently leave on the system.
If you don't remember to enable logging after you have disabled it, your uninstall process may not work correctly.
Syntax is as follows:
Disable(LOGGING);
//Add code to copy your permanent files here
Enable(LOGGING);
For InstallScript projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Uninstall" property in the right pane to a value of "No."
For MSI Projects:
To prevent the files in a particular Component from being removed during uninstall:
1-Select the Components view from within the Organization folder.
2-Select the component that contains the files you do not wish to remove during uninstall.
3-Change the "Permanent" property in the right pane to a value of "Yes".
I see this is an old question but I just came across this. Seems to be a common problem. One good solution is to stage the files to a private directory mostly program files and then have a custom action do the copy and register (ocx etc). Installshield remembers what it copied so it tends to remove them. Do not disturb anything else like logging (my recommendation). Set conditions on the custom action so that it doesn't run during Uninstall.
Although sometime back I did another weird implementation which only programmers are used to doing.. Packed the files as resources and created my own code to extract and deploy (Something that Process Explorer kind of tool does). There were certain use cases that warranted this kind of implementation. But again this is complicated and obviously reinventing the wheel. Unless you are good with C/C++ and Windows API this would be difficult. I would still suggest you stay away from this kind of implementation because it is also considered a "virulent behavior". Yet, so far I never got warnings from the Anti-malware products.
Using WiX (Windows Installer XML) I have created an MSI installer which installs Word templates into the users Application Data folder, e.g. on Windows XP
C:\Documents and Settings\<user>\Application Data\Microsoft\Templates
I'm retrieving the path to this folder from the registry:
<Property Id="APPDIR" Secure="yes">
<RegistrySearch Id="RegSearch_AppData"
Type="directory"
Key="Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"
Name="AppData"
Root="HKCU" />
</Property>
<CustomAction Id="ActionWordTemplateFolderAssign"
Property="TEMPLATEFOLDER"
Value="[APPDIR]Microsoft\Templates" />
<InstallExecuteSequence>
<Custom Action="ActionWordTemplateFolderAssign" Sequence="1" />
</InstallExecuteSequence>
However, some users installing the MSI file on Windows Vista receive an error because the APPDIR property is empty.
Is APPDIR not the correct way to retrieve the Application Data folder? Or do I have to consider another property on Vista?
EDIT: This is just a short version of the WiX Code to retrieve Word's template folder. First I'm actually checking whether the user has a custom template folder defined by a policy or under HKCU\Software\Microsoft\Office\12.0\Common\General\UserTemplates. However, if none of these are set the fallback is to use the default location under %APPDATA%\Microsoft\Templates which is retrieved by the above code.
You should use [AppDataFolder] instead. I can't find anything about "appdir" in the windows installer property reference.
Edit after question edit: The shell folders key (great blogpost btw) where you get your appdir value from is a very old and deprecated way to get at the system folders. It is only there for backwards compatibility and you should not rely on it. Especially if you live near Raymond Chen.
Edit 2: Since the real question turns out to be "how do I find the user's word template folder"... The word template folder is not always
[AppDataFolder]\Microsoft\Templates
This is because the template folder can be configured under tools - options - file locations - user templates. Ironically we are back to searching the registry if we want to detect this:
<Property Id="USERTEMPLATES">
<RegistrySearch Id="SearchUserTemplates"
Root="HKCU"
Key="Software\Microsoft\Office\11.0\Common\General"
Name="UserTemplates"
Type="raw" />
</Property>
This registry value is normally not present however, and you cannot specify a default value that contains [AppDataFolder] here (I tried).
Instead, I would try to define two components, one which installs to USERTEMPLATES and one which installs to [AppData]\Microsoft\Templates. You can then make use of Condition elements to test for the existence of USERTEMPLATES, and install only the right one.
Some additional information:
The reference for MSI properties containing special folders:
http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx#system_folder_properties
And a link to a related blog post:
What is the WiX equivilent of Environment.SpecialFolder.ApplicationData from .NET?
Divo - In response to your comment on localized Vista installations, the problem probably isn't so much localized Vista (unless I'm reading you wrong) but localized Office.
Microsoft\Templates might become Microsoft\Vorlagen with German office for example. It's a pain in the ass, because I haven't found a reliable source of documentation on what folder names have been localized in Office, and what haven't.
My particular problem was with installing Macros to [AppDataFolder]Microsft\Word\STARTUP - which is localized for some languages only. #$%# in the end we just get customers to manually move the templates, the majority of our markets don't have a problem but we've noticed Italian and Turkish office plus a couple of others seems to exhibit this rather annoying behaviour.
On Vista there is a new standard folder available called TemplateFolder. I think that is what you want. To use it in WiX just do something like:
<DirectoryRef Id="TARGETDIR">
<Directory Id="TemplateFolder" Name="Templates"/>
</DirectoryRef>
Then you can reference the TemplateFolder Directory where ever you may need it.