Ok, I will stop talking now as its clear that Mac OS X works very differently from Windows in this particular context. Anyway hope that whatever solution the developer comes up with will please all Mac users! 
While the second half is a nice thought, I don’t see it happening and it seems too much to ask from this project.
As I’ve come to realize, this issue really only affects the users of the free Desktop Edition. The Cloud Edition is already multi-platform by means of being a web app. For the Server Edition, having to install/update prerequisites is not unheard of for server admins.
We have already been given a full featured and well supported accounting program at no cost, yet there will be costs to using Xamarin Studio and for developer accounts to list on the stores.
As it currently stands, Mono is built into the Manager Desktop app for Mac, not installed system wide.
Apart from the user data saved in “~/.local/” as opposed to Application Support, Manager Desktop does function as a standard Mac app.
Quick off-topic: @lubos: I imagine it would be a really quick change to have user data saved in Application Support instead. Make AppSupport the default location, if the files don’t exist there then check if anything exists in .local, if yes then move to AppSupport, if not create a new file. Unless “~/.local” is used intentionally to keep linux and mac code base the same.
From today, it’s now free. Five concurrent developers can use it in businesses with less than A$1.5 million in revenue.
The Mac Manager app is already signed using a paid Mac developer account. There are no extra costs for the app stores.
I disagree. Four out of the five items are free to implement, and take less than 5 minutes work in Xamarin Studio. All builds of Manager would benefit. The project would be easier to maintain and less work overall.
Xamarin Studio is the current supported version of the tool used to make Manager today. Using a non-maintained tool caused the issue that led to the creation of this thread and possibly others.
Well, my take was largely based on the Xamarin subscriptions being the largest barrier to entry. With Microsoft’s announcement a lot has changed in the last few days, in that regard.
And I realised he would already have a paid Apple developer account while I was typing the reply. I was just too lazy to take it out – guilty.
Xamarin Studio is the current supported version of the tool used to make Manager today. Using a non-maintained tool caused the issue that led to the creation of this thread and possibly others.
I’m not going to speculate on this, as I don’t know what tools lubos has been using, nor his particular workflow. Plus, I only have a basic understanding of programming.
All that being said, this seems to be the preferred way forward and only looks to be getting stronger support in the future. I’d put my vote here.
There a few roadblocks which need to be addressed before the latest version of Mono can be bundled in Manager.dmg. I’m working on it.
Yesterday’s announcement from Microsoft/Xamarian was good news.
1 Like
The latest version of Manager now embeds the latest version of Mono. This means the bug related to custom SMTP when sending emails should be resolved.
Just downloaded latest. It won’t open with OS X 10.11.4. I get this notice: The application “Manager” can’t be opened.
@Tut There’s the confirmation I was looking for.
Same issue here, though it can be run straight from within the DMG (as a workaround).
EDIT::
If you rename the Manager application it can open. If you change it back, it can no longer be opened.
Edit 2::
A restart should clear it up. The application has been changed considerably, enough that OS X thinks it’s an imposter and is blocking you from opening it. The restart clears a cache and everything should be peachy.
1 Like
I’m not able to reproduce this issue but if restart fixes this then let’s leave it at that for now.
Same here, “The application Manager can’t be opened”.
All OK after the restart.
Confirmed. OS X must first verify Manager after restart, which takes longer than normal launch. Subsequent launches are faster.
Updating today to version 16.4.33, happened again “The application Manager can’t be opened”.
Restart, Mac stays forever in blank grey screen, I had to force shutdown with power button.
After the second attempt works OK.
My experience was similar in some aspects to @ntrim’s, but different in others, because I followed different steps.
-
After downloading and installing the desktop edition of v16.4.33 into the Applications folder on my Mac, it would not open. I got the dialog box saying: The application “Manager” can’t be opened.
-
Rather than restarting the machine, I followed @smi89’s earlier suggestion of opening the application directly from the disk image. That worked perfectly.
-
Once I had opened Manager from the disk image, I could open the exact same version I had already dragged to the Applications folder, without downloading or installing it again. However, I now get this notice, which I’ve never encountered before, every time I open Manager from the Applications folder:
Why would the desktop edition need to accept any incoming network connection under any circumstances, @lubos ? (My usage data is not being shared.)
I tried uninstalling and reinstalling Manager. I still get the same connections dialog box. However, after having once launched the application, I did not see the “can’t open” notice again despite having reinstalled Manager.
I think what caused the “could not be opened” message originally was that the actual executable file had been renamed from “Manager” to “ManagerMac”. In this latest version “ManagerMac” has been changed back to just “Manager”.
As long as that file keeps a consistent name, users shouldn’t see “could not be opened.”
16.4.34 appears to have a problem with the code signing, however. Maybe just related to the renaming above.
When I got around the “could not be opened” I received the message that “the application is damaged” and an option to move to trash. This is typical of an invalid signature.
When I disabled Gatekeeper, “Allow apps from Everywhere” rather than “Mac App Store and identified developers”, I was then able to launch Manager.
@Tut I’m not sure why you would see the connections message, possibly a mix of all this and your firewall settings, but I am under the impression that Manager runs as a local only server - like a stripped back version of Server Edition running in a box.
I believe you are correct, @smi89. And while I can change my firewall settings, I don’t want to. Nor can I see any reason to with the desktop edition, except possibly for some interaction when usage data is shared. Since I don’t share usage data, it doesn’t seem that I should be asked. I suspect you are right about how Manager functions, and the new version just needs a conditional test that the old version probably had. (I did verify that there wasn’t any old exception in my firewall preferences from an original installation years ago.)
@lubos, any progress on my question 2 days ago about Manager accepting incoming network connections? It is getting frustrating dealing with that pop-up every time I launch the program.
Based on this answer: macos - "iTunes.app" to accept incoming network connections? - Super User
It appears digital signature on Manager.app is somehow broken. I will check today if this is the case.
Digital signature is good so that is not the issue.
So I assume your firewall is on (that’s good). When you go to Firewall options on your Mac. Do you have option which says Automatically allow signed software to receive incoming connections on?
Yes, that option is enabled. But a very strange thing happened when I opened Firewall Options to check. Manager was listed and showed the option to Block incoming connections even though I had never added it to the list. So I deleted Manager from the list, closed and relaunched the application, and this time did not get the warning. When Manager was open, the Firewalll Options list showed Manager with Allow incoming connections selected.
That seemed to make sense, indicating the operating system was automatically allowing a signed application. Manager disappeared from the list when I closed the program. However, when I relaunch it now, Manager does not appear in the list and I get the warning. Repeated closings and relaunchings have no effect; the warning now shows again every time. All the while, the automatic enabling of signed software has been enabled.
If I relaunch Manager and allow incoming connections, the program does not appear in the Firewall Options list. And if I close and relaunch, the warning box appears.
Here comes the weirdest part. If I specifically add Manager to the firewall exceptions list, allowing incoming connections, I still get the warning box.
So there seems to be some relationship with the firewall exceptions list, but whatever is happening is not repeatable. I got proper behavior once with Manager deleted from the list but automatic acceptance of signed software turned on. I got improper behavior many times no matter what else I did.
And I still question why the desktop edition needs incoming connections at all. Hope this info helps.
Desktop edition is built on top of server edition. Server edition is HTTP server and by definition, HTTP servers need to accept incoming connections to operate.
Desktop edition has its own firewall so even if someone figures the port on which desktop edition is running, it will refuse connection anyway. But Mac OS X has no way of knowing this and therefore it will show the warning on the basis of active HTTP server.
As for why you can’t make this warning to go away. First, check whether your copy of Manager.app is digitally signed. In order to do this, go to terminal, navigate to the folder where Manager.app is located and type:
codesign -vvvv Manager.app