MonoGame Deployment Issues...


I have recently returned to researching the use of MonoGame for a military simulation framework I am currently developing.

Having decided early on to use another engine that was quite easy to use, the word is out at that development site that support for this engine may be halted as the team is interested in going in other directions. This is most unfortunate since this little engine is quite capable and rather easy to use, especially for 2D development work. Nonetheless, that community is getting frustrated by the fact that those who use this engine appear to be getting short the end of the stick and are starting to look for other environs.

I have worked with MonoGame in the past and never really had an issue with its deployment or its capabilities but I did leave the community since the engine was so raw and lacking in such basic tools as a GUI for such development. However, coming back now, it appears that many things have changed.

Admittedly, I am still working with the .NET Framework Version 4.6. I have done this as I find the standard .NET Frameworks more reliable as they are not subject to the ongoing changes and feature refinements that Microsoft is constantly making to the .NET Core Frameworks.

And I understand the MonoGame Development Team’s interest in maintaining currency with the latest frameworks that are on offer from Microsoft.

However, for those of us that are still in the midst of developing their projects, upgrading to a new framework is just not in the schedule currently due to the costs in time and effort. As a result, I chose to review the earlier versions of MonoGame that are still reliant on the standard .NET Frameworks. At least for the time being until I can devote the time required to upgrade the 10+ projects that make up my current development endeavor.

As a result, I initially selected MonoGame 3.7.1, which would allow me to work with the 4.6 .NET Framework.

I installed the binaries as instructed only to find that the Pipeline Content Builder tool(s) were not in the deployment of the binaries. As a result, I decided to build it from the corresponding MonoGame source code.

Well, that didn’t work due to the fact that one, the source code, like I found out, did not have any of the relevant solution and project files to allow one to load the required projects into Visual Studio.

OK… I did some research and found that the MonoGame Team was using for this version of the MonoGame source, a tool called ProtoBuild, which the team stated on the forums they were no longer supporting. Instead, what was being supported was the DotNet Cake Build Tool.

Well, I tried both and neither one worked. And I tinkered with both tools trying out every configuration I could imagine to get the solution and project files generated.

Eventually, I found a posting in the forums demonstrating that there were issues with the 3.7.1 source builds and that there was no current work-around for them.

Wouldn’t it have been simpler for all concerned to simply not offer the 3.7.1 source as a download until someone fixed these issues or at the very least leave a note on the download page?

I decided then to work with the 3.4 source download since I found another posting put up by a developer who decided to currently stick with MonoGame 3.5 since he had found that the versions released after 3.5 suffer from too many issues.

I imagine this comment was related to deployment issues and not the MonoGame Engine itself since it has always been considered a very fine game development engine.

With the 3.4 source I was nearly able to get the entire set of projects compiled with the exception of the Pipeline Content Tool. The ProtoBuild tool worked as expected and all of the solution and project files were generated.

However, like all of these MonoGame source code projects, the biggest issue is figuring out the various dependency issues that each included project has as they relate to the framework versions being used. But no matter what I did I could not get the Pipeline Content Tool compiled cleanly. This left me with a decision as to whether I should continue my efforts with MonoGame since I wanted the complete working capabilities of the MonoGame Engine and to me the Pipeline Content Tool was an important aspect given its image loading efficiencies.

I nearly decided to give up on this endeavor when I cam across a post on the forums that described that the deployment of the Pipeline Content Tool binaries were made to the “Program Files (x86)\MSbuild” directory.

Imagine going through several days of compiling attempts to only find that everything I needed and wanted was simply placed in directory few would have suspected. Why is this?

I mean why would the MonoGame installation not deploy all of its binaries into the corresponding MonoGame directory under the “Program Files (x86)” directory. Is there a special reason for this? I can’t imagine what it would be except to mess with developers’ minds. The “MSBuild” directory, to me, is where the Visual Studio compilers place their build data. Interestingly enough, on my system, there is not really much of note in this directory at all, no matter which “Program Files” directory you look at.

I have been at this profession since 1974 and I have to say that the quality of the output of the Open Source Community when it comes to documenting its work has been rarely stellar. It appears that since everyone now relies on the Internet for everything, people have gotten very lazy as it regards quality documentation for the products being put out. Nonetheless, with a piece of software such as MonoGame, the documentation should rival such products as the Open Source Database Engines.

When I release a product, the user knows exactly how to use it with the documentation provided.

One would think that with an exceptional piece of development such as MonoGame, current users, newcomers and returnees could and should expect concise documentation that corresponded to the version being used.

Instead, the community is left with the forums to figure out their issues, which is quite a mishmash of old and new postings across a number of categories that makes research a difficult process.

Now, it is true that the MonoGame Development Team is made up of primarily volunteers leaving them probably with a limited amount if time to devote to all the necessary requirements of product development. But at the same time, poor documentation and an erratic forum structure only detracts from the reputation from the product itself.

Isn’t it possible to get community members who are adept at MonoGame to assist in documenting it in terms of use (We still do not have a single book available on MonoGame since the community is directed to rely on decades old XNA documentation for such purposes.) as well as cleaning up the forums where issues are on a per version basis.

It seems to me as a senior software engineer that there should be some consideration of plans to work on the documentation aspects of this fine engine, which it truly deserves. Because right now, and I have done extensive research on this subject, the entire game development environment is a complete mess with some of the lesser known engines providing better documentation on deployment and use that one would expect from the MonoGame product…

Here is a summary of the web page:

  • MonoGame Deployment Issues: The author shares their experience and frustration with installing and using MonoGame, a game development engine, on different versions of the .NET Framework.
  • Problems with MonoGame 3.7.1: The author describes the difficulties they faced with building the Pipeline Content Tool from the source code of MonoGame 3.7.1, which was not included in the binary installation.
  • Solution with MonoGame 3.4: The author explains how they managed to compile most of the projects from the source code of MonoGame 3.4, except for the Pipeline Content Tool, which they later found in a different directory.
  • Suggestions for MonoGame Documentation: The author criticizes the lack of quality documentation and forum structure for MonoGame, and urges the development team and the community to improve them.


Hi, Umm while there is no notice as of yet, this forum is closing soon, for a response to this kind of topic I might suggest a forum post on the discord forum/channels for the time being.

Can you clarify what you are asking and which Engine are you speaking of?

MonoGame is a Framework, not an Engine.

Which project are you speaking of?

Hell Mr. Valentine…

I am not sure how to answer your questions since I was quite specific in my post.

In any event, to me MonoGame is an engine, since its capabilities are limited to graphics, audio, and some input capabilities. A framework to me is something like the Stride Engine that allows you to work with different components and interfaces.

.NET is a framework as it provides a host of tools for just about any type of development one could need.

Interesting to hear that the MonoGame Forums may be closing soon. But I do have access to the MonoGame Discord Server. However, there does not appear to be much activity there that I have seen…

Steve Naidamast / Sr. Software Engineer

Most people just lurk, use the Forum channel to create a forum post, and then link a link to it in the Help channel, I could not read anything above, it was too vague, I read half of it before realising how enormous the post was.

Open Source Databases usually have dedicated teams or at least more than 6 people working on them more than free time based, MonoGame is entirely voluntary based, and only just became a Foundation with some actual funding.

3.9 is on the horizon.

Good luck in uhh not sure what was being asked frankly.

I recognize that the MonoGame Development Team is voluntary and I stated as such in my post.

Nonetheless, MonoGame, as fine a product as it is, is sorely lacking in quality documentation for proper deployment, source compilations, and usage guides on how to implement game development efforts with it…

I started a wiki for that sole purpose while the documentation is updated, mostly there is just an API thing, which frankly I have no clue how to navigate half the time.

If I can help direct you to some resource, what would you be looking for?

1 Like

I figured out what I needed to accomplish.

Right now, all I would have wished for is that I had not spent several days researching how to compile MonoGame when everything I needed was in a directory few developers would have thought of…

Uhh, where was that.

Good show.

1 Like