I'm writing an InnoSetup script to deploy software to a user's machine (default c:/programfiles) but I also want the user to be able to navigate to, say, a portable flash drive as well (like on a second page) and then have the installer load files to the HDD (programfiles) and then have it load files onto their selected flash drive - is this possible? How would I go about executing it?
thanks :)
I am not quite sure what you are trying to do but it sounds possible to me.
As you stated you could do this with a second page where you allow the user to select a drive or a directory where some files are.
You can then iterate over all files and install them into the selected program directory you chose in the setup before.
For more information it would be good if you could provide more information but so far this is the best answer i can give you for the provided information.
Maybe this helps you along when listing up all files in a directory:
Inno Setup: list all file names in an directory
And with this you can copy them:
Inno setup filecopy
And if you want a FolderBrowser use this:
Pascal Scripting: BrowseForFolder
Related
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
I would like to create an installer of my program.
However because the installation is quite complicated, I need something more advanced than installshield limited edition.
I have to run another installer from my current one. It doesn't matter if the user press "cancel" or installs the program, I just need to run it.
I have to install a directory structure on user computer which has a lot of files, that's why i'm going mad with wix: 100 files and I should write all of them with my hands in that xml file? Are we mad?
I have to install files from point 2 into a registry key. That's why I was using wix
I played with nsis long time ago and I liked it, but the language is not so nice.
Wix has "similar" problem. I would love using something like C# and things like that otherwise I'll stick with wix but I need a way to add files faster to xml file, can't add 100 files manually.
Any suggestion?
You can give Advanced Installer a try. It has folder synchronization, which means it can batch add contents of folders, with the possibility to filter out certain file name patterns, for example you'd want to filter *.pdb files and add all the rest to the project automatically.
I use it myself and never had a problem.
Wix Heat can generate the wxs source files for you.
You should look at InnoSetup. It has an IDE available that allows drag and drop of files (and multiple select in a file selection dialog), can launch other applications (including additional setup files), create and modify registry settings, and supports pretty complex scripting if needed. It's pretty easy to use, and the documentation is pretty good. It comes with pretty comprehensive sample installations, too.
The installation scripts are created by the IDE and then compiled into an installer, so the script source is editable by hand if needed. It's also not XML, but more like an INI file, so it's a little easier to work with manually as well.
Best of all it's free, and so is the IDE.
I would go back to using NSIS, if you use the HMNSIS editor http://hmne.sourceforge.net/ to write your scripts you can use the Wizard mode to make a list of the files and directory structure you will use in your installer.
Running other installers and registry settings are also easily done with NSIS.
we are making an Application for OS X, however, when the .app is copied on another MAC, we have problems with reading and writing files
on one MAC, everything works great from the start...
the other one will not write certain files and another 2mac will not write certain different files
if i go to show application contents and wants to edit the file by myself, i get a writing permission denied
how to distribute an MAC application so there are no such issues? so all files can be read and write by the current user
does there have to be some authorization or code sign, or smth. different in this form, in addition to normal code?
thank you
It sounds like your application tries to write files within its own application bundle. The correct solution here is: DON'T DO THAT! The only time your application bundle should be written to is when it's installed or updated.
Files that the application needs to write to should be stored in the user's home folder, generally under ~/Library. See this note in Apple's dev docs.
Preference and settings files in ~/Library/Preferences/<appbundleid>.plist; use NSUserDefaults.
Data the app manages for the user in ~/Library/Application Support/<appname> (the docs say to use the bundleid, but everyone -- Apple included -- uses the app name instead).
Cache files in ~/Library/Caches/<appbundleid>.
Temp files, use NSTemporaryDirectory
If you need to share settings & files between users, that should generally go in /Library/Application Support/<appname>, except that you really shouldn't be doing that at all.
In the past I've always used PackageMaker to create installers. An installation package can authenticate with root privileges so you can set permissions after the install. I don't have it in front of me right now but if you look around you should be able to see a Post-Installer script line. Write a shell script that manually sets the permissions of each file you have in question and then have the package execute that script after the install is finished.
You can find PackageMaker at /Developer/Applications/Utilities/PackageMaker
Currently, I'm developing a system which will extract some files from an SFX archive (files that will be used for another app). I want to make the extracted files hidden, so the person which has find the location of the exe couldn't get the files which will be in same directory with the exe. I know i can apply attrib +h to the files but if the user turns on "show hidden and system files" option in Windows, the files will be visible.
Isn't there any method to overcome this? Any suggestion is welcomed.
Thanks.
If you're writing to the disk, a user can find and read your file. There's no way around that, one could monitor what happens when your application is run, find what files it's writing to, or just intercept while it's being written. Consider why you don't want the user to find your files.
Is it because there's sensitive data, or things you'd rather they didn't change? Consider encrypting it, or verifying it's integrity with a checksum or hash.
Guess you could play around with user rights. However, you'd need to ask an administrator right at install then to make it hidden from the given user who is an admin on the PC.
My installer requires there be two files in the same directory in order for it to install.
The installer (.msi file)
An organization specific config file that the installer copies. (This file is customized by the organization and then distributed to it's end users).
Since there are two files, the file has to be distributed as a zip file. Which presents the issue of if a user tries running the .msi without actually extracting the zip... only the msi file gets extracted. I am able to detect the issue in the install process and tell the user they need to unzip the file... but you know how noone actually reads error messages.
So, I'd like to make it more foolproof and so i was wondering if there was a simple tool that i could let my customers (ie the organization) be able to make modifications to the config file and when finished create a .exe file which when clicked would extract to a temp folder and then run the msi. I know there are solutions for this which require commercial software. I'm wondering if a simple freeware tool exists that can do this.
Edit: Accepted Solution Notes:
The one issue i ran into is the iexpress wasn't designed to be used for .msi files. As a result on the step that asks you for the Install Program. It's a combo box which if you had added a .exe file in the previous step could just select the .exe file from. Instead you have to manually type in
msiexec /i yourinstaller.msi
I was very pleased to find such a simple solution that's built in to windows. The only way this could be better is if it allowed for wildcards so that your iexpress project would be able to handle changes in the msi file's name which occur with each version. And defaulting the Install Program to the .msi file. These minor inconveniences are offset by the fact that end user wouldn't need to install any new software to create the package so I have stopped looking for other tools.
You could try using iexpress.
It enables you to package up a set of files which can be extracted, with the option of running an installation command automatically after extraction. It also has options to enable you to prompt users about things, show a EULA, restart the computer, etc..
I believe it comes as part of Windows (part of IE?) - try running iexpress.exe from the run dialog to get the UI.
The Wix project has a bootstrapper and packager for dealing with this kind of thing.
I've used wix a lot but haven't really looked at the bootstrapper/packager much - last time I had a quick look it wasn't really usable but that was a long time ago so it may be better now.
I'm guessing that the config file is something like a properties file, and that you want users to set the values of the properties "foo" and "bar". You don't need a separate tool to update the file.
I would do this:
Put one or more dialogs in the install that ask the user what the values of foo and bar should be, and set a couple public properties accordingly.
Write a custom action that writes the config file out to whatever location you want, including whatever values you want for foo and bar. This would be pretty easy in vbscript.
Put the custom action somewhere in the execute sequence (ideally as a deferred execution action, since you're making changes to the system).
Add an entry to the RemoveFile table, so the config file is removed on uninstall (assuming you don't want it to be left behind.)
Add an entry to the LaunchCondition table, to prevent users from doing a silent install. Or if you want silent install to be allowed, make the names of the public properties that hold the config data known, and make them part of the LaunchCondition. You would block "msiexec /i myapp.msi", but you could choose to allow "msiexec /i myapp.msi FOO=Something BAR=SomethingElse".