February 3, 201312 yr Hello, I am going crazy with packaging runtimes on my mac. Whenever I create a Runtime, the FMStrs.dls files located inside the Runtime.app -> Contents -> Resources -> Language folders are locked. I can easily unlock them, but it relocks them every time I package the runtime. They are not locked in the default Runtime folder. So I don't know why these are locked. Any ideas? Thanks, Stephen
February 3, 201312 yr I noticed this myself a few years ago (FM9?), and I don't know why. In the runtimes I've produced I built the basic files (actually a single file was sufficient for me), but retained the fp7 file extension so I could continue to develop the solution using FMPA without rebuilding the runtime. So, there's a clue as to how you might also issue updates to clients without issuing the runtime. If your clients want to upgrade to full FMP then let them and the transition will be so much easier. On the above basis you only need to build the runtime once, so you can fix the locked file then.
February 4, 201312 yr Author I do change the default name to a different extension. What I have been doing is keeping a copy on hand of the .app that is created with the runtime and copy this over the newly created one which always locks the FMStrs.dls files. I wish I could figure out was is actually causing this.
February 4, 201312 yr You don't need to continually rebuild the runtime. Once the runtime is built, and provided you don't add or remove any files from the solution then the runtime will work. You only need to substitute the data files. Beware if you are using 'remove admin' in the runtime builder though! Hence, I suggested use the native FM extension (.fmp12) so you can continue to develop the data files without needing to rebuild the runtime. If you use the default .USR extension then you cannot use these within FMPA. I still can't tell you why the FMStrs.dll gets locked, maybe there's infinite wisdom being used by FMI?
Create an account or sign in to comment