MonoGame Modularisation

Times are changing and now that the latest milestone release of MonoGame (V3.2) is out. there has been a lot of taking stock actions on the GitHub Site.

Old PRs and issues are being validated and closed, a clearing house of sorts to separate the wheat from the chaff as it were.

If you have old issues that are no longer relevant on the GitHub site, please close them so the team knows what to focus on and fix. Help with the clean-up.

The first part of this new world order is a first stab at adding modularisation to the MonoGame framework in much the same way that traditional XNA was separated into several DLLs.

What Did XNA Ever Do For Us?

As part of the delivery of XNA, each focal area had its own namespace and its own library. This helped when you only wanted certain portions of the framework or wanted to replace parts of it with your own. This is what XNA looked like in the end:

• Microsoft.Xna.Framework.dll
• Microsoft.Xna.Framework.Avatar.dll
• Microsoft.Xna.Framework.Game.dll
• Microsoft.Xna.Framework.GamerServices.dll
• Microsoft.Xna.Framework.Graphics.dll
• Microsoft.Xna.Framework.Input.Touch.dll
• Microsoft.Xna.Framework.Net.dll
• Microsoft.Xna.Framework.Storage.dll
• Microsoft.Xna.Framework.Video.dll
• Microsoft.Xna.Framework.Xact.dll

This design ensured that each component was totally responsible for its own area, each depending on the core Microsoft.XNA.Framework DLL only. This allowed you to pick and choose which parts of the framework you wanted to use and more importantly, also allowed you to replace core parts of your project with alternate frameworks while still reusing the same base types from the XNA framework.

The Farseer physics library was a great example for this where it used the XNA base class and struct types in its XNA/MonoGame implementation.

And So It Begins – Welcome MonoGame.Net

With the latest change, MonoGame too has started down this path of separating each component into their own respective libraries in answer to a lot of comments around this area. It is also good for the framework because things become easier to test the smaller they are and we can be sure that changes in one feature are not going to have unintended consequences in others.

One thing to make clear is that the MonoGame team will only separate the framework into separate components where it makes sense to MonoGame. It is highly unlikely we will see as much separation as XNA had, just that which benefits the long term goals of the MonoGame framework.

The first of these new modularisations is the MonoGame.Framework.Net library which encompasses the following namespaces:

• Microsoft.Xna.Framework.GamerServices
• Microsoft.Xna.Framework.Net

They are bundled together in one library because they are so intertwined and dependant on each other, with this separation also comes an additional benefit that MonoGame.Framework is no longer dependant on LidGren, only the new MonoGame.Framework.Net.

What Does This Mean for MonoGame Contributors?

If you currently contribute or are working on a PR for the repository, make sure you do a fresh pull in to your clean develop branch and test your improvements against the built version of that.

NOTHING has changed in the setup of the MonoGame directories or files, just that some namespaces are part of a separate DLL, most remain as they were before.

Before submitting any new PRs, I’d recommend creating a new branch for your submission and copy over your changes, before pushing it and creating a PR. Better to be safe.

If you’re new and looking to contribute, be sure to check out my Git Contributor article here – might update it soon to talk about working and publish branches.

What Does This Mean for MonoGame Users / Adopters (post V3.2)

This first change should not impact your project at all unless you are using the networking or GamerServices features. If you do, then just add a manual reference to the new MonoGame.Framework.Net library.

If you are using the existing MonoGame v3.2 installer, then nothing will change until you update to a later release!

Future releases will still ship with LidGren and the new MonoGame.Framework.Net libraries but they will not be part of the default (new) project templates. If you want them, then just add a reference to each lib by browsing to the MonoGame installed assemblies directory, e.g.

C:\Program Files (x86)\MonoGame\v3.0\Assemblies

Updates and Releases

There’s no confirmed date as to when the next MonoGame installer will be released but there is a general feeling in the team to move to a more regular update schedule (since everyone else loves continual delivery ) but keep your eyes on the MonoGame main website for future updates.

As for NuGet, once things have settled, I will get a new develop NuGet package out which will include these changes so you can test them out for yourself.

A Final Call to Arms

Now both in MonoGame and its split off cousin FNA have taken this move to separate out the NET namespace from their frameworks, the main reason for this is that it allows some focus to break the dependency on LidGren itself. There’s nothing wrong with LidGren - it is a good networking framework but some people don’t like it or generally prefer to use something else, this is where you, the budding developer community, can come in.

There has been a request to separate out a XNA/MonoGame/FNA Networking library and set of corresponding components into its own deliverable and its own repository. With the aim of creating a more generic networking framework for all XNA based games and with the ability to host behind it just about any pluggable networking framework.

Are you up to the challenge? Or fancy taking on this project? Then get involved and get talking, the entire XNA / MonoGame community is listening and waiting.