MonoGame 3.8 Android Content Builder failure

Under MonoGame 3.8 with VS2019 the Content builder fails if there is no file called "Content/Content.mgcb.

Unhandled exception. System.Exception: File 'C:\PATH_TO_PROJECT\Content\Content.mgcb' does not exist.

Steps to reproduce:
Use Visual Studio 2019 to create a new Android MonoGame Project.
Delete Content Folder
Build (fails)

Steps to compare previous version of MonoGame:
Use Visual Studio 2017 to create a new Android MonoGame project.
Delete Content Folder
Build (succeeds).

If I remove the Nuget package for

MonoGame.Content.Builder.Task

Then the project will now compile but there is no content available (from a shared project that contains the actual Content.mgcb file).

Is this a bug or am I just doing it wrong?

I’m not sure I understand. You’re saying you have

  • an Android project
    • reference to MonoGame.Content.Builder.Task
    • no mgcb file
    • no MonoGameContentReference
  • a shared project
    • mgcb file
    • MonoGameContentReference

Is that right? And this builds in VS 2017 but not 2019?

With my setup, even with a shared project I still manually add this to the Android project:

<MonoGameContentReference Include="..\Content\Content.mgcb" />

Hi and thanks for replying.

I’m trying to figure out how to have an Android project use the .mgcb files from a Shared project using Visual Studio 2019 and MonoGame 3.8.

Therefore the Android project does not have it’s own Content folder or .mgcb file.

The problem is that as soon as I delete the Content.mgcb file from the Android project, the build for that project fails with the message:

Unhandled exception. System.Exception: File 'C:\PATH_TO_PROJECT\Content\Content.mgcb' does not exist.

This exception seems to be caused by the (new to 3.8?) MonoGame.Content.Builder.Task nuget package, it seems to assume there will be a file at that location when there isn’t and crashes if it isn’t there.

So if I try to remove the MonoGame.Content.Builder.Task nuget package from the Android project, the project can then build. The trouble then is that the .mgcb files from any shared projects are not copied over, causing a crash at runtime.

This is all entirely different to how it was in the previous 3.7 release of MonoGame, using Visual Studio 2017. I would simply create the Android project and delete the Content folder, then reference any shared projects I wanted and automatically any .mgcb files from any shared projects would be copied to the output and available to the Android project.

I hope that’s a clearer way of putting it?

Do you know how I can fix it? There is some manual hacking of the csproj file I have to do now?

If you right-click on the Android csproj and edit it, you should see a line like this towards the bottom:

<MonoGameContentReference Include="Content\Content.mgcb" Visible="false" />

If you deleted the Android project’s contents but you still want to build content (with the Builder.Task package), you must update this line to point to your shared Content.mgcb file, relative to the Android csproj. For me, that path looks like this:

<MonoGameContentReference Include="..\Content\Content.mgcb"  Visible="false" />
1 Like

Thank you this is very useful information indeed.

It’s a shame as this used to work so beautifully. I don’t suppose you happen to know why this manual hack of the csproj file was introduced into the latest version of MonoGame?

I didn’t realize it used to pull in shared content like that.

To me, editing a csproj file is a common part of developing an app and not at all a hack; and it seems natural that if you delete your content and want to build different content as part of your project, then you’d have to edit a setting in the project. So I guess I don’t see this as an issue, but if there’s a way it could work better than maybe we can try to restore the behavior that you’d seen in previous versions.

I see, well to me personally I’d say editing a configuration or a manifest file is fair game, whereas csproj and sln files are visual studio files, that visual studio maintains (like auto generated code) and usually if you have to edit them then something has gone quite badly wrong.

The removal of MonoGame.Framework.Net in the 3.8 update has similarly perplexed me. It might not have had much in the way of functionality, and that functionality might even have been misleading but anyone with an XNA project could use it to have a buildable game with minimal changes quite quickly.

What happened to the .Net “pit of success”?

This is to take nothing away from the talented and enthusiastic MonoGame developers, I take my hat off to all of them, what they have achieved is truly remarkable in bringing XNA back from the dead.