This could be because desktop edition bundles an older version of Mono which could have this issue. When trying server edition, you will end up with newer version of Mono. I’m pretty certain this is the issue and I will need to update Mono version within desktop edition bundle to fix this issue.
I first installed Mono Framework 3.4.0, which was listed in the prerequisites for Manager Server. That worked, although didn’t install properly on the latest Mac OS X.
I also installed the latest Mono Framework, 4.2.3, which also worked, but installs properly in OSX El Capitan.
I’m considering not to bundle Mono framework on Mac OS X and simply ask users to install it separately before they can start Manager.
Will this be required if we don’t email from Manager?
If Mono is not bundled in DMG file, then it would need to be installed separately otherwise Manager wouldn’t start.
However, one advantage is that Mono would need to be installed only once and Manager.dmg package itself would be decreased down to 2 MB or so.
Disadvantage is that installing Manager on Mac OS X for the first time would be two-step process. First install Mono, then Manager. Upgrades would work the same way as they work now (since Mono would be already installed).
The install package for Mono framework is between 150-200MB, I haven’t checked the installed size. As you say it is only for the first install and should need to be done again, but some users may be against the large install.
Would having the framework separate make support easier, or more difficult? Currently you know what versions you have bundled with each release of Manager. With a two part install, users could have multiple or different framework versions installed and you’d need to make sure the correct version is called.
By the way, which version of Mono is bundled at present?
I moved several posts to a new topic, as the subject had veered a long way from email problems. It also seemed like a good idea to solicit wider feedback from users.
Having looked up a little about Mono, I’d like to put my oar in the water on this idea of removing Mono from the standard download bundle, if that’s the right term, for Mac OS X. My head hurts just from reading a summary on Wikipedia. I would not want to get into what appears like a formidable software installation and maintenance routine just to do my accounting.
Granted, there appear to be many users for whom removing an essential element from the installation and adding standalone preparation and maintenance tasks would seem simple. But there are also many who are clearly barely functional. The idea of having to download and install something else before you can install and open Manager seems a great disservice to a great many people.
I know I’d eventually get it right, and perhaps learn something interesting in the process. But had I been told I had to do that when I first adopted Manager, I would have chosen a different package. I would have viewed Manager as a half-baked product.
One of the reasons I use a Mac is that I constantly encountered situations like that in the Windows world. You had to be an IT expert, or have access to one, to keep a laptop running in a geographically distributed company, even if you only used the Office application suite. No one thought anything of constantly requiring you to update drivers, add third-party apps for something as simple as generating a PDF, or asking you to wrestle with arcane IT trivia. I have no desire to plunge back into that world, even if it makes the Manager disk image download a little quicker. (I don’t have outrageously fast broadband capability, and it still only takes a few seconds.)
Stick with simplicity for the user. I thought that was the Manager philosophy anyway.
1 Like
Without getting into a Windows/Mac debate I think that it would be better to separate the accounting program from the Mono Framework. I suspect that Mono Framework is something similar to the Microsoft .net framework.
Now with Microsoft.net framework there are many programs that use this platform, so it makes sense to have say the latest version of the .net framework installed separately and all the programs that require framework use the same version.
This has benefits:
-
You have one framework installation across the board instead of a dozen different versions of the framework installed with each program.
-
For troubleshooting purposes, it would be far easier to identify a problem with a program and a specific framework version as one could say. Everything worked fine on .net 4.5 but now Manager is very slow on .net 4.6 to use an example (not a true example, just an example). As @Tut mentioned in another post apparently there was an issue with Mac OS and Manager freezing. My impression is that its this Mono framework that was the cause because @lubos mentioned something about updating either this or something like this a few months back. Integrating the framework within the program makes it harder to identify the framework as the cause of the freezing problems which I believe has been fixed for Tut since updating Manager and updating Mac OS to a later version making it difficult to identify what actually caused the problem and thus prevent the problem from re-occurring.
I do not feel that requiring a user to download Java, Flash player or .Net is difficult for any user and should not lessen the appeal of the program in any way. In fact Manager would be leveraging the frameworks provided in Windows and Mac OS X instead of re-inventing the wheel all the time.
All you need to do is have a popup alert to say that the framework is not installed an you can download it from here type thing or even better have a real time link to the latest version of the framework for Mac OS X. For Windows, Microsoft .Net is updated through windows update.
As an added addition, removing the framework from the install routine just might reduce the false positives from anti virus programs. 
@dalacor, you just proved my point. You are an IT pro. What seems simple to you is comprehensible to me, but not necessarily easy to understand. To many, it would be gibberish. 
I understand the reasons for installing a framework, but like @Tut, prefer not installing things like that on my day to day systems. If nothing else, it doesn’t seem as clean and is certainly at odds with the Mac ethos.
I do not feel that requiring a user to download Java, Flash player or .Net is difficult for any user and should not lessen the appeal of the program in any way.
In theory, yes, but with security concerns nowadays more and more people are moving away from system wide libraries (yes, oversimplification). Java and Flash have old versions disabled or deleted and browsers, either natively or with extensions, can block or ask permission to use those libraries. It becomes another potential attack vector to be actively kept up with.
When such libraries are bundled into an application, their scope is essentially limited to that app, so long as you trust the application you should be golden.
As an added addition, removing the framework from the install routine just might reduce the false positives from anti virus programs.
@dalacor The false positives are likely related to the Win32 .exe in the bundle, which if I understand correctly, would always need to be included as Mono acts as a wrapper for the .Net application to let it run on Mac/Linux.
I appreciate everyone has differing viewpoints on this. I am kind of in the middle in that I am a user like yourself, but I also work in IT (although not programming), so I can see things from the developers point of view as well. So I am just adding my opinion to the table discussion.
I agree with some points made here. I don’t tend to install any program that requires Java because of all the security concerns as Java is in my opinion a very unsafe program to use. So a system wide library does have security concerns, but given that Microsoft .net is installed on pretty much every windows machine, you are not going to make Windows any more secure by bundling .net with Manager. Whether that is true for Mac OS X I cannot say but Microsoft .net for windows is used by so many programs that it doesn’t matter what computer I go to, its installed.
I don’t know, I guess it depends on which method would be simplest for the developer to maintain as evidenced by the fact that the desktop version is apparently using an older version of mono which means that by separating the two, the developer has more time to concentrate on developing Manager and “outsourcing” the development of Mono per se! There are clearly advantages to both methods I agree.
But the developer knows Mono is there. Hundreds or thousands of users do not, so they wouldn’t even know they have to maintain it.
Now I see where you are coming from. I am not expecting the end user to know to update Mono and so on. I was expecting Mac OS X to be able to manage the update maintenance of mono and other shared libraries like that.
All I expect is that the user download Manager.dmg and download the Mono program and install both and then in future, all they have to do is download Manager because I assume that Mac OS X would take care of updating Mono? So I am not expecting the end user to be an IT technician as all they will do in the future is download manager.dmg and update - thats it.
Unless Manager was/is specifically written to use Mono instead of .Net, there is no need for a Windows user to know about/use Mono on Windows.
From what I gather, the purpose of Mono is to allow .Net applications to be run on systems where they would otherwise be unable to; Mac and Linux.
As .Net is used for many Windows applications, it certainly makes sense to install it once there, but it would be used vary sparingly for *nix systems.
Plus, .Net is usually updated through the Windows Updates service, rendering it “install and forget” for Windows users.
So, whatever is chosen, bundled or required install, it will business as usual for Windows users.
Yes I agree. My question is - how does this work in Mac OS X. Will Mac users have to update Mono manually or not? I will be honest and say that as I am not a Mac user, I have no idea what mac apps use Mono so I just presume that it works in a similar way to .net on windows i.e. you install it once and then operating system handles the update of that particular piece of software.
So in short, the question is will it be business as usual for Mac users - bundled or required install?
Sorry, I missed that out. There would not be automatic updates for Mac users at least. They would need to download and install any Mono updates for security or compatibility from Mono’s website.
Installers such as that could be bundled in a Mac package installer as opposed to the standalone app. Which would be similar to installing some programs on Windows where it checks for .Net and installs/updates it if needed before continuing with the application install.
That would seem rather unwieldy for a compact application like Manager though.
OS X updates only Apple software. You would have to maintain Mono yourself. Some programs for Mac, such as Microsoft Office and Adobe applications, bundle an updater so you can get updates automatically. Many, probably the majority, do not.
I strongly disagree with the proposal of requiring a separate Mono Framework Installation:
- This increases friction for users. It’s hard enough to get users to perform one step. We need less friction, and more users
- New potential problems due to infinite combinations of installed Mono version and Manager.io - Currently only one pair is tested and supported.
- Poor citizen with other apps - Could break an already-installed Mono app that does not play nice with version that Manager.io forced the user to install. User will have hell trying to fix that, or even know what happened.
- Against best practice on OS X, and a backward step to becoming a better Mac app.
- It’s hard enough working out the non-standard behaviours of Manager.io on the Mac. Explaining these unexpected behaviours to other Mac users trying Manager.io is already difficult. Unbundling Mono will cause even more problems with end users.
Rather than turn Manager.io into an even more non-standard Mac app, instead become a best practice Mac app that looks and acts in a trustworthy, familiar way:
-
Use Xamarin Studio to build the Mono library in to the Mac app.
-
Enable Application Sandbox (one click in Xamarin), as the app is run on a computer that has sensitive business data.
-
Ensure Manager’s application data is stored in Application Support - where the user expects. Not in a folder that’s only accessible using a terminal command known by few, that has a name that does not have anything to do with Manager (~/.local/) !!!
-
The above three modifications would let you publish Manager on the Mac App Store, which might bring new customers. Manager would also be automatically updated on their computers, including the bundled Mono library.
-
If you want, you would get an Android and iOS version for minimal extra work, and the Windows version can also be generated from Xamarin Studio for parity. Linux versions can still be built from MonoDevelop as before - Xamarin Studio is a superset of MonoDevelop.
Failing that, at least keep the Mono included in the Application bundle relatively recent and the same version across Linux, Mac, Manager Desktop and Manager Server.
1 Like