Two Questions:
Is there any way to write cross platform programs on Microsoft Visual Studio?
If there isn't then could I write a C# application on VS2008 and recompile it with MonoDevelop and have it work?
1 - I dont' think so. Not without something like Mono.
2 - Yes you can, but Mono doesn't cover all the framework - they are working on it.
The best thing to do is check with the Mono Migration Analyzer. The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have on Mono - http://mono-project.com/MoMA.
I have found most of my .NET 2.0 applications can be converted, but you may need some tweaks.
You can always use C++ and QT. Soon QT will be released on LGPL license (from version 4.5) that will give some more freedom.
The only limit of using free QT license is that you don't get integration with VS. However this can be handled by using eg. CMake (which will generate VS solution files).
Yes, Write your code, compile and run on another platform using Mono. When you compile you generate IL, which Mono can use. Note: Some functions aren't available on Mono. Delphi Prism, is an add on for Visual Studio which allows you to code to Linux and Mac from VS albeit in the object Pascal language though.
Yes, see same issues as in 1
I agree with Joe90, just one thing he left out: MonoDevelop can compile .sln and .csproj files because it has a MSBuild implementation.
So point MoMA at your code and if you get a green light it should compile as-is in MonoDevelop.
As a MSCLR junkie I have to admit that Mono has a few 'better' implementations of certain critical functions (mostly to do with encryption). You will get more usability power from these.
Another thing to watch out for is subtle logic errors. If a class is implemented in Mono it does not mean that it will behave the same the MSCLR one (Mono is a cold-room implementation and as such they DO NOT use the original source code). This is really where you will get good results from a well unit-tested code base.
For a good indication of what you should expect, I remember seeing a large amount of #if MONO in the AgsXMPP repository.
You could ideally write a C# application and have it run on the Mono platform. BUT, that will depend on the libraries of MS .NET that has been ported yet to Mono.
Just in case, there is no language constraint, you could consider using other languages like Java, Python, Ruby and the like..
Good Luck!
As many others mention your success will depend on the libraries you use. Mono does have Winforms but I would suggest that you also look at GTK# http://www.mono-project.com/GtkSharp as your windowing library. If you use GTK# you will use a library which is not reverse engineered (as Winforms is in Mono).
My understanding is that "non-gui" .NET 2.0 stuff is pretty much in place with the newest versions of Mono
You don't need mono develop, the whole idea of mono is you can develop for .net and have the same assemblies work on both mono and .net, provided you only use stuff which has been implemented in mono.
Stuff which won't work:
pinvoke,
wpf,
linq to SQL
Stuff which will work:
.net 2.0,
c# 3.0 (including linq to objects and linq to xml),
winforms
If you write your application in Silverlight, anyone with a web browser and the Silverlight plugin can access your app. This is as cross-platform as you're going to get with .NET.
Related
I intend to learn C# and start coding Windows .exe applications, but the only thing that is holding me back is that not all potential users have the .NET framework installed and therefore would be unable to run my application.
Is there any way around it?
Thanks!
No. c# only target .NET (or a comparable framework, such as mono). As an aside, Win7 comes with .NET preinstalled, and I believe Vista did as well. There are also a ton of MS apps which require .NET. It's getting near ubiquitous on windows machines, so I wouldn't worry about it.
YES, there was XenoCode that can wrap everything that your app needs and runs it in as a standalone. I don't know what kind of dirty tricks they use, but there IS a way.
Now it's Spoon
From their site:
Spoon Studio
Easily virtualize all of your applications for instant,
zero-install delivery on Spoon Server and Spoon.net.
Spoon Studio lets you convert your existing software applications into virtual applications
that run with no installs, conflicts, or dependencies.
BTW, I'm in no way affiliated with them - just curious if the community will accept it or flame it.
Yes, with .NET Native.
Instead of compiling to intermediate language, it will compile to native code and run with statically linked .NET libraries. Therefore, there will be no .NET Runtime requirements for end users.
https://msdn.microsoft.com/en-us/vstudio/dn642499.aspx
https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx
Does not work before Windows 10
C# is just a programming language. From a strictly technical point of view, someone could develop a C# compiler that targets the Windows API or <insert your target platform here> directly. Sure, it would be a lot of effort because C# was designed to fit .NET, which means the compiler writer would essentially have to re-implement .NET to provide all C# features.
From a practical point of view, you just want to use C# to target either .NET or Mono.
Microsoft started shipping .NET 2.0 with XP since 2005. So, even if your target machine was bought somewhere within the last 8 years, it should still have .NET.
If you are targetting the linux machines on the other hand, there is the mono framework available for that. You don't even have to include it, most repositories like ubuntu, debian, etc. has packages available for mono in their repositories. All you have to do is make your own package dependent on Mono runtime.
NO as simple as that
Everybody might say that it is already installed/ or you need the runtime. But that means YOU NEED IT
It's not about C#. It's about whether you want to develop managed or unmanaged applications. C# is the choice for developing managed applications which run on .NET Framework.
If you want to avoid it, you can go to Visual C++ (without .NET) development using Visual Studio
However, .NET framework comes pre-installed with latest Os like Win 7 these days.
Microsoft makes a redistributable installer that installs the version of .NET that you require. It bloats your install, but it's pretty much the only way to do what you need.
You'll need the .NET Runtime. However, most of the PCs running windows already have it.
I know WPF libraries aren´t implemented by mono class library, however(as far as I know) the mono 2.6 runtime is fully compatible with the .NET 2.0/3.5 runtime, so if the WPF libraries only make PInvoke calls to windows api it is theoretically possible to run a wpf application on windows using the mono runtime.
The reason for wanting that is deploying a wpf application as a standalone executable for windows. Has anyone tried something like that before? If so, what were the results?
In short... No
At this point, the Mono project does not have plans to implement Windows Presentation Foundation APIs as part of the project
Mono will provide Moonlight support which, from what I understand, would also use a subset of XAML to create its UI (the same as Silverlight does) but there are legal complications involved. Such as, it's limited to non-microsoft and non-mac platforms.
If you want to find a list of open-source cross-platform alternatives to WPF/XAML I'm working to compile a list of viable alternatives.
Well I did give it a try with little success. I first checked with corflags if required dll-s are implemented in mixed mode (PresentationFramework, PresenationCore, WindowsBase, System.Xaml). They are all pure CIL implementations so that should work fine with mono. Next I installed mentioned DLLs into mono's GAC and tried running a very simple WPF application. This is what I got:
Assertion at mini-codegen.c:1186, condition `reginfo [sreg].born_in
0' not met
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
So although in theory this should all work, WPF is probably way to complex to run out of the box on mono, it would be cool if there was a pure CIL implementation of WPF that was compatabile with both mono and .NET Framework.
As much as I know, Mono does not support WPF.
Also, WPF uses graphics modules and interacts directly with the GPU. So I can't see how u can use WPF with no hidden pinvokes.
Sounds like you need to read about WPF architecture to better understand it.
http://msdn.microsoft.com/en-us/library/ms750441.aspx
Many pieces are missing in Mono and solely available in .NET. Therefore, your "theory" is not correct, and you cannot run WPF applications on Mono, even on Windows.
At MIX 2010 Miguel de Icaza said in his session that Mono isn't going to support WPF. Anything tangentially related to WPF-like support is only to provide what is needed for Moonlight.
Not fully, but..
You can use Moonlight 4 ( silverlight 4 ) in a desktop mode:-
https://github.com/inorton/MoonBase - MVVM helpers
https://github.com/inorton/XamlPreviewer - XamlPad clone
i have a program written in visual studio 2008 c# which uses
System.Threading.Tasks.Paralell.For(...
now i want to run it in linux environment using mono, is it possible? if so how?
currently i have Mono Jit compiler version 2.4.2.3 , it cannot run the above program...
Mono 2.4.2.3 does not support Parallel LINQ. If you're not afraid of compiling mono from sources, I'd recommend doing that.
As you may know Thread management is very tied and closed to the underlying OS. The Mono team has not yet completed an implement of the TPL for Linux and I have some doubt that they will be able to achieve it soon as they have to implement it to every OS they support.
In fact you get the beggining of an implementation made during the Google Summer of Code 2008 by Jeremie Laval : http://code.google.com/p/mono-soc-2008/source/browse/#svn/trunk/parallelfx
You can get more info about this implementation here : http://blog.netmedia.info/2008/07/29/c-30-and-parallel-fxlinq-in-mono/
You could try the PFX implmentation by Jeremie Laval for Mono, but I have found that it is subtly different than the Microsoft implementation, so there may be some porting required to get things to work correctly.
That being said, another potential possibility (untested) would be to use the new Reactive Framework for .NET 3.5sp1, and see if it works on Mono. It includes a backport of the PFX libraries, in their current API. It may work correctly on Mono (but, as I said, it's not tested or supported there).
I want to switch over to Mono from .Net (plus Visual Studio to whatever IDE in Mono).Is this going to be really tough?
What are the issues I would face?
Thanks
As others have pointed out, I'm assuming that what you meant was moving from the .Net framework to Mono. With that said, the amount of difficulty you'll face depends a lot on what kind of code you are trying to move and what parts of the framework you use. For example, if your code is littered with P/Invoke calls, you're going to have a rough time. If it's straightforward .Net code you will probably have relatively smooth sailing.
You're going to want to spend some time with the Mono Migration Analyzer (MoMA). You'll run into things that aren't caught by the tool, but it will catch a lot of the basics and leave you free to tackle bigger things.
I believe Mono hasn't quite caught up with all the .Net 3.5 libraries and hence has either no or partial implementations of them. Mono will always lag a bit behind Microsoft, but it's a fantastic achievement and a brilliant piece of work.
have a look at the Mono Roadmap
Just to clarify, you can use visual-studio to compile in Windows, and run your apps in Linux. There's lots of chatter about this-or-that not being implemented in mono, but honestly I haven't found anything missing.
Now, if you want to debug in Linux (and eventually you'll need to), then MonoDevelop is a good option, but I've had trouble getting in running on RedHat, so it really depends on your target linux system.
I think you're making a confusion here.
Visual Studio is an IDE, while Mono is an implementation of the .net CLR.
I guess what you really want to do is switching over to SharpDevelop or another IDE.
It is probably as tough as switching from Windows to Linux. It is a different environment and switching will always involve a period when some things will feel slightly out of place. The same applies to the .Net -> Mono switch. The first and most obvious difference will be the IDE. As great as MonoDevelop is (or has gotten recently) it is not VS. It doesn't have as many features (most importantly no Windows Forms or ASP Designer) and the overall quality is probably not as high, but it certainly is enough to get you started.
Also, we shouldn't forget about things that Mono has and .Net hasn't like the C# interactive compiler or freedom to get involved in the platform creation. All things considered switching to Mono will require a certain effort but it is well worth it.
Visual Studio is a way better IDE than MonoDevelop where it automates many things are make MD seem like just an Editor (some like that). You can also use VS and target Mono which is a great opion. With virtual OSes, it's pretty well supported option on any host OS support by Mono.
Mono is close, but always will be a little behind the .NET Framework. Mono also is has it's own APIs that are better than anything in core .NET. But basically .NET == Mono at the binary level sans some missing or extra APIs.
I have some neural net code written in c# that would benefit from using SIMD support. Mono 2.2 just came out that supports SIMD but Microsoft's c# does not support this yet. Being happy with my c# setup I was wondering if I could write a lib in mono for that piece and call it from .net.
Edit:
I guess what I really want to know is it possible to compile mono down to something like a DLL that I then can call from dotnet. I heard Miguel de Icaza on a podcast saying that for the iphone the mono compiler would allow them to compile down to an exe for moonlight so it did not violate the terms of service for iphone so it got me thinking what else can you compile to.
I heard Miguel de Icaza on another pod cast Herding Code Episode 28 say that you could use the mono complier to compile to an exe not just to intermediate code. What are the implications of this?
This got my curiosity up so I thought that I would throw a bounty at it.
From Miguel de Icaza's blog:
Our library provides C# fallbacks for
all of the accelerated instructions.
This means that if your code runs on a
machine that does not provide any SIMD
support, or one of the operations that
you are using is not supported in your
machine, the code will continue to
work correctly.
This also means that you can use the
Mono.Simd API with Microsoft's .NET on
Windows to prototype and develop your
code, and then run it at full speed
using Mono.
As I understand it, this means that you can write code that uses Mono.Simd, and will be able to run it under .Net, but it won't be any faster than regular code, because the .Net runtime doesn't support SIMD yet.
Essentially, if you write it with Simd and distribute the dll with your code, it will use acceleration if the target VM supports it. If not, it doesn't break. So you can use the library and give any users of your program who run .NET apps with Mono a speed boost.
Microsoft has been said to be planning to add such support in its next release of its runtime, though I cannot find the link and don't have it handy right this sec---can dig the link out of a historic backup if anyone is interested enough.
In order to take advantage of SIMD features, the runtime should be able to natively support it. Basically, Mono treats Mono.Simd namespace specially in the runtime. Obviously, Microsoft .NET runtime does not support this feature. However, the Mono.Simd assembly provided is a completely valid and normal .NET assembly written in managed code and therefore it can run on .NET CLR, but it would be just a software emulation of what SIMD instructions do.
You can run Mono runtime on Windows and take advantage of those features but there is no direct way to run half of application on .NET and the other half on Mono (you could, of course, use communication mechanisms as two distinct applications can use, but it doesn't make sense for this scenario at all).