I have a setup file for a particular application. When I run this file it automatically creates a folder in my C/: drive without consulting me and installs some stuff in there. Then it installs the rest of the stuff in Programfilesx86 folder in C/: drive. It is really frustrating that I have no control in deciding these parameters.
I managed to open the setup file using Winrar and there were six folders in there numbered from 'disk 1' to 'disk 6'. In 'disk 1' there are a couple of setup files which when run skip the first part of the setup (in which a folder is created in the C/: drive) and starts installing stuff in Programfilesx86.
There are also some other stuff in that folder which I tried to open with Notepad such as setup.lid, setup.ins and dll and bin files. Some of them looked sensible when opened, but some contained a lot of funny looking and meaningless characters (at least to me).
If you want something for testing (i.e. the software of interest), try downloading the Motec ECU manager from their website for free.
Any help or hints are appreciated.
Related
I have installed a window application on a machine. When i run exe file and try to read value from config file, it gives different results for different users.
What I have identified:
config file is saved in user's folder not in the application folder in program files.
it pickup setting for different users from local folder :
C:\Users\myUser\AppData\Local\VirtualStore\Program Files (x86)\Parentfolder\ApplicationName
It seems to me that the application was designed to INTENTIONALLY use the users AppData folder to store its settings. It's generally a bad idea to mess with how a program was designed to operate.
HOWEVER, if you have the ability to run a different program that can do file syncing between different machines on the network, you can certainly do something like make a single copy of the config file and put it into a folder somewhere on the network - preferably on a file server, then use a file syncing program and set it up to take that one file and copy it out to each users workstation and drop it into that AppData folder.
Then, you would only need to make a change to that one file and the file sync software will see that it was changed, then it will copy the new file out to the users' workstations.
Here is a link to a site that reviews a bunch of different Windows programs that do file synchronization ... there are probably thousands of options out there ... just google around and find something that works for you in your environment.
By the way, if you go this route, I would make sure that any time you change the config file so that it copies out to the user's workstations, that the users shut down the program until the file has been copied to their workstation. It's possible that the software could have open locks on the file or that changing it while the software is running might piss it off ... so it's just good measure to shut the programs down, then sync the file then have them launch the program again.
I have a fairly large application (~750k LOC) that I distribute using the Package and Deployment Wizard. I fully understand that it would be nice to migrate to .NET (that ain't happening - see the code size above), and that the PDW is deeply flawed. However, for the most part I've made it work well for my end users, by customizing the Setup1 application, writing a menu-driven wrapper for the Setup application, and by running it in silent mode. (Note that the problem I'm about to describe occurred even before I started using silent mode.)
The issue I'm having is that my application requires quite a few auxiliary files, which I've added to the PDW project in the "Included files" section. When a user does a clean installation (either from scratch, or after un-installing a previous installation), everything works fine. However, if they simply run the installer to update the existing installation, the executable file and any OCXs I've updated get copied over the previous versions just fine, but my auxiliary files don't - I have to have the user manually delete them, and then the Setup1 program will re-install them as it should.
I've checked in the Setup.lst file, and all of the files are listed there, with their current date stamps. In fact, in my "BuildAll.bat" file, I do the Windows equivalent of a "touch" (copy /b "TheFile.dat" +,,) to force the date stamp to be current. However, if the file exists on the target machine, it won't be over-written even though it's older. There are no errors reported, either visibly or in the .LOG file (which is required if using the silent option).
A couple of additional points: Some of the auxiliary files are themselves VB6 applications - just the .exe files. Those do get copied correctly if they're newer than the existing files. Other than being files with internal versioning information, there's no difference between them and the other auxiliary files (which are things like media files, or text-based .txt or .dat files).
So, what's going on, and how do I fix it (besides moving to Inno or some other solution that won't work for me...)? Thanks in advance for any help!
~~
Mark Moulding
We market an application that runs on multiple platforms, including Macintosh. On the Macintosh the software gets packaged into a .dmg file, and when installed everything goes into the /Applications hierarchy.
Some of the files in our application's hierarchy are samples that users are supposed to be able to modify in place or copy to different files in the same directory. The problem is the permissions that seem to get applied within the /Applications hierarchy prevent our application from doing such operations.
So I either need to change the install so the directories and files in question within /Applications allow modification, or I need to segregate the sample files to a different location on the disk where they can be modified.
I've tried making sure the permissions on the files allow writing at the time the .dmg file is pulled together, but then when the product is installed the permissions get changed to more restrictive ones that don't allow file modification or copying.
I've been able to modify the packaging so the sample files get installed to a different location, but so far I haven't been able to find a suitable area on the Macintosh disk to put them so modification is allowed. I haven't been able to figure out how to tell the packaging that these sample files should be installed into the installer's home directory.
Anyone have any suggestions? I'm afraid I'm a bit of an Apple novice. The procedure to build the .dmg file employs a Makefile that invokes commands like pkgbuild and productbuild. The productbuild command uses a --distribution qualifier that references a .xml file. There don't seem to be any scripts invoked.
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
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.