What is normally to be done to run a WinForms application on a Mac or Linux machine?
a. Just copy and run (assuming they have a Framework installed).
b. Rebuild.
c. Cosmetic source code modifications.
d. Heavy source code modifications and forms redesign.
Assuming that the application is developed as 100% managed C# 3 code by means Visual C# Express or Visual Studio 2008 targeting .Net Framework 3.5, developed without using any 3-rd party components/libraries, without encapsulating nonmanaged code or any low-level hacks - only standard Microsoft-documented .Net Framework C# API used). Or the same conditions but C# 4 language, .Net Framework 4 and Visual Studio 2010.
Is there somewhere a practical guide for developing Mono-ready applications while using MS .Net Framework and Visual Studio? Any guidelines, tips, specific aspect highlights, informing a developer of what he really needs to keep in mind to write an easily portable application without having to lookup every function in the Mono reference while coding in Visual Studio.
It is possible that your app will just run with zero modifications, but I've yet to see that happen in the real world.
A tool which may help you a great deal is MoMA. MoMA is made by the same folks who make Mono, and will tell you if you are using any features that have not yet been ported.
In general, .NET 3.5 and Winforms is mostly OK. Compatibility with version 4 is still very much in development.
A more up to date tool, if you're doing your development on Windows, is the .NET Portability Analyzer from Microsoft. This can be used via Visual Studio.
If it's a Windows Forms application, using standard Windows Forms controls, and no 3rd party components, you can typically run this on Mono directly, just by doing a copy and run.
Mono supports Windows Forms and C# 3 features very well.
However, if you use any native components, data access outside of what is supported by Mono, or WPF, you'll run into issues. C# 4/.NET 4 will most likely not work at this point, either.
Well, i didn't develop large projects, but from my experience you would have to introduce some minor modifications to your code, but just to refine some things. The application itself should run just fine without recompilation. As for windows forms, i found it to be extremely slow some times when working with GDi, but maybe i was just doing something wrong. However, the Mono team claims it has full support of windows forms.
One more thing worth to mention. It is really hard to write a cross-platform application, which wont be harsh without using some native OS features. I think you should always consider a possibility to write some additional OS-specific modules to provide a tight integration with the underlying OS and leverage some cool stuff (like an awesome toolbar features in OSX). You should also remember, that people are used to different look&feel on different OS's
Theoretical, .Net is fully cross platform, as it doesn't depend on specific architecture, but on a VM.
In practice though, you have the microsoft implementation for windows, and the mono implementation for linux/mac. The main problem is that the implementations can differ from each other, making it hard to run an application on multiple machines out of the box.
Source code shouldn't have to be altered, if not some of the libraries are not ported to mono, or different libraries are used.
C# 4 can be a bit harder, because mono isn't yet up-to-date to the microsoft implementation.
Related
I am new to programming and I am interested in developing applications in C# using Mono. I would like to choose a GUI framework other than GTK+: either WinForms or XWT (https://github.com/mono/xwt).
Is there a designer to design WinForms GUIs? What about one for XWT? I am using MonoDevelop as my IDE.
If there is no designers for either WinForms or XWT, do you think it possible to write the application in C# in .NET with WinForms using Visual Studio 2012 and just compile it using Mono when I want to deploy?
That's probably two questions.
1.) What are my Mono GUI RAD options?
If you want a Mono GUI RAD your only choice is GTK# as far as I know.
If you want a GUI RAD for Windows.Forms, it's called Visual Studio (or potentially VS Express for Desktop in Win8) and requires Windows/working outside of MonoDevelop. ;) On the plus side, it's a really good GUI RAD.
2.) What GUI framework is best for writing once and running everywhere?
Gtk#. Unfortunately, Mono's Windows.Forms doesn't work well and is a dead end tech. See here for a similar question.
As I mention in an answer there, if you want to write a utility that targets multiple OSes in Mono (or you're Linux-centric), you probably do want Gtk#. If you want to create a traditional client app, prepare to rewrite your GUI on each target platform.
Edit: Less nepotistic question on a similar subject here.
Edit2: There is a Mono WinForms designer that I forgot about here, but its description readily admits that, "Unfortunately the designer is not ready yet for proper use," and the blocking bug they refer to is from 2007, so not much help.
Good luck!
Looking at current direction of mono who driven by Xamarin, they promotes the native UI for each platform. means you writing business process as separate project and GUI for each target platform. as for desktop, using XWT is preferable as you will uses similar API to access native UI in each platform, without loosing ability to add more advance UI for each platform.
XWT API is based on GTK# API (easy for Xamarin folks to migrate their existing apps), and provides with lot of common widget/control which implemented for each target platform (WPF for Windows, Cocoa for Mac, GTK for Linux). furthermore it easier to add advance/custom widget and hosted in XWT as it actually like hosted in native toolkit in each platform
Update:
About Winform is already answered, for XWT seem no designer yet, but for deploying, just creates projects XWT GUI (Shared all XWT GUI), XWT.WPF (XWT launcher for windows) and XWT.Cocoa (XWT MonoMac application for Mac). But the each launcher only can be compile in each platform
If a group of developers are working on a project written using ASP.net and C# in a Windows environment with Visual Studio, is there any way a developer can join their team and work with them on the project in a Linux environment? I know about the open source, cross-platform development framework Mono, could this be an option or would the Windows developers have to use this as well for that to work? Is the best option for a Linux developer to just install a Windows partition or can he join them without doing so?
Is the best option for a Linux
developer to just install a Windows
partition
Yes, by far. Even better, just get a PC. I've run into so many headaches trying to develop in .NET on Linux. Mono isn't perfect, and never will be.
Yes! Use MonoDevelop and a source management solution like Mercurial.
Yes, MonoDevelop can even load the Visual Studio solutions.
It deppends on many factors, I'd say that if you plan to use third party controls, for example, then you probably better stick to windows and visual studio. If you are going to do P/Invokes (call Win32 api methods) then, again, better stick to windows.
The fact is that many functionality that .Net framework has is only available on the Microsoft redistributable installer/visual studio installer etc. If you are joining a team that already has a project going on and it is linked to any of this namespaces (Microsoft.* comes to mind) then definitely install windows and visual studio, on the other hand, if you are just starting a new project it could be easy to develop on linux with monodevelop as long as you stick to anything that is fully supported by the mono framework.
Another thing you should consider are licenses. If your team already has visual studio and windows licenses it does not make much sense to switch to linux, as much as I love linux and mono/monodevelop the best way to develop for .net is the microsoft stack without a doubt.
What makes sense is to try to comply with mono so that your software can run in unix/linux infrastructure if you already have it and if switching it to windows server, for example, raises the cost too much.
It's all about the cost, unfortunely, so see these tools just as that, tools, they are the means to an end and just that. If developing and deploying with windows and to windows is cheaper then go ahead, if you have a large unix/linux server set already working and want to deploy into that then use mono, just consider it has a slightly learning curve since it is NOT visual studio/.net per se.
I'm about to start a project that requires me to write c# code. The thing is, I've got a mac.
I was wondering if there are any pitfalls involved in c# development using mono on OSX 10.6
I think the page is clear that the implementation is crisp, but on the other hand I've read that people install VMWare or something like it to use Windows. I'd like to avoid that if possible.
Note
I'll be working on a team and all the
other guys have Windows machines
Thanks
Based on your comment to HiVoltRock's answer (ASP.NET development), I'd say Mono 2.10.1 and MonoDevelop will be just fine (the stable release of MonoDevelop works just fine, but for development on OS X I prefer to use the most recent version which I compile from Git).
There are some things to take into account, such as file paths (ie: if the windows devs are writing static paths such as ApplicationsInstallDirectory + "\data\templates\foo.bar"; you will run into problems as directory separators on Mac OS are forward slashes. Also if existing code is using P/Invoke or other specific Window's functionality you'll be in trouble.
Finally if your code base uses third party libraries that requires Windows this could cause you issues.
For reference our product has been designed since day one with a requirement that it runs on Mono on Linux or OS X. With that in mind we've made sure to consider everything with cross-platform execution in mind. If you're joining an existing product, the same considerations might not have been given, meaning a lot of the existing code isn't compatible with Mono.
The Mono Migration Analyser will help determine if you've got any incompatible code.
There is a bit of fud out there about developing under Mono. Our project is an MVC3 with Razor, running .NET 4 using NHibernate, StructureMap etc and there haven't been that many issues developing on a non-Windows machine.
Be aware that the .NET libraries from Microsoft and the implementations in Mono are compatible "most of the time." If you're working in a team, you may run into some headache related to these compatibility issues (also, if you're using any third party plugins to any .NET application you're writing, you may have issues as well.). If you didn't want to run a virtual machine, I'd just bootcamp into Windows. It might disrupt your flow if you're very used to the OSX UI, but if the rest of your team is using Windows, I'd do that just to avoid compatibility issues.
The biggest thing I've had developing on Mono (admittedly on Linux) was GUIs. The majority of GUI-less code will run just fine. The only thing I've had to do is catch a few different exceptions. GUIs, however, would be a whole different beast, so don't expect those to translate well at all.
I would highly recommend using windows thru vmware rather than trying to code with some unstable osx programs. It's not cool to code for hours on a mac and then realize that none of your code works on any windows machine or that the gui looks totally different than on your computer.Always choose the right tools and languages for the right problem. Besides, visual studio is pretty nice to work with most of the time.
I've come across odd cases of memory leaks and segfaults with code compiled on Windows and dropped onto a Mono Linbox as-is. I've also had issues compiling .csproj files with xbuild that had some MS quirk that xbuild wasn't familiar with.
If I'm not mistaken, the two compilers do slightly different things at times, which are related to subtle implementation differences in the runtimes. This is most likely the cause of the segfaults and memory leaks I've come across.
My bottom line is, compile on the same platform as the runtime. So for local testing, you should be fine (you compile on mono on your mac and run/test with mono on your mac). But don't build the project on your mac and then release the resulting Mono binaries to Windows servers running MS .NET runtime (or vice versa). If you have a build server best would be to stick to that (which we all should do anyway... right?).
If your team doesn't have a build process and you must build the binaries you are going to release, I would use a Windows VM for that final step.
Which one of the following IDEs/language will you recommend for developing a project under windows that involves recognizing hand gestures and interacting with the OS? I will be using OpenCV library for image processing tasks. After that I will be using win32 APIs or .NET framework to interact with the OS, depending on the tool you suggest. Performance is also a major issue.
Visual C++ 2008 (using C++/CLI)
Visual C++ 2008 (using native C++)
visual C# 2008 (using .NET framework)
Qt
Dev C++
Code::Blocks
It sounds like your targeting Windows and only Windows. As such I would stick with Visual Studio. It's a great IDE and is designed specifically for windows development.
Both QT and Code::Blocks are designed to be cross platform IDEs. I don't have a lot of recent experience with either of these IDEs. In the past I've found that they were great at providing tools for generating cross platform code but not nearly as good at helping you target the features specific to a particular operating system. If you are only intending to target one platform you will likely want to use some Windows specific features.
As for the language that depends a bit more on what you are actually doing and is overall a bit subjective. My personal advice though is to use C# unless there is a constraint preventing you from doing otherwise. For example if you had to write a driver which required C++ code.
If I understand you clearly, I think what you want to know is not the IDE to use, but the programming language/platform to use.
If you go for C++/C#, Visual Studio is a great IDE, but I hope you know that it is costly too.
If that's fine with you, anyone on SO would highly recommend going for Visual Studio.
Visual Studio Express (freely available) is good if it is just an academic project.
If you are targeting C++ then there's absolutely no reason to use C++/CLI versus the native version. The only time I've ever used C++/CLI was for integration of a native C++ library with a managed code layer, to obviate the need to use COM interop.
Agree with Jared's suggestion to use C# (for speed of development) unless you have native code dependencies that require C++. I don't see any managed implementation of OpenCV mentioned here.
If you are targeting Windows only, then there's no reason to use Eclipse versus any version of Visual Studio >= 2005, unless you are totally familiar with Eclipse and a newcomer to VS.
I haven't yet needed to write any cross-platform apps in C#. However, everytime I come to work with paths etc I always wonder what things I should be doing to make my life easier should I need to cross compile to Mono.
I understand the GUI could be an issue. I would like to try and employ good cross platform practices in my normal Windows coding if possible.
Are the any ADO issues to watch out for?
What issues have people come across and how are they resolved?
Run everything through MOMA after you have written it. It will identify for you any constructs that are not platform independent or not implemented in the Mono runtime.
Additionaly compile both with MSBuild and the mono .net compiler.
Using Path.Combine and Environment.NewLine are a couple off the top of my head.
Avoid windows only construct (WMI and such) that have no linux/unix analogue.
Path.Combine springs to mind.
Guidelines:Application_Portability might be usefull
If you create your application using Mono in a Windows environment using Gtk# then it should run on all platforms, since it will not use any of the .NET libraries which are not available under Mono, nor will it use any of the Mono/Gtk# libraries which are not supported in Windows.
If you're a Visual Studio user, take a look at the Mono Tools for VS package.