I’m working on a MonoGame project that contains applications for Android, iOS, and all PC platforms that MonoGame supports. Does it matter whether I choose .NET Framework, .NET Core, or .NET Standard?
Core is cross platform
.NET Standard is a target for libraries and can be used with any of the .NET runtimes: .NET Framework, .NET Core, Mono or even Xamarin for mobile. If you have a common library with all the game logic, then I recommend you target .NET Standard with that project.
For your per platform projects (you need 1 for desktop and two more for Android and iOS) the target depends on how you want to distribute your game. For mobile you need to use the Xamarin toolchain. For desktop things are a bit more complicated. On Windows users have .NET Framework already installed, so you can distribute your game without a .NET runtime by targeting .NET Framework on Windows. The .NET version will determine what windows versions your game will run on. I think .NET 4.0 runs as far back as XP and up while 4.5 runs on Vista and up (but not 100% sure about that). Now, you can include a runtime with your game as well, but your game will be a little bigger.
For Linux and Mac, there’s no runtime that comes with the OS, so typically a .NET runtime is bundled with the game so users don’t have to install one and can potentially run into compatibility issues. That runtime used to be Mono, but with .NET Core things have become a lot easier. With a build flag you can build your game into a single executable that includes the runtime for the platform of your choice. So I recommend you go with .NET Core for Linux and Mac. If you don’t care as much about the size of your game, you can also use this method to build your game for Windows. It saves I think something like 20-30MB.
Is MonoGame.Framework.DesktopGL.Core built from @cra0zy’s own fork? I was under the impression that the official recommendation for Linux and Mac was still to use Xamarin. However I see the current templates in the develop branch reference MonoGame.Framework.DesktopGL.Core, but I don’t believe that’s published from the official MonoGame repo. This whole interaction seems odd to me.
The templates that reference cra0zy’s .NET Standard fork are in the repo, but the core repo doesn’t support .NET Standard yet (there are some complications). You’re correct that the MonoGame.Framework.DesktopGL.Core build is not official.
I don’t mean to call anyone out, but that sounds like bad practice for a number of reasons. Now we have official templates that use an unofficial version of the framework published by an individual community member. And to address the main question of this thread, it seems like the recommended .NET runtime would largely depend on if you use the nuget packages or want to build the framework yourself from source, which would cause pain for anyone who wants to switch from one to the other and struggles to find the source for the .NET Core package.
No, the official templates that get installed when you install MG do not use the Core version. They’re still the old ones. The unofficial templates are just already in the repo. And cra0zy is a maintainer of MG. The new dotnet templates will become official once the official MG fully supports .NET Standard, that was always the goal.
Not at all, I’m not sure where you got this from. I explained why I would choose .NET Core vs .NET Framework in my previous comment.
EDIT: Ah, I misunderstood, and think I understand you now. You can use either version using NuGet, but I get that the current situation can be confusing.
I know cra0zy is a maintainer and a trusted community member – I meant it more as a philosophical argument that it seems unusual for the recommended approach to be to use an unofficial fork. I was unaware that the unofficial templates don’t get installed.
To clarify my point about which runtime to use: it’s easy to use .NET Core if you rely on cra0zy’s nuget, but if you start a .NET Core project and then decide you want to build the framework yourself, it might be hard to track down the source of package and realize you actually need to clone a different fork.
The only thing that the fork has left at this stage is just a custom .csproj file, I guess I can submit that upstream but it can’t be connected to the build bot, until the build bot gets updated.
Maybe we could do a partial .NET Stanard support until Protobuild removal is done.
I’m in favor of that. I believe the MonoGame.Content.Builder stuff is also missing, although I wanted to talk about that separately because I accomplished the GetMGCBTask with standard
PackageReferences which I believe is more robust. Maybe I’ll start a separate thread on this, as I’ve been merging those pieces into my own fork and making some updates over the last few weeks.
The PR for MGCB nuget has been up for some time but no one got around to merging it: https://github.com/MonoGame/MonoGame/pull/6295
EDIT: It looks like this comment may be irrelevant as I see the new csproj’s rolling in!
By the way, while I’m thinking about this topic, I’m not sure if the community cares but I don’t think the Core package follows standard naming conventions.
Core is used for packages that have full packages and core subsets, without implying anything about the target framework. For example:
- Microsoft.AspNet.WebApi vs Microsoft.AspNet.WebApi.Core
- System.Data.SQLite vs System.Data.SQLite.Core
The convention I’ve seen for indicating a .NET Standard target is
NetStandard. For example:
- DiskQueue vs DiskQueue.NetStandard
- Apache.NMS vs Apache.NMS.NetStd (also note Apache.NMS.Core only support netcoreapp2.0)
I think this convention helps avoid confusion by specifying that the library targets .NET Standard and supports .NET Core, .NET Framework, Xamarin, etc., rather than just Core. That being said I don’t feel super strongly about this, but just wanted to see what people thought.