I have a small software for MacOS with a simple dmg installer (Open, drag and drop to Application folder, you know). My problem is, that the software writes a small ini file inside the .app package and if I update the software, this file is lost, because the old package is removed before writing the new one.
My question is, if any of you know an elegant solution for this. The user should be able to save the file in any place e. g. desktop and the ini file should be moved into the new package. I don't want to save this file outside the .app package, because this would leave private data on the computer if the user just removes the package.
Thanks in advance!
Saving data into the aplication bundle is no good practice,
for future release, please implement another solution.
To solve the current problem, I can think of two solutions:
Add two files to the .dmg file
The new application.
Backuptool: An simple AppleScript to backup the file would do the job.
Make sure to notify the user to run the backup before replacing the application.
The user might however forget to run the backup, and loose data.
Create an installer
Another option would be to write an installer using PackageMaker.
PackageMaker provides options to run scripts before updating the Application.
Add an pre-installation script that backups the data.
Related
I’m writing an application that should save user specific data into AppData. This application has an installer. Now I’m not sure, what is the best way to provide the folders in AppData.
Should the installer create (and delete) the folders, or should the application itself create (but probably never delete) the folders.
Also, if multiple user on the same computer use the app, the folders probably doesn’t exist, if another user installed the application.
I didn’t found anything that really explained this to me.
Thanks in advance.
I'll answer for Windows Installer, MSI files, and basically you shouldn't need to worry about it in the installer; just install files to their required locations, and the folder will be created automatically and removed at uninstall if it's empty.
In addition to Phil's correct answer:
If the files from the AppData folders used by your application are created only by the application, at run time, there is no need to configure the installer to create the empty folders. Those folders will be created the moment your app writes down the files.
Also, even if your installer is creating the folder, on uninstall it will not remove if in that folder are files created by the application. Windows Installer keeps track (should do it in a correctly configured package) of every file it installs and only removes the ones it installed (by default, it can be configured to force remove a folder and files which it did not install).
Regarding other users of the app. In this scenario, the simplest method is to use your application for creating the initial default files in the AppData folder, at the first launch of the app for each user.
If you need to install files to AppData from your installer then you could try one of the following approaches. These techniques can be applied with any setup authoring tool that can create MSI packages.
Some time ago, we distributed a toolbox to our users via the MATLAB App Packager, to make it easier to provide future updates, without users having to handle search paths. Now, we wish to distribute an updated version. Usually, re-packaging the toolbox should make a new .mlappinstall file, which asks the user to upgrade. Instead, MATLAB now considers the new version of the app as a unique new app, and installs it again rather than upgrading. Thus, the user will then have the app twice in the Apps pane, one in an outdated version, and one in the new version.
We have been unable to find an explanation for this in the MATLAB documentation nor online. When we install the updated app (so that both versions are present in the Apps pane), further changing it will upgrade it as expected, so unfortunately, we cannot provide a minimal working example, as we cannot reproduce the issue.
The question is this: How does MATLAB establish app uniqueness? The app name and author fields are identical to the original values, and the version number is incremented, so why might MATLAB not recognize that the app is already installed?
When you had that discontinuity, were you re-packaging using the original .prj file by clicking on it in the file browser in Matlab, or did you run "Package App" again and fill in the same properties?
I think the thing that determines the unique identity of the app is a GUID that is generated behind the scenes by the "Package App" wizard. If you open an existing .prj in the Matlab GUI, it re-uses that GUID. If you run "Package App" again you'll get a fresh GUID regardless of what you put in for the various developer-visible app properties.
You can dig around in the .prj and .mlappinstall files to see this yourself. (I couldn't find it documented anywhere either; I just poked around the files and did some trial and error.) The .prj is just XML, and the .mlappinstall file is a zip file with an "Open Packaging Convention" layout. In the .prj, there's a param.guid element containing the GUID. In the .mlappinstall, its in metadata/appProperties.xml in a GUID element.
If you end up with the same problem again, make sure to re-package using the existing .prj file. Or if you don't have it, once you create your new .prj file, dig the old GUID out of the metadata/appProperties.xml from the old .mlappinstall file and copy it in to your new .prj file and I think it'll behave as the "same" app. This will even let you change the name and contact info for your app, and it'll still install on top of older versions.
We ship a config file as a part of our installation that we create via install4j. Suppose the user is doing an upgrade installation when we ship a new version of the product. Is there any way to determine if the user has manually modified the file after last installation ??
We need to detect if the user has modified this file, and then merge the changes that the user has done with the new changes that we are introducing by the update.
Any pointers / ideas would be greatly appreciated.
TIA
As of 5.1.11, install4j does not support this kind of content-based modification detection. Modification detection only takes file modification times into account.
Windows installer compares a file's create and modify dates. If they are different the file has changed.
I believe you can solve this in a better way by writing the config file using the main application executable using "internal defaults" in your application instead of a base config file delivered via your setup. You can then re-apply all internal defaults to the existing file, add any new updates whilst keeping user changes where possible (sometimes you want to override what has been changed?).
The more intelligent an application is in its configuration and maintenance of settings, the less deployment problems you will see.
I'm writing a modification for Arduino that turns an Arduino board into a game controller.
In order to add my board-specific files to the programming environment, right now, the user needs to open up the Arduino.app package, and then add a few different files into a various folders in the Arduino.app package. It is hardly user friendly. How can I make an installer which automatically moves my files into the appropriate locations within Arduino.app, or is that impossible?
You can download PackageMaker (available here, in the Auxiliary Tools for Xcode download).
You will then be able to make a .pkg that the user will be able to install simply by double clicking. You can also make a script that will check if Arduino is already installed and stop the installation if it's not. You get the idea.
Normally, especially in today's code-signed MacOS app approach (where any modifications to the app or its resources/files would break the app & make it not-launchable), I would say "you're out of luck".
But Arduino is one of the rare OPEN SOURCE apps.
You can fetch the source code from this page:
http://arduino.cc/en/Main/Software
And make your modifications to the project and then build a fresh, customized copy for yourself.
I figured out how to do it using the magic of scripting!
You can take a look at my solution here:
http://code.google.com/p/unojoy/source/browse/#hg%2FLeoJoy%2FLeoJoy%20Installer.app%2FContents%2FMacOS
The folder structure it's in makes it show up as an app on OSX, and the two scripts (LeoJoy Installer and LeoJoyInstaller.command) copy the files. There's two scripts there because I wanted to have a console window pop up to show the user progress, and that's the only way I could figure out how to do that. But, if you run this app in the same directory as the Arduino app, it copies files from the installer app into the Arduino.app package, updating the Arduino app so I don't have to distribute a whole separate version of Arduino.
So I am continuing testing and releasing changes to my app and I have come across a pain point that I am unsure how to deal with.
First off, my app uses a SQL Server CE database to store information and I need to be able to make changes to this db so I've created an internally updating process that runs whenever the application runs to make sure the db is up to date.
The crux of this internal update process is another SDF file named DBUpdates.sdf that contains all of the db schema changes that need to be applied.
The problem I am having is that the MSI distribution I created will not overwrite this file. It appears that when SQL Server CE opens this file, it changes the Modified date/time of the file. This is a flag to the MSI process that the file has changed, and that it shouldn't overwrite the file. Well now I am seeing that my db changes aren't being applied, because the MSI process thinks the user has changed this file.
At this point I am kind of stumped. I was planning on using an MSI distribution but maybe I can't. What do you think?
What about storing your .sdf as an embedded resource in your executable, and then extracting it to a temporary location on disk (as necessary) and perform the updates.
Unversioned files with MSI can be a bit difficult to handle if you need to force the installation of the file. You can see this previous question, for some ideas, How to add a version number to an Access file in a .msi.
The question contains a link to this blog post, http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx, which suggests the way I prefer to deal with this problem. Add the .sdf file to be part of your executable's component. The downside to this is if someone delete the .sdf file, but not your executable I don't think a repair of the application will catch this. If your using Visual Studio to create your MSI files then this may prove a difficult solution to implement. I strongly suggest your check out WIX in that case. It is a better MSI build system.