I have an application to be distributed.
Pretty much everything is self-contained within one bundle so I could just put the bundle in a DMG for the first version-- however this won't work for upgrades, so I figured I'd best work out the process ahead of time.
I've been looking at PackageMaker and it seems straightforward enough. However I have a couple of very specific requirements which may cause problems, and it wasn't apparent from reading the PM docs as to whether this is even possible:
First of all, I want the installer to automatically choose between installing two different versions of the app, depending upon whether a previous version of the application has previously been installed.
Secondly, I don't want to just overwrite the previous application's bundle, I just want the installer to overwrite files within it and add new ones -- in other words, I want certain files within the application bundle to remain from the previous version.
Is this something I could achieve with PackageMaker, or should I look for a different approach?
You can do a lot with an installer package, for example run a shell script which in turn allows you to do everything.
I get the feeling that you're doing it not the Mac way. It's uncommon to store data in the application bundle, normally such stuff goes to ~/Library/Application Support/. I presume that those two different applications are quite similar, why not just set a preference?
Personally, I feel that today a .zip is the best way to distribute your apps. It gets automatically decompressed and shows up with your application icon in the downloads stack. (Only if you get it from the internet, of course.)
For updating look at the sparkle framework. The forst install is just copy the application bundle from the internet and te user then just asks to do update and does not have to leave your application to do anything
Related
I have developed a Firemonkey app for Windows and OSX. I have also developed an Apple Help Book containing the help for my application when it is run on OSX. (I have a different help system when running in Windows.) Apple's recommended location for the help bundle is in the app's Contents/Resources folder. I can copy the help bundle there manually but it gets deleted every time I run my app in the IDE or deploy my app.
I thought about trying to use the deployment manager but this only allows files to be deployed, not bundles. The help bundle contains a large number of files spread amongst various folders and it would be tedious to set each file up individually in the deployment manager. Moreover, I would have to change the setup every time I added or deleted a page from help since each page is a separate HTML file in the bundle.
So for now, I am manually pasting the help bundle into Contents/Resources. Does anyone know of a more efficient method to incorporate the help bundle?
After much research, I came to the conclusion that the only reasonable way to incorporate an Apple helpbook is to paste its bundle into the app bundle at the location Contents/Resources. I thought about locating it elsewhere but Contents/Resources is where Apple recommends it should go. This is inconvenient because it gets erased whenever I redeploy the app or run it from the IDE. But until Firemonkey is enhanced to make provision for helpbooks, this seems to be the only acceptable way to do it. The program 'Packages' http://s.sudre.free.fr/Software/Packages/about.html is then a great way to package the app for issue to customers.
This issue has been discussed several times on Stackoverfl0w, but unfortunately I did not see any really satisfying solution.
The situation:
(Only included because most previous answers went with the line of "Just dont do it! There is no reason to have multiple version of an application.. etc.", which I agree with for most cases, but not this one.)
We are currently shipping a .pkg file that installs our software package to /Applications/$CompanyName/$SoftwareName_$VersionNumber .
Including the Version number in the folder's name and not deleting older versions is necessary since many of our customers use our current release and beta version in parallel, and, furthermore, many customers work with an older version software because they certified it for a specific use case, but they use a current version for current projects.
We used to ship only command line tools and libraries for macOS, therefore it worked totally fine for us over many years.
However, we started porting our GUI applications from Windows only to Windows / macOS / Linux, which are shipped in the .app format under macOS.
The issue:
If an .app is shipped within a .pkg installer, the installer searches the hole disk for old instances of the same .app .
If it finds one, it replaces the instance it found (very bad) and also does not place the .app in the specified installation dir (also bad).
Solutions I found:
a) Changing the CFBundleIdentifier of the .app for every released version. Seems not like a clean way to me. I assume it will also cause the .app to appear multiple times in the Launchpad
b) Searching all instances of the .app before the installer does it, zipping them, and extracting them again after the installation. (Also does not sound like a good solution.)
Does someone have a clean way for this?
Can not believe that Apple does not have a way of specifying that this behavior should be omitted during the creating of the .pkg.
Is there better documentation then the one I found?:
https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.html#//apple_ref/doc/uid/TP40005370-CH100-SW15
http://s.sudre.free.fr/Stuff/Ivanhoe/FLAT.html (Good documentation, but after ~8 years of uptime, a lot of the fields are still labeled with "Description Forthcoming.")
EDIT:
Added XCode as a Tag.
Bumping after earning the tumbleweed with this question.
Would appreciate any suggestion :)
The "relocate" property in the distribution file seems to control this. Unfortunately, it appears you can only enable "relocation" by adding this key, but not disable it by omitting the key. According to Apple's Distribution XML documentation, the default for .app bundles is "relocate".
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I want to create a simple autoupdate that downloads the new version of my software (in a temp folder), runs the installer (I'm using Innosetup) which will take care of closing my application and then, after the setup is complete, I would like to remove the installer file.
What's the best approach to do that?
I saw there are a number of libraries that take care of everything but I have written almost all the code used to check for updates and I'd just need to be able to run the installer.
Thanks a lot.
You can use the NAppUpdate framework to achieve that quite easily.
Check this out: http://www.sjurvarhaug.com/nappupdate-to-automatically-download-and-execute-installer
I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.
Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.
Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.
Issues that need to be respected or clarified;
Manual build of a single brand via Idiot-Proof GUI (choose a git
branch/tag, specify a certain brand, configure the app e.g.
IAP-enabled, server-domainname, etc - will be written to the
info.plist)
In previous manual tests, setting the executable name in
the plist didn't work? Sorry, have forgotten the exact problem..
perhaps was only an Xcode Debug buildconfig problem, not relevant to
a distribution build?
Code-Signing?!? Can the profile be specified
on-the-fly? Some brands need to be built with the customer's own
profile.
My personal feeling: Hudson or CruiseControl + Xcode plugin.
There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?
And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.
So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?
Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).
IMHO you can resolve all issues using different targets of XCode.
Every target will share the code but it could:
be signing with diferent profiles
use diferent plist: this implies having different names..
use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
Build with one click in XCode.
I hope this helps
An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.
See this script as a starting point: https://gist.github.com/catmac/1682965
Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.