SolvedMonoGame [Todo list] Future-proofing MonoGame

Hey there!

Many efforts have been started to future-proof MonoGame and make it a modern .Net framework but it seems that there is no comprehensive centralized point where to understand how things should move forward and their current state.

Hence, I'm trying to maintain this issue to keep track of the different tasks. Please feel free to point me to any untracked tasks or progress.

I guess that we will agree on the following main objective: making MonoGame fully .Net Standard 2.0 compliant in its entirety (all targets, all of its tools, and its build/test/package process), while maintaining a backward compatibility where it's relevant.

This would mean: being able to consume MonoGame as a dotnet (Core) framework, and as a full .Net framework.

So here comes the long list. @cra0zy @Jjagg @tomspilman please let me know if this list makes sense to you and if there's anything more to say about the current state of the repository.

Moving to .Net Standard 2.0 (and .Net Core compatibility):

  • Removing Protobuild & switching to SDK-style project format #6207 #6768 #4975 #6604
    • MonoGame.Framework
      • Windows DirectX
      • Windows UWP
      • DesktopGL
      • Android
      • iOS
    • Archive MonoGame.Framework.Net to a dedicated repo (#6900) ->
    • MonoGame.Framework.Content.Pipeline
      • Windows
      • macOS
      • Linux
    • Tools/2MGFX
      • Windows/macOS/Linux
    • Tools/MGCB
      • Windows/macOS/Linux
    • Tools/Pipeline
      • Windows/macOS/Linux
    • Remove Protobuild and any file/folder related to it
  • Making all tools Dotnet Tools and packaging them as nugets (and make the templates to use them)
  • Making Core templates (that uses global tools) and publishing them as nuget for dotnet new -i #6930
    • Windows DirectX
    • Windows UWP (not .net core compatible)
    • DesktopGL
    • Android (not .net core compatible)
    • iOS (not .net core compatible)
  • Making all targets dotnet build/publish compatible #5339 -> WindowsDX and DesktopGL support dotnet build; others require full MSBuild so they can't be built with portable MSBuild that dotnet CLI uses.

Getting Team City continuous integration to work again:

  • Tests (content pipeline tests should be moved to dedicated test projects)
  • Building and publishing all targets as nugets #6773

Keeping a compatibility toward full framework users:

  • Defining which backward compatibility target(s) make sense beside netstandard2.0 (net4? net45? net451?) => net452 that is
  • Making traditional non-Core templates (that would be packaged as a VS extension along with the tools they would rely on?) for full framework users (not relevant anymore)
  • Allowing to install non-Core tools & templates to MSBuild when building from source (e.g. auto-deploy target at build time) for full framework users (not relevant anymore)
  • Packaging project templates into a Visual Studio Extension so that templates can be distributed without the need of an installer


  • Update the Getting Started documentation for setting up projects for all targets
  • Update the Publishing & Packaging documentation for distributing apps on all targets
  • Document how to build MonoGame from source code and debug it


  • Removing the installer #6842
  • Dropping irrelevant targets
    • macOS (should be integrated into DesktopGL after VideoPlayer has been implemented there -> #6860)
    • Linux/WindowsGL (is equivalent to DesktopGL and should be renamed/removed) -> naming is because of Protobuild, the SDK-style project is named DesktopGL.
    • Windows Phone? (already dropped)
    • Web (not maintained)
    • tvOS (not maintained)
  • Remove obsolete IDE extensions
  • Remove obsolete nuget nuspec
  • Remove obsolete zip templates and build F# templates
  • Make the Cake script to output all nuget artifacts to the same folder (e.g. ./ouput or ./build once protobuild is gone)

Bonus stage for console targets (which unfortunately can't be discussed publicly):

  • Keeping VS2015 and net45 non-SDK style projects while being compatible with the parent repository structure (deprecated)
  • Refactoring MGCB and Pipeline to find console targets
  • Enforce C# 5.0 language version
52 Answers

✔️Accepted Answer

Thanks to everyone's effort lately, especially harry-cpp and tomspilman, MonoGame is getting super close to a new release embracing the new distribution model.

All that is left to do is making the Content Builder Editor (previously named Pipeline tool) a global dotnet tool, and updating MonoGame's website to reflect the new distribution model with some documentation (and ideally a VSIX extension to provide project templates for non CLI users).

Other Answers:

So after giving this some thorough tests, TieredCompilation and Ready2Run are the culprits. Disabling them makes .Net Core as smooth as other runtimes.

We'll have to make sure that these are in the templates:


The misleading part here is that disabling tiered compilation makes the JIT to generate Tier1 code, which is the slowest to generate but since most of the generation happens at the startup, it runs way smoother because tiered compilation is not around anymore to promote Tier0 code to Tier1 at random times.

Using Ready2Run is even more misleading, because the AOT parts of it are actually Tier0 code, even if tiered compilation is disabled. Which means that the JIT still tries to generate Tier1 code instead. So better not using Ready2Run to avoid the extra bits.

I'm closing this issue since everything is done!

The team is wrapping up a few remaining works that will lead to a 3.8 release (soon, but no ETA).

We currently cannot use C# 7 because the AOT compiler that's used for consoles does not support some of the IL that newer language versions generate.

We're working on that issue currently and hope to resolve it in the coming months.

Honestly, if MonoGame got that netstandard2.0 love, it would be a huge step forward.
.NET Schedule
The development (except security patches) on the .Net Framework will soon stop and .Net Core will practically become it's feature-enriched predecessor, becoming the new .Net 5 which can utilize either the Mono or .NET Core runtime, meaning that it will be supported based on the runtime's platforms.
MonoGame + .Net5 would be a dream from cross-platform development 😃

More Issues: