The company I work for wants me to port a Windows service to a daemon for OS/X. I don't have access to an Apple computer, but can I develop on an OS like FreeBSD and expect the daemon to work on OS/X?
I guess it would depend on what the daemon is going to do. You might be able to create it in FreeBSD, but you will most likely have to tweak it to get it running on Mac OS X. How is it you do not have a Mac to develop the daemon, but you do/will have access to a Mac to run the daemon?
I assume they're going to rent/lease a Mac at some point, but since OS/X is based on BSD, I figured I could at least get started developing the daemon on a PC running FreeBSD, hence my original question.
The service I'll be converting is written in C#. My boss thinks we can use mono to write the service. I'm not so sure that's going to work (I had assumed they'd want me to convert it using C/C++, but it seems that's not what they had in mind).
Just from glancing over the articles I linked to makes me think you will be in a world of hurt developing on FreeBSD then moving it to Mac OS X. It seems pointless to me to do all this work for a, i.e. one, daemon. What are their future plans for this Mac? Is the company looking to move a Mac into the workflow? Do the "powers that be" know about the Mac OS X 10.5 UNIX certification? Your company can get a Mac mini for $599.00 and it should have no problems being used as a development machine and a test machine.
Other than "Good luck", I do not know what else to tell you. Mono on Mac OS X looks promising and looks to be a good way to expand your knowledge.
It's not just a daemon, it's a desktop app as well, but if they want me to write a daemon for a Mac, far be it from me to argue. I've been programming for almost 30 years, and I'm only here for the paycheck. I'm certainly not interested in trying to talk them out of something they think they want to do.
When/if they get around to wanting me to actually start work, we'll see what happens as far as hardware is concerned, but again, I don't care what they do with the hardware after I'm finished with it.
After looking at the links, I don't see how anyone could seriously recommend mono for development on ANY platform. It's not fully .Net compatible (irregardless of the version you might happen to mention), and you need an external binary (mono) to even run an app. I think I'll stick with C/C++ for this task (if anything ever comes of it).
I believe the whole purpose of mono is so C# developers can develop on non-Windows platforms since Microsoft submitted the C# language specifications to ECMA for standardization (ECMA-334).
Comments
The service I'll be converting is written in C#. My boss thinks we can use mono to write the service. I'm not so sure that's going to work (I had assumed they'd want me to convert it using C/C++, but it seems that's not what they had in mind).
http://www.mono-project.com/Mono:OSX
Ben S. Stahlhood II's WebLog
Project: Cocoa#
Just from glancing over the articles I linked to makes me think you will be in a world of hurt developing on FreeBSD then moving it to Mac OS X. It seems pointless to me to do all this work for a, i.e. one, daemon. What are their future plans for this Mac? Is the company looking to move a Mac into the workflow? Do the "powers that be" know about the Mac OS X 10.5 UNIX certification? Your company can get a Mac mini for $599.00 and it should have no problems being used as a development machine and a test machine.
Other than "Good luck", I do not know what else to tell you. Mono on Mac OS X looks promising and looks to be a good way to expand your knowledge.
When/if they get around to wanting me to actually start work, we'll see what happens as far as hardware is concerned, but again, I don't care what they do with the hardware after I'm finished with it.
After looking at the links, I don't see how anyone could seriously recommend mono for development on ANY platform. It's not fully .Net compatible (irregardless of the version you might happen to mention), and you need an external binary (mono) to even run an app. I think I'll stick with C/C++ for this task (if anything ever comes of it).