Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any chance of ".Net Core" for cross-platform? #5339

Open
felaugmar opened this issue Nov 28, 2016 · 71 comments

Comments

Projects
None yet
@felaugmar
Copy link

commented Nov 28, 2016

Hey, for now, Monogame's using Mono for targeting multiple platform.
My question is: Could .NET Core be used instead of Mono?

@SimonDarksideJ

This comment has been minimized.

Copy link
Contributor

commented Nov 29, 2016

A full .NET Core / Standard library wouldn't be possible as it doesn't yet support all the necessary API's for game development, such as Input, Graphics and audio, to name but a few.

However it may be a more compatible and viable alternative to the .Core solution that was being proposed a time back, given that .NET core projects are even more accessible that PCL's it may be more useful.

So @tomspilman @dellis1972 @KonajuGames What are your thoughts? Is there still an appetite to move all the platform generic code in to a central library in a future release (obviously not 3.6) and if so, does a .NET Core project sounds like a better alternative to a PCL.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Nov 29, 2016

.Net Core is still not quite there yet, few of the major problems that it has are:

  • No support for .config files so all the wrapper files would need to be compiled once for each system
  • No support for a lot of Linux distros
  • Most IDEs still don't support .csproj .Net Core projects
  • AFAIK Protobuild doesn't support generating .Net Core projects

Hey, for now, Monogame's using Mono for targeting multiple platform.
My question is: Could .NET Core be used instead of Mono?

I have seen so many of these questions, so my question for you is why would you want .Net Core support?

A full .NET Core / Standard library wouldn't be possible as it doesn't yet support all the necessary API's for game development, such as Input, Graphics and audio, to name but a few.

Mono doesn't offer any of that and we use it... that is not the problem with .Net Core.

However it may be a more compatible and viable alternative to the .Core solution that was being proposed a time back, given that .NET core projects are even more accessible that PCL's it may be more useful.

Comparing PCL and .Net Core projects is like comparing PCL and C# Library projects.

@gulbanana

This comment has been minimized.

Copy link

commented Jan 23, 2017

One advantage of .net core is that it's easy to embed a standalone clr/corelibs with a packaged app.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Jan 23, 2017

One advantage of .net core is that it's easy to embed a standalone clr/corelibs with a packaged app.

You can do the same thing with mono, just use mkbundle.

@gulbanana

This comment has been minimized.

Copy link

commented Jan 23, 2017

That's good to know, previously I'd only come across MonoKickstart.

@aienabled

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2017

Interesting read:
Building a 3D Game Engine with .NET Core
https://mellinoe.wordpress.com/2017/01/18/net-core-game-engine/

@RUSshy

This comment has been minimized.

Copy link

commented Feb 22, 2017

Performance wise Mono is far behind, .NET core is the future (and present), and is set to completly replace Mono

Would be cool to see more support for it

@cra0zy

This comment has been minimized.

Copy link
Member

commented Feb 22, 2017

All the problems I described above are still present :/

@cra0zy

This comment has been minimized.

Copy link
Member

commented Mar 9, 2017

Well I got MonoGame working with .Net Core today:
dotnetcore

Don't expect to see this in the repo until the problems I described get addressed.

@SimonDarksideJ

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2017

Fantastic news @cra0zy Although can you detail a little more what you mean by "working on .Net core"?
So is it a "core" version of MG, a Netcore project referencing MG as is, etc?

@cra0zy

This comment has been minimized.

Copy link
Member

commented Mar 9, 2017

I ported MonoGame DesktopGL to use netstandard1.4, it's pretty much the full version of MonoGame (except Song stuff, I had to cut that part out, see #5562).

Edit: Also the libs are hardcoded to LInux libs because of "No support for .config files so all the wrapper files would need to be compiled once for each system"

@SimonDarksideJ

This comment has been minimized.

Copy link
Contributor

commented Mar 9, 2017

An interesting start @cra0zy , would be interesting to see that also compiled against netstandard2.0 to see what other benefits it might garner.
Do you have a branch worth checking or is al local work?

@cra0zy

This comment has been minimized.

Copy link
Member

commented Mar 9, 2017

No branch, all local, I can send you the files, but it's nothing special. I do plan on getting some stuff fixed in the main repo so it's easier to integrate .net core later on.

@dsaf

This comment has been minimized.

Copy link

commented Mar 18, 2017

Isn't Xamarin going to properly support .NET Standard only starting with 2.0?

PS: thanks for the MonoGame PCL 3.6 - it's amazing!

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2017

I can find awfully little information about timeframes. Maybe @dellis1972 knows something we don't?

@cra0zy

This comment has been minimized.

Copy link
Member

commented Mar 18, 2017

I took a bit of time to fix up sound and upload MG .net core version: https://github.com/cra0zy/MonoGameCore

@dsaf

This comment has been minimized.

Copy link

commented Mar 20, 2017

This might allow using C# 7 tuples it seems dotnet/corefx#14235

Roadmap for .NET standard: https://github.com/dotnet/core/blob/master/roadmap.md

@Genbox

This comment has been minimized.

Copy link

commented Apr 2, 2017

Right now, it is pretty difficult to implement MonoGame in a cross-platform project that uses .NET core, as you have to target net45 everywhere to use it.

@dsaf

This comment has been minimized.

Copy link

commented Apr 2, 2017

@Genbox I am extremely glad to see Farseer coming back to life!

@cra0zy

This comment has been minimized.

Copy link
Member

commented Apr 2, 2017

The current major problem with MG supporting .net core is: dotnet/coreclr#930

There are several ways we could workaround it, but I would rather see it properly implemented in .net core.

@Genbox

This comment has been minimized.

Copy link

commented Apr 2, 2017

It took me 47 minutes to read all of that. Phew... that was not pleasant.
In a month, the issue will be 2 years old. I don't think we should hold our breath until an official solution for DLL mapping exist.

It seems that AssemblyLoadContext (part of System.Runtime.Loader) is capable of doing what you need. Create your own assembly loader that inherits from AssemblyLoadContext and override LoadUnmanagedDll. Then you have to call LoadLibrary (or similar) to obtain a handle, which you return. Since .NET Core uses AssemblyLoadContext.Default and not your assembly loader, subscribe to the AssemblyLoadContext.Default.Resolving event, which you can then pass your assembly loader on to.

[DLLImport("mylib")] would then result in a call to Resolving, in which you provide your assembly load context, which then maps "mylib" to the right DLL for the platform reported by the RuntimeInformation class.

It is a little more legwork than a simple .config file with the mapping, but it seems trivial to implement. @cra0zy what are your thoughts on this?

@cra0zy

This comment has been minimized.

Copy link
Member

commented Apr 4, 2017

@cra0zy what are your thoughts on this?

I currently know of 5 ways of "solving" this and the way I would prefer to do it is by overriding library folder and having a constant nameset for all the libraries. Alternative easy solution is just spiting DesktopGL into 3 assemblies (one for each platform) and #if-ing the const string for the lib name.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Apr 4, 2017

Side note, the 5 ways are:

  • Modify library load folder, set all library names to same name
  • Split DesktopGL into 3 assemblies
  • Nightmare you described :P
  • T4Template to generate 3 sets of functions
  • Separate assembly which just contains the constants and is added as a dependency const values get included in main assembly
@Jure-BB

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2017

I don't know if this is of any use here. There is a hack on Windows to load DLL with function LoadLibrary in static constructor or at the beginning of the program and DllImport will then use cached DLL that you already loaded manually. Example1, example2

Maybe this hack could be modified somehow to work on other platforms too?

@Genbox

This comment has been minimized.

Copy link

commented Apr 8, 2017

@cra0zy It certainly seems doable. I'd say the changes that are needed are small enough that it can be re-done if the .NET Core team ever decides on this issue.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Apr 8, 2017

@Genbox All the 5 ways I described make at least 1 new problem :|

@Genbox

This comment has been minimized.

Copy link

commented Apr 8, 2017

@cra0zy I certainly don't have the same insight into MonoGame as you have, so I defer that to you. However, working towards the .NET Core platform and being part of the .NET Standard is a big deal and will solve many problems that library authors have with targeting to different platforms.

@Thraka

This comment has been minimized.

Copy link

commented Jul 2, 2018

What about getting this to work with UWP?

@mrhelmut

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2018

Just to let you know that we successfully ported multiple full games to .NET Core and built them with CoreRT thanks to the work of @cra0zy!

It works very well. Performance wise, games start very quickly but gameplay performance are the same (which was to be expected in an AOT context).
But the real advantages of CoreRT is that it allows to obfuscate the exe, and most importantly, to produce standalone exe with absolutely 0 dependencies. Everything is statically linked, including the .NET runtime, and any MVC runtime as well.
This is super cool for shipping desktop games that work as-is.

I have only tested CoreRT on Windows for now, but this is surely something to keep developing.

On the other hand, I tried to AOT compile games using Mono, but to no avail. I'm still getting errors on native libraries marshaling producing IL code, but the main drawback of Mono is that even if assemblies are AOT compiled, Mono still requires the original IL assemblies to be present, which prevents the possibility to obfuscate them.

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2018

@mrhelmut That's awesome :) What about filesize? I found including the .NET runtime bloated the filesize by quite a bit. Any plansto write more about the process? (please take that as a question, not a request; I know you're busy)

EDIT: Is there any benefit to using Mono?

@mrhelmut

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2018

File size gets bloated, but not that much, about 10-15MB. That's very little compared to what BRUTE produce or even embedding Mono with MonoKickstart (which is the biggest overhead, ~55MB on Linux).

There's no benefit to using Mono, expect that it would allow to AOT compile games as a post-process. (Now that you mention it, I believe that I know why my AOT attempt failed: I tried to mono AOT assemblies built with the .Net compiler. I believe that building with Mono behave differently regarding delegate marshaling.)

Regarding the process, it was as simple as switching to @cra0zy .Net Core's template and MG branch, and target CoreRT.

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Nov 8, 2018

Neat :) Thanks for the quick response 👍

@cra0zy

This comment has been minimized.

Copy link
Member

commented Nov 8, 2018

You should be able to use ILLink.Tasks for extra size reduction.

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2018

Closing this in favor of #4975.

@Jjagg Jjagg closed this Dec 10, 2018

@cra0zy

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

@Jjagg #4975 is asking about a different subject.

@cra0zy cra0zy reopened this Dec 10, 2018

@Jjagg

This comment has been minimized.

Copy link
Contributor

commented Dec 10, 2018

@cra0zy It's all about moving the lib to .NET Standard. Though #4975 specifically is about replacing PCL. Maybe better to open a new issue 'Support .NET Standard' to replace both this and #4975.

@TheFanatr

This comment has been minimized.

Copy link

commented Feb 13, 2019

Just FYI, it is possible to run the latest version of MonoGame for Windows 10 desktop (which has it's templates currently targeting .NET Framework) on the .NET Core 3.0 Preview 2 runtime, as long as the newly-preview-released Microsoft.NET.Sdk.WindowsDesktop SDK is targeted in the project. I have it running in Visual Studio 2019 with C# 8 and it works perfectly. Templates for that specific part could be made already. As for supporting other platforms, something else needs to be done, but to reiterate, this is the vanilla MonoGame.Framework running on .NET Core for desktop Windows. No recompiling or refactoring of the MonoGame source needed.

Steps

  1. Create a project from the MonoGame Windows Project template.
  2. Replace contents of .csproj file with the XML from this pastebin.
  3. Have fun.
@cra0zy

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

Hmm... 🤔 , .NET Core is not supposed to be able to reference .NET Framework assemblies, so something is very fishy with that .csproj file. I'll wait till .NET Core 3 gets officially released to test stuff out.

@jkotas

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

.NET Core is not supposed to be able to reference .NET Framework assemblies

That is not correct. Read ".NET Framework compatibility mode" in https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/

@TheFanatr

This comment has been minimized.

Copy link

commented Feb 14, 2019

Last time I checked, .NET Core was always able to use a compatibility shim to access assemblies targeting .NET Framework.

@mrhelmut

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

It's a good hint toward the fact that it can run on .Net Core, but moving to .Net Standard still is the way to go to future-proof MonoGame and solve cross-platform deployment (as well as supporting CoreRT out of the box). Probably safe to wait for .Net Core 3.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

That is not correct. Read ".NET Framework compatibility mode" in https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/

Ha, interesting, didn't know about that, thanks @jkotas

@cra0zy

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

as well as supporting CoreRT out of the box

I'm somewhat interested in knowing if the @TheFanatr s project above can be compiled with corert.

@RUSshy

This comment has been minimized.

Copy link

commented Feb 14, 2019

there is a monogame sample on corert repo https://github.com/dotnet/corert/tree/master/samples/MonoGame

@cra0zy

This comment has been minimized.

Copy link
Member

commented Feb 14, 2019

there is a monogame sample on corert repo https://github.com/dotnet/corert/tree/master/samples/MonoGame

I know, @jkotas added it, it uses my .NET Standard MG DesktopGL assemblies XD

The point of above question is mostly to know if .NET Framework assemblies can be compiled with corert.

@quixoticaxis

This comment has been minimized.

Copy link

commented Mar 7, 2019

FYI DLLMap is coming to .Net Core. I didn't dig in, but I suppose people will find it useful: inability to manage native dependencies in runtime was mentioned as one of the blockers for .Net Core migration.

@cra0zy

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

Yea, MonoGame is already doing that except manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.