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.
Related
Get a Unity project with a native low-level plugin .. Mac version.
Make a small change in the Xcode plugin project, and build.
You now have the new plugin library in the Unity project.
If you "Build" again, the final Mac app of course now contains the new library - no problem.
However .....
if you hit Play in the Editor,
it does not pick up the change in the library.
In fact it seems:
Every time you change a library in Unity, you must restart Unity!
Everything has been tried, "Reimport all assets", AssetDatabase.Refresh, renaming, etc etc. It seems you literally must restart Unity.
What's the deal on this?
More information on this:
It would seem that mac shared libraries/bundles cannot be unloaded. Article:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm
Apparently this was fixed in 10.5:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlclose.3.html
Maybe Unity could solve this now. At their usual pace it should happen anytime around 2035.
Sadly it comes down to you can't do anything about it.
As per .net's DLL handling DLL's cannot be unloaded individually without closing the application domain. And while Unity picks up the changes done to the DLL the old version is kept in memory and used at runtime in the editor. A "funny" thing you can do to see this in action is by deleting the native plugin from within the editor. Confirm that you want to delete the file. The file will dissapear from the inspector. However if you right click the folder and refresh (ctrl+r) you will see that the file gets reconstructed (this also happens when hitting "re-import all", as the application domain isn't closed, despite unity restarting).
When building the application it will however use the locally stored file, and not the memory stored file. Hence the plugin being updated on the build.
There is no way to unload an individual assembly without unloading all of the application domains that contain it. Even if the assembly goes out of scope, the actual assembly file will remain loaded until all application domains that contain it are unloaded.
source
This has been a problem for some time now, and people have made attempts for work arounds and/or fixes, but as far as I am aware the "work arounds" that exist now are for windows only. here are some links to discussions about it.
"Unload a plugin"
"Reloading native plugins"
I suppose something that could be done is writing a wrapper that automatically restarts Unity when the dll has been edited... Although this won't solve the issue it'll atleast make it somewhat less of a hassle.
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.
This should be pretty simple, but I can't seem to get it. I have a setup project (VS2010) that packages a few dozen image files (along with my SQLite file) and copies them to the user's computer when the program is installed. As these are essentially "stock" images, it's ok if the user deletes them (there is functionality to do so from within the program.) However, after one or more of these images have been deleted, the next time the program starts it gives a "Windows installer" dialog box, and deletes all of the remaining data files!
What I think is happening is the program sees the missing files, assumes the installation has been corrupted, and tries to go into some kind of recovery/uninstall mode. I'd like to know how to indicate in the setup project that the files need to be installed, but may be removed by the user at any time.
I have tried several combinations of File properties, and nothing seems to do quite what I want, which is for my installer to put them where I say and never think about them again. Do I have to reinvent the wheel and do this through a custom action??
EDIT: Transitive and Vital had both been set to True. Setting them to False causes the program to re-add the deleted images back after it has been restarted! I'll probably go with a custom action if I don't get an answer.
When using a file association or advertised shortcut Windows Installer automatically checks if component key paths are missing. If a key path is not found, a repair is trigger to reinstall the component.
Most likely your installer repair process does something that removes the other files.
A solution is to not register your components with Windows Installer. This is done by using a null component GUID and it's not supported by Visual Studio setup projects (it is however supported by most of the other setup tools).
Another solution is to make sure that your image files are not key paths in their components. This is also not supported by Visual Studio.
If you want to use a setup authoring tool which offers more control, you can take a look at this list: http://en.wikipedia.org/wiki/List_of_installation_software
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.
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