C# Programming for those who like .net and/or mono
jazzed
Posts: 11,803
Hi.
I'm a fan of C# and it is available on Linux and WinPCs (not sure about Mac - any help?)
In one of the other forums there was an emerging productive discussion of C# programming.
Some have suggested a C# GUI would be a nice project for developing code and communicating with various micro-controllers.
Is .net really cross-platform enough for that to work? Perhaps we can explore that here?
All C# ideas from young or old are welcome here. Please save .net bashing for another thread.
Thanks for your time.
I'm a fan of C# and it is available on Linux and WinPCs (not sure about Mac - any help?)
In one of the other forums there was an emerging productive discussion of C# programming.
Some have suggested a C# GUI would be a nice project for developing code and communicating with various micro-controllers.
Is .net really cross-platform enough for that to work? Perhaps we can explore that here?
All C# ideas from young or old are welcome here. Please save .net bashing for another thread.
Thanks for your time.
Comments
Just to point it out, so it's clear, the Mono .NET runtime is independent from any compiler or IDE, and you can run your C# (or other .NET language) compiled code on any of the above listed platforms. You can whatever method you desire to produce that compiled code. Whether it's the Mono command line tools, MonoDevelop, or the Visual Studio cross development route, the end result is a .NET assembly (exe) that can run in the Mono runtime (or the native windows .NET runtime assuming you didn't use a Linux or Mac specific library).
Another thing to keep in mind, you can generally mix and match any .NET language code. So you can have some parts of your code be in C#, some in VB.NET, yet still more in C++/CLI, and so on. It all compiles down to the same CIL for the CLR. There are CLI variants of a lot of languages, including Python, Ruby, COBOL, Lisp, and more. So you can fairly easily bring over a lot of existing code that you might have and "glue" it together with C# code.
Roy
You mentioned ".exe's". Is a .NET-compatible .exe actual compiled code, or just a convenient packaging for bytecodes that get interpreted by the CLR? 'Just trying to get a handle on .exe's in the context of OS/X and Linux where .exe is not a native file type.
-Phil
"PE32 executable for MS Windows (GUI) Intel 80386 32-bit Mono/.Net assembly"
Presumably they wrap up the byte codes that are to interpreted by the VM at run time.
Run the byte codes on Linux with:
$ mono HelloWorld.exe
mono knows what to do with them. That HelloWorld is actually a GUI app with a few buttons that work. Created in monodevelop even without reading the manual.
Linux can be configured to run mono programs automatically just by giving the file name as a command.
Technically, both, Phil. They are packaged 'bytecodes' or IL (Intermediate Language) but they are not interpreted by the CLR, instead, they are recompiled (called Jitting) at first execution into native executables for each platform and then executed.
Bill
Everyone answered for me. On Windows you can just run the exe directly, on other platforms you run it through a native app that implements the runtime. What wjsteele called Jitting is Just In Time Compiling (JITing). It's actually done as it runs in most cases, so you don't get a big delay every time you run the .NET exe as it compiles the whole thing to native.
Also, the CLR does run bytecode too. It depends on the implementation how much get's JITed, and how much is just interpreting the bytecodes.
Roy
It helps so much when using .NET dll's the way they were intended. All experianced .NET developers will love you for it.
Just to clarify... in the full Microsoft .NET CLR platform, all code is jitted before execution... it just depends on when. There is no bytecode interpreter in the full .NET Framework. It does, however, both have the option of precompiling the code at runtime as well as dynamically compiling the needed functions/methods that are being called, which has the advantage of dynamic code (like the intrepreter does,) but the performance of native code. (Again, with the one time hit for compiling each method.) All compiled code is stored in the "Application Execution Cache" and executed directly from there.
The .NET Compact Framework (used in Windows CE) also JITs the code, however, due to some special constraints (like small device memory) it can unload previously jitted code and recompile it when needed to free up memory.
Mono does have the option for using an IL intrepreter for some of it's platforms, but not all.
.NET MicroFramework, which was mentioned by Invent-o-Doc, always interprets due to very low memory available. There is no option to pre-jit the code.
Bill
Dont forget that .NET also runs on XBox 360 called "XNA Framework", and .NET Compact runs on Windows CE and Zune.
I will try and get some basic serial port communications libs uploaded to my site, these lib's/dll's will need to be called by your code but I will create some sample Windows Forms that use them so you can see how they work. All my project code will be in Visual C# 2008 Express. This will give anyone/everyone the ability to use them if they so desire. the direct link to where I will upload them will be http://whatsavailable.org/Propeller.aspx Give me a few days to put together some good samples.
Unfortunately, I will not be able to do much IDE coding for a compiler, that is beyond my experiance, but I may able to incorporate the use of propellent or a similar tool for compiling.
#region CreatePort handler /// <summary> /// Create a serial port instance /// </summary> /// <param name="sender">Sender</param> /// <param name="e">Serial event arguments (port and baud)</param> public void CreateSerialPort(Object sender, SerialPortEventArgs e) { // Create the serial port serialPort = new SerialPort(e.Port, int.Parse(e.Baud)); serialPort.WriteTimeout = 5; serialPort.ReadTimeout = 100; // Open the serial port serialPort.Open(); // Wire the serial port data received handler serialPort.DataReceived += SerialPort_DataReceived; // Fire the port created event SerialPortCreated(this, e); } #endregionAnd Silverlight (which is itself it's own .NET Framework) runs on Windows, Mac OSX, Windows Phone and certain Nokia Phones!
Most GPSs that use TrafficLink also are .NET based, as that service is provided through a technology called MSN/Direct which came out of the SPOT Watches (and is now the opensourced .NET MicroFramework!!!) But the GPSs are usually running CE.
Bill
You can break it down a bit more if you just want to see what ports are currently connected, either at app startup or through a button, etc...
populate a combo box with the following
Mike G. and JorgeP, I used similar serial port techniques posted before (maybe i used delegates) with mono 2.1 on Fedora a couple of years ago, and could not get anything to work. I'll try it again once i get Debian installed under a VM on my workstation ... been seriously putting that off :<
I'm hoping to post a source version of Propalyzer here either Sunday or Monday. That works great on mono with everything except serial ports. Maybe someone can help solve the serial port riddle.
Let's see if we can further lift the potential of C# in Parallax micro applications. Thanks.
But I will post the zip here as well for those that dont want to go to my site. It needs to be compiled so you can use it to see if monodevelop will indeed compile the code without errors. If mono supports serial ports, it should run fine and display a list of serial ports in the dropdown box once the "Get Serial Ports" button is clicked.
If it dont compile in Mono, I will compile a debug and retail version myself, and post thise files to see if they will run.
After that, if they don't run, then serial is probably not supported yet in mono. OR mono needs to be configured.
PM me once with errors under mono
I will be gone for 2 days so I will get to the PMs on the 9th or 10th
Hope it works fine....
Attached is a screenshot of my IDE front end for catalina. This is written in vb.net 2008 and enables development of C89 code.
vb.net is very similar to C#. And I think C89 is a subset of C#.
How cool would it be to have an IDE written in C# that can compile code in C# for running on the propeller?
-Phil
Dim ports As String() = SerialPort.GetPortNames() Dim port As String ComboBox1.Items.Clear() For Each port In ports ComboBox1.Items.Add(port) Next port ComboBox1.Text = ComPort ' com portat the beginning of the program and then
Public Class Form1 Dim WithEvents SerialPortName As New IO.Ports.SerialPort ' generic serial portThis could be quite a fun little project.
<rant severity="high">
I was starting to get a warm feeling about C# until you mentioned XML Code Comments.
That is one of the ugliest and dumbest things I have seen in programming ever. This XML thing seems to have gotten out of hand.
Now not only do you have the tedious repetition of the parameter names, in the C# method definition you also get the endless repetition of those XML tags "<param...> ...</param>"
and attribute names.
C# is syntax is derived from C which was supposed to concise. This is like bolting ADA or COBOL on top of it.
I really don't want to end up having to read reams of that stuff in source code.
C# syntax was looking quite clean to me, why oh why did anyone think soiling it with XML was a good idea?
</rant>
OK that won't put me off trying to pick up some C# know how but it really does make me wince.
Don't feel bad. This whole .NET/Mono thing has me blindsided. And, although I'm loathe to admit it, my ignorance has been as much studied as accidental. Not that I regret concentrating on Perl instead, but sheesh!
-Phil
I'm done for. In the space of a few days I have been "blind sided" by both this .NET development on the forums and Linux Mint (which I'd never heard of despite following Linux for years)
Same here.
I have it running on my netbook with no effort. Moreover there is a dual boot installation option for windows machines which is rather nice (wubi).
It installs ubuntu on a NTFS disk, and offers a dual boot option. If you don't like it simply uninstall as any other windows software.
As a general alternative virtual box offer a nice place to experiment.
Massimo
Hmmm... I'm not sure how else you'd do this. It's not just about commenting the code... the real beauty is the fact that when you write a library, it allows your comments and instructions to the users to be exposed to the tools.
For example, when you hover over an method, it'll popup a tooltip giving you the correct usage of that method. In fact, it'll also show you any overloaded methods as well.
By using XML as the basis for it, it allows ANY tool that understands XML to parse the source code file directly.
I think the benefits of this tech far outweigh the down side. Be sides... tools like VS can actually hide it as well via collapsing regions, etc.
Bill
This is Microsoft's answer to Javadoc, so not really unique to C# or VB.NET.
It takes some getting used to, but it can be helpful for others using your libraries as wjsteele pointed out.
C.W.
Actually when I need to understand what a parameter means, some kind of tagging helps me to wade through the usual Smile such as 120 characters of *====... or whatever some maniac thinks I need to see to understand their program.
I've used Javadoc tags for years and years as documentation markup for DOXYGEN. Javadoc is much more concise, but it's not "standardized" (for whatever that's worth) like XML. You will find this in almost all my published code because I think it's helpful to others AND i don't have to write some silly API document that has to be updated every time I add (maintain) to my code.
This kind of thing generally helps to reduce errors in communication on several fronts. XML just happens to be the "channel" of communication that suits the documentation program.
So in the spirit of better all around code quality, it's best to just be tolerant of the markup.
(And I guess I should be tolerant of enormous and useless stars and bars lines).
-Phil