MonoGame.Extended UWP

Based on the description of installing MonoGame.Extended found here:

I was hoping I could use it as part of my development of an XBox One Monogame app.
However, when I go to NuGet and attempt to install the package, I get this for output:
Package MonoGame.Extended 0.5.149 is not compatible with uap10.0 (UAP,Version=v10.0). Package MonoGame.Extended 0.5.149 supports: net (.NETFramework,Version=v0.0)

I’m not sure what to do here. .NETFramework Version 0.0?
Is MonoGame.Extended compatible with Universal Windows Application development?

Hey @CoryKroll

To be honest I’ve never actually tested MonoGame.Extended with a Universal Windows App myself. However, I believe it should work. The more recent packages target a wider range of frameworks.

Try installing the latest pre-release package or building from source.

I followed the link to getting the latest pre-release, but I’m unfortunately still unable to bring in the NuGet package. I’ve included a screenshot with the Output log to show you what I’m getting.

I’m using MonoGame 3.5.
I open Visual Studio Community 2015, select New Project…
I select MonoGame > MonoGame Windows 10 Universal Project

Under the New Universal Windows Project dialog I choose:
Target Version: Windows 10 Anniversary Edition (10.0; Build 14393)
Minimum Version: Windows 10 (10.0; Build 10586)

As I said, I’ve not really used UWP myself.

But at a guess based on the screenshot I think it might have something to do with trying to mix .NET Core with .NET Standard libraries.

A little googling seems to indicate that you can change the target framework on your UWP project to something compatible. Although, I don’t really know how to do that?

MonoGame.Extended uses Profile111 .NET Portable Subset (.NET Framework 4.5, Windows 8, Windows Phone 8.1) which is compatible with .NET Standard 1.1

Check out for information on PCL compatibility with .NET standard.

Just as a follow up, downloading the deveopment branch installers fixes these issues, and Monogame works great with UWP.


I’ve got another issue. Since MonoGame.Extended uses .Net Standard libraries with Monogame.Framework.Portable referenced, I can not use MG.Ex in UWP. I’ve tested this issue on clean solution:

  1. created UWP project
  2. created .net standard library with Monogame referenced from Nuget package (Monogame.Framework.WindowsUniversal or Monogame.Framework.Protable)
  3. referenced my library in the UWP project

No matter which nuget package is installed in library, the compilation fails with different error. It only works when I manually add monogame DLL installed on my machine, the same which is referenced in UWP project.
Can anyone explain this in some logical way? My only idea is that both Nuget packages (Monogame.Framework.WindowsUniversal and Monogame.Framework.Protable) are PCLs and I can not reference PCL in .Net Standard lib. If so, the only way is to use PCL project library instead of .Net Standdard…

I vaguely recall someone else reporting a similar issue once before. Although, I can’t remember the exact details.

My understanding is that it’s actually more to do with the way NuGet resolves references than anything else.

Unfortunately, I don’t know of any way to fix this issue. The best you can do is work around it by manually referencing the DLL yourself like you mentioned or perhaps compiling MonoGame.Extended yourself and turning it into a library that can be referenced from UWP (I’m pretty sure someone else did this once).

There’s nothing that I’m aware of in MonoGame.Extended’s actual code that prevents it from being used in UWP. Only the quirks an limitations of the various target frameworks, NuGet packages and the NuGet package manager.

That said, if anyone comes up with a better solution to this I’d love to hear about it.

I get that as a warning with UWP, but it doesn’t error out.
A few things that might help:

  • Be sure your UWP project is targeting the latest version. I think past targets don’t have .NET Standard compatibility. I’m running UWP with these NuGet packages targeting 1903
  • Make sure you don’t have Visual Studio reporting warnings as errors