I've been looking at Roslyn for quite some time now, and I'm curious and excited about it. One thing I noticed is that they mentioned that the compiler is re-written in managed code. This raises the question of whether Roslyn is able to run on non-.NET virtual machines, such as Mono.
I would really love to embed C# scripting using Roslyn in my video games, and to use many of their other features in my applications, but I'm wondering if using Roslyn will break the ability for it to run on Mono.
Has anyone tried running Roslyn on Mono? Is it possible? Why or why not?
To clarify, I'm interested in both whether the managed assembly can run on Mono, and whether it can generate assemblies that mono can run.
Despite it being the furthest thing from Eric's mind, Roslyn has been released as true Open Source (Apache 2.0) and is in fact now cross-platform.
Miguel de Icaza of Xamarin showed it running on Mono at BUILD.
When Roslyn releases, it will become part of Mono. They are already maintaining a branch at the Mono Git repo.
As #Govert has already mentioned in a comment, if you want to embed C# scripting capabilities you should simply use the Mono-equivalent library/tool: Mono-Csharp. (Especially because, even if Roslyn could run on Mono, its licence may dictate that you're not allowed to.)
This tool in the Mono world has existed much earlier than Roslyn BTW, and is open source. Here you have even a Microsoft employee blogging about it and uploading it to Nuget:
http://blog.davidebbo.com/2012/02/quick-fun-with-monos-csharp-compiler-as.html
I hope your game will kick ass!
Related
I am currently using Manjaro Linux 20.2, with official JetBrains Rider from JetBrains Toolbox
I have installed this package package screenshot
When I'm writing in my terminal "mono" it runs.
File location also looks fine.
When I'm opening my Environment tab in Rider. I got this.
Environment Tab
I can create and run/execute/debug any projects with my .NET CORE
But I can't use the framework at all.
A simple application like this New Project Window
And here... the error
In my settings -> build and execution -> I have these parameters
path settings
I don't know what to do and how to fix this error. Tried many times disinstall/reinstall the Mono Package. But it's always the same.
Maybe I should change somehow a Mono path here in Rider Settings ?
But I don't know to where.. there are so many of these files in usr/lib and usr/bin
Please help me, I don't know what to do next and how to fix this..
I just know for sure. That it is possible to run Mono on UNIX.
Something is wrong..
UPD1: I've discovered, that to run Mono on Linux. I should install a different package "monodevelop"
But according to GitHub, this package is not build-able on Linux anymore (only on MacOS)
I've discovered this "dotdevelop" package..
https://github.com/dotdevelop/dotdevelop
But I don't know, it's looks like it doesn't work for me either.
Or maybe I'm just putting a wrong file to my mono path settings in Rider..
UPD2: Maybe there is still hope for me, if I'll use .NET FRAMEWORK from inside a container ?
https://hub.docker.com/_/microsoft-dotnet-framework
I know how to use Docker. It will be possible to use it in my Rider ? I don't get it.
This answer essentially has what you're looking for. There is an issue in recent mono packages for some distributions that causes Rider not to have a proper reference to the mono libraries.
JetBrains Rider not detecting mono or Unity API
I've tried this on Debian 11 and it works as expected. I also use an Ubuntu machine and I didn't have to do this. I'm not entirely sure why, all I know is that some distros need the override set in in order to work. I use KDE Plasma and used their method of setting environment variables. There's a million ways to do that, check Majaro's documentation for what's best for your system.
**Before reading below, be aware that we're talking about legacy software and there's no guaranty that Mono will work in the future since it has been superseded by .NET (core). New development should be done there rather than Mono/.NET Framework unless you really need to. Just be aware it's legacy at this point and ymmv.
As for the other comment that there is no .NET Framework on Linux, that's not completely true. Mono is the .NET Framework implementation for Linux and macOS. It supports a large portion of the .NET Framework that exists in the Windows version, however it has some drawbacks.
For instance, WinForms is only partially supported and extremely buggy. WPF will not work at all.
ASP.NET can be run under Apache with a plugin, however it doesn't support all of the frameworks that you can use on Windows. For modern .NET web development on non Windows platforms, .NET 5+ should be used.
Another weird one is that the Console.Beep() method works unreliably. The Console.Beep(int frequency, int duration) method also doesn't work on macOS at all.
Other than those examples, there's other things that won't work which are mainly things that rely directly on the Windows API though it's possible to run .NET in some capacity under WINE. This isn't recommended though. Anything that uses COM will not work as well. It's also practically impossible to use a printer so that's probably out.
You can review https://www.mono-project.com/docs/about-mono/compatibility/ for a better list of what is and isn't supported.
For console applications, mono works quite well. Just be aware that not everything will work.
Good luck!
You should create a console application by choosing "Console Application" under ".NET Core".
I wonder why Rider guys decided to show the projects under ".NET" to mess things up. Beginners like you won't be easy to know what they are and how to run them on non-Windows machines.
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).
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.