We Keep Coding

Getting started with C# on OS X

I'd like to create a few simple C# applications and command line utilities to learn more about C#, affordably. Initially, I tried using Microsoft's free Studio Express in a Windows 8 virtual machine; however, it quickly reported that it could only create apps for the Microsoft app store and failed to build the simplest examples of an XML file transformer.
I also found Mono or rather MonoDevelop. I'm still reading about it. It seems that the SDK is entangled with the MonoDevelop IDE, and the MonoDevelop installer is actually the Xamarin Studio installer. Xamarin is a subscription based IDE and inexpensive versions of it appear to be constrained. Perhaps I need to continue studying; however, I thought I'd ask if anyone has experience getting started with C# on OS X.
Ideally, I'd like the simplest setup. I prefer using command line compilers, simple code editors, and build scripts. Are there Windows and OS X command line compilers for C# applications? Are there framework libraries that can easily be included that work on both OS X and Windows?

First, Mono is not an SDK, but a runtime. The specific point of Mono is to be able to, for the most part, run the same IL on other platforms as what runs on .NET for Windows. This means that, barring the slight hiccups in implementation, you could copy a program, run it via "mono program.exe" (via the console) on OS X, and get the same output (I have tested this with Console applications, at least - UI starts to get a little hairier).
In terms of library, the Mono libraries try to mirror the .NET ones so exactly, that the code you write for one is almost completely compatible with the other.
"MonoDevelop" and "Xamarin Studio" are the same thing, simply having applied a name change after a certain version. They are the most well known tools for building in the .NET language family on a non-Windows system (the only tools I even know of), and tend to mirror the shortcuts of Visual Studio well (at least on windows.) Unlike Mono itself, these are an IDE, and do not constrain you any more than VS constrains you into .NET.
The constraints you'll find with free Xamarin apply mostly to their mobile platforms (iOS, Android) and do not affect working with desktop (ie Windows and OS X) applications.

I've settled on using a Windows 8 virtual machine and Visual Studio Express for Windows Desktop as Dan J recommended. For usage similar to mine, simple desktop and command line apps, be careful not to select and install the "V.S.E. for Windows" version.

Porting C# code to run on OSX

We have a console app that runs in .NET 3.5. It connects to a USB device and spits out data received from it.
I'd like to port this over to OSX and have some questions about the strategy to do this. The USB Driver is already installed on OSX.
Mono looks promising but I don't get it. Does the end user have to install Mono or run something?
After looking at some other posts it seems that you can write a bash script and do some hacking to get the program installed...but I can't find a really good explanation of this. it also seems that mono wouldn't be installed in this process. These posts were also from '09 so I'm wondering if something has changed to make this easier.
My question is, what's a good way to approach running/porting a C# console app to OSX.

.NET is compiled down to IDL (bytecode) on all platforms including the windows platform. It is then run on the CLR (common language runtime iirc) which is a similar concept to the Java Virtual Machine. It just so happens that on most Windows machines that this CLR is installed by default. So if you wish your application to run on another platform you first need a CLR for that platform. Mono does include a CLR which can run on OSX. So either you (as part of your package/ bundle ) or the user would need to install this before your .NET will run.
The other issue you have is that .NET also contains certain API's which are not part of the ECMA standard which your application may or may not use. Some of these API's are present in mono, some of them are not. Those that are not usually have an equivalent or similar API which you can use to achieve the same thing however you may need to alter your application to deal with that scenario.
It really depends on what .NET api's your application is using as to how difficult it will be to port. I am guessing you are probably using winforms as part of your application so here is the guide from the mono site for that portion of the API
http://www.mono-project.com/Guide:_Porting_Winforms_Applications

You can bundle the Mono installer with your application (or your own build of Mono). You might even have the option of statically linking the mono runtime into your application on the Mac, I can't remember if it's supported (yet) or not. I'm pretty sure you can.
Also, wrt gordatron's warnings, if you use Path.Combine() to create paths instead of hard-coding \ as your path separator (which you should be doing anyway), you won't have to worry about having file system path problems.
For a nice easy way to check if your app uses any features which aren't available in Mono, you can use http://www.mono-project.com/MoMA to check for unsupported methods/classes and any other potentially non-cross-platform blockers like P/Invokes.
For a console application, I don't see you running into many issues (although you'll likely need to interface with the USB hardware differently than you do in Windows).

Cross platform development, GUI and Database - c#

Forgive me for asking a common question, but I couldn't quite get what I needed from what I found so far.
First question - SQLite. I am using this DB as in my C#.NET 3.5 windows service and it works great, I was looking for a portable solution, because I would like port my service to a linux daemon etc, using Mono, which seems to support it. However, I am not sure how to implement this. I had thought the dll was compatable, but it seems there is a seperate dll for Mono/.NET which I should have expected. Does this mean I need to seperately code/compile for each platform or is there something that would allow me use of SQLite with the same code on various platforms? I have encountered this a few times in my searches, csharp sqlite, a "reimplementation". To be honest, this is quite new to me, is it of use? The Mono SQlite page says that they Mono.Data.Sqlite code is based on System.Data.SQlite and goes on to say...
"We have chosen this way as means to
provide a migration path for
developers using SQLite in their .NET
applications"
Are they referring to creating a new, seperate binary? Or could I run my code as is with some adaptation?
Second question - GUI. As far as I can tell the two main options for cross platform dev in .NET would be GTK# and Winforms. Again however, its the specifics of implementation that are a bit hazey. Can I create a win forms GUI in visual studio as I normally would then easily migrate this using mono? Or should I develop this in something like X-Develop or MonoDevelop?
Many thanks for your advice/patience :D

To help out a little bit here I used the full mysql dll file that was provided and I was able to compile my program on windows using visual studio, and then deploy it to Linux without changing anything(except the case of the mysql dll file, which is kind of annoying you'll see what I mean at some point).
Also from what I've heard winforms isn't totally supported by mono yet, but I may be wrong. I haven't done a gui cross platform yet, but I would test winforms first, just so you could develop it in visual studio, and if that doesn't work I think GTK should be fine.
You just need to make sure that the dll's are compiled for .net 3.5 or below and you should be fine(90% of the time).
Check this out here, http://www.mono-project.com/MoMA and also the link that chris provided.

Differences in development between .NET and Mono

I'm looking into Mono and .NET C# and we'll be needing to run the code on Linux Servers in the future when the project is developed. At this point I've been looking at ASP.NET MVC and Mono.
I run an Ubuntu distro and want to do development for a web application, some of the other developers use Windows and run other .NET items with Visual Studio.
What does Mono not provide that Visual Studio does?
If running this on Linux later shouldn't we use MonoDevelop?
Are there some third party tools or add-ins that might be an issue with Mono later?

What does Mono not provide that Visual Studio does?
MonoDevelop is presumably what you mean here. MonoDevelop offers cross platform development on Linux, Mac OS X, Windows based on GTK. However it is not as polished as Visual Studio for obvious reasons - it's 3 people making it, not hundreds. It has some nice features, especially its source control plugin architecture. However as Visual Studio Express is free there aren't many advantages on Windows to using it.
It uses the same .csproj and .sln format as Visual Studio, however the XML docs format is different.
If running this on Linux later shouldn't we use MonoDevelop ?
As I mentioned above, the project formats are inter-operable.
Are there some third party tools or add-ins that might be an issue with Mono later?
Unlike Visual Studio, there aren't a huge wealth of add-ins for Monodevelop. The ones that you use in Monodevelop won't effect your .csproj files at all, as anything Visual Studio cannot read it generally ignores.
As people have said don't confuse Mono for MonoDevelop. MonoDevelop is an IDE for Mono that originally came from (forked) SharpDevelop.
Mono is the cross platform framework that 'apes' the Microsoft CLR and framework libraries.

I don't have much experience in this area but...
The Mono Project Roadmap has an overview of features that are new, upcoming, and not present in Mono compared to MS.NET. Even where Mono has the same classes as .NET, note that compatibility is not 100% (although that is generally their goal). I'm not sure if there exists a comprehensive list of things missing in Mono.
MonoDevelop is now available on both Windows and Linux so you're probably best off using it. However, MonoDevelop does appear to use the same project file format as Visual Studio and SharpDevelop, so you could make an attempt at mixing IDEs.
Of course, when using 3rd-party .NET libraries, note that many of them have not been tested with mono, and in particular anything that uses P/Invoke will not work on Mono for Linux. However, most incompatibilities with mono are minor, and if you stick with open-source libraries you can always fix any incompatibilities you run into.

You might also take a look at Mono Tools for Visual Studio. It lets your visual studio developers target and test with the mono platform.

You're aiming to always have support, and/or primarily use the software on Linux, correct? This is actually a question I asked the Mono developers at a conference a little while back, and it basically boiled down to what you want to do with it.
If you want it to always work on Linux, then use Mono. If you only care about Windows, then use Visual Studio.
If you're using Mono, then use MonoDevelop across all developers. It'll just make life a lot easier later on, and it'll make sure that whatever you write in the one will work for everyone.
Unfortunately, I do not know the answer to the exact limits/advantages of Mono vs. .NET, aside from .NET being further ahead, and Mono playing catch-up, nor about different addons.

If none of your developers need to develop on Mono for certain features, I suggest you all use Visual Studio on Windows. Then test the applications on Mono via
Mono Tools for Visual Studio
manually copy the binaries over
check out the code on Linux and build in MonoDevelop.
Personally I experienced a lot of small troubles when I tried out the third way, but luckily I am capable of finding workarounds.
It is only when you touch Mono, you know which part of your application needs to be tuned.
http://www.mono-project.com/Start

If you can help it, it'd recommend avoiding the Mono implementation of Remoting. There seem to be some unexpected hiccups and debugging it is not straight-forward.
We had a very Remoting heavy product that we tried to port to Mono so we could support Linux. Due to being unable to resolve the Remoting issues, we eventually had to abandon our attempts at supporting Linux altogether.
Caveat: my experiences may be outdated. See comments below

You don't need MonoDevelop in order to run ASP.NET program in Linux, make a shared folder on your development server (VMWare'd or real one), test often so you can easily work-around what's missing from Mono
That's the same approach I'm using in my .NET Remoting program I host on Ubuntu server. But I do the reverse, since I'm a solo programmer, I make a shared folder on my Windows development machine, then access that shared folder on my Ubuntu test server (vmware'd). On ASP.NET stuff, if the changes don't reflect on your Ubuntu test server, in Terminal just touch the Web.Config file in your Ubuntu test server. i.e. touch Web.Config, then refresh the page

Mono has a fully functional implementation of ASP.NET. This includes full support for ASP.NET Web Forms and Web Services. This essentially means that more or less any ASP.NET application that you have developed using with the .NET Framework will work with Mono. Obviously there might be changes needed, such as data access changes, removal of any
reliance on .NET Framework BCL types . Mono- Oracle users-.Net Programming C# : ubuntu 11.04

C# -Mono (platform independence)

I'm very newbie to Ubuntu OS and I have my solution developed in visual studio 2008.
I want my application to run in both windows and Linux(ubuntu).
I've few questions in my mind.
Does mono support visual debugger .
If I start development using
mono.Is it possible to run same in
.net framework (windows) ?? or do I
need to write the NSI script to
download the libraries during
installation from internet and
install.
What is the best way to
achieve platform independence.
Thanks in advance.

Yes, Mono has a debugger - see MonoDevelop.
Assuming you don't use any Mono-specific libraries, or ship them alongside your app, it should just work in Windows against the Microsoft .NET implementation - although of course you'd want to test it.
A lot of achieving platform independence is a matter of the libraries you use: make sure whatever you want to call is either already available in both platforms or can be shipped alongside your app. Beyond that, there are obvious things like not assuming a particular path/directory separator, potentially not assuming a particular endianness (although that's rarely an issue in C# in my experience) - and regular testing, both manual and automated as far as possible.

There is an Mono add-in for Visual Studio that warns you when building your app if you use something that Mono doesn't support yet.
Don't remember the name, thought.