In case anyone else also is wrestling with this, I found this helpful thread from last year:
Since vista was released and we experienced the same issues, we found the best way to combat it was to install our solution into the root of drive c...
The installer we use (inno setup) lets us add read / write permissions to the files.
So far, there have been very few issues with this over the years.
Thank you, SWS. Further research on other forums turned up some more helpful discussion supporting what you said.
Incidentally, it seems that the same issue applies to OS X -- i.e., installing the entire runtime in Applications is not considered good practice. But at least it launches.
Sounds like we will be revamping the install routines for both platforms :(
Looks like I have to research the mac side of it myself, I wasnt aware mac had issues also :-(
Im getting ready to deploy my first mac solution over the next week...
FWIW, I don't know that it is a specific problem on OS X. My comment that "the same issue applies" was based upon the final post in this thread:
The poster sounds knowledgeable, and I believe that the statement was made with respect to best practice, not functionality.
My own experience is that a .dmg containing the runtime and all associated files -- when opened and dragged to the Applications folder -- installs fine. The program launches and runs okay.
Still, I plan to make necessary changes so that it installs the "right way".
Hmm. The more I read, the more I wonder whether or not this really is a concern under OS X. Can any gurus here offer perspective on the advisability (or folly) of dragging an entire runtime folder into Applications?
I've been experimenting with this a little today and have not come across any issues myself... but that does not mean there aren't any...
On windows, it was apparent from the word go... even once you get the runtime working properly, if you later try to update the database files (or replace them) it quickly becomes apparent that your new files are not being used / seen.. Instead the files from virtual store are being used.
So far under OSX Ive not come across anything to suggest there will be an issue
On that note however, it would be good if we could do it 'properly' or at least the way the OS wants us to.
But for this to happen FileMaker would need to allow us to specify a path to the data files, plus a way to modify this path, either with a .ini file or similar approach...
The way file associations are on windows (a nightmare) you cannot trust that the correct runtime executable will launch when opening a database file, besides, we are not talking microsoft word here.. we want people to open the application (solution), not the individual documents (database files).
Overall it would be more beneficial to give the executable the ability to locate the database files, rather than leaving it up to the database file to locate the executable. To save issues with backward compatibility, If no 'custom' path was specified, it would simply look in the local folder...
I guess I will go and post it as a feature request to FMI
One more thought after digging a little further:
Apple's own guidance on software installation does not really include any cautions against installing everything under Applications. In fact it says, "The Applications folder is generally the best place to install software":
[Note, though, that this was last updated November 2008 and is indicated as applicable to OS X 10.4 and 10.5 -- I could not find similar guidance specific to Snow Leopard.]
Also, in checking my own MBP with Snow Leopard installed, I find that even the "heavy hitters" like Adobe's Creative Suite and FMP 10 Advanced install the whole shebang -- icons, images, txt files, sample html pages, sample .fp7 files, etc. -- in the Applications folder or subfolders.
So, at this point my conclusion is:
- Windows runtime installation into C:\MyApplication
- OS X runtime installation in the Applications folder, with the data file in a subfolder if possible
Still, I would welcome any perspective from others with more experience or insight into this question.