MonoGame.Forms - Create your Editor Environment!

MonoGame.Forms 2.3.7

  • Refactored Camera2D component.
  • Added public float DefaultZoom/DefaultRotation/DefaultPosition properties, so that it’s possible to reset these values to specific default values.
  • Added overloads to the ResetCam method, so that it is possible to reset specific camera values like Position, Zoom and Rotation.
  • It’s now possible to quickly set the default values of the camera to the current ones with SetDefaultsFromCurrent().
  • Added Buy me a Cola-Light support button.
  • Added a GitHub Sponsor button.

MonoGame.Forms is now 21 month old and recently reached over 20.000 views here in the MonoGame community. This makes it the second most viewed thing in the “Showcase” topic.

Additionally we achieved 9.868 downloads of the library on nuget.

So, it’s time to raise a glass or two :cocktail::tropical_drink::beers::champagne: :grinning:

Huge thanks for your ongoing support and furthermore happy editing! :two_hearts:


  • Marcel

A bit of a side note, since I realized I never mentioned it, I have published Gtk version of MonoGame for quite some time (sorry @SpiceyWolf, I know I hijacked the package from you). Gtk for those of you who don’t know is a GUI toolkit mainly used by Linux apps, however it works under Windows and Mac as well. To try it out do:

# install templates
dotnet new --install MonoGame.Template.Gtk.CSharp

# create project in current dir
dotnet new mggtk

# run project
dotnet run

(On Windows you need to install Gtk beforehand:

@SandboxBlizz Some of my random thoughts.

  • We could make an Eto.Form control
  • you can specify the MonoGamePlatform property in the nugets themselves
  • you can compile content during runtime by using MG.Content.Pipeline dll file found next to the Pipeline Tool, its what MGCB/Pipeline Tool actually use to compile content
  • What are you doing regarding input handling, if anything? With Gtk version I made a limitation of only 1 active control so I fully implemented input handling based on widget position and focus
1 Like

I remember seeing that Gtk version of MonoGame somewhere. I believe it was on GitHub. But I haven’t tried it so far.

  1. An Eto.Forms version of MonoGame.Forms would be a great addition, because our GL implementation would be slower than a more “native” multi platform integration through the original graphics context rather than just converting the back buffer to a bitmap like in our case.

  2. Oh, never thought about that, but this is a nice idea. So the end-user has less pre-setup to do before using the library. Now that you addressed this, I think about setting up a seperate .targets file which also imports the MonoGame.Content.Builder.targets file and includes a basic MonoGameContentReference file (.mgcb). I’m sure one could also create a template for this, but I never did that so far and would need to read a bit into this topic.

  3. Yeah, personally i’m using the MGCB.exe in a different project to do this. I’m not sure how I would implement this in the MonoGame.Forms library for the end-user so that it would makes sense in his editor project. I now it’s possible to directly use the MG.Content.Pipeline.dll and make the content compilation available without an extra tool. Maybe I could write a helper class for it and let the user decide how to use this functionality.

  4. It’s the same for MonoGame.Forms. Only the control with active focus receives input from the user. We are using the original input functionality from the MonoGame.Framework for mouse, keyboard and gamepad interaction. The DX version utilizes a nice little keyboard trick using reflection (@nkast showed it to me first ;)). The GL version uses the SDL-Input capabilities from the MonoGame.Framework by using SDL.PushEvent() (same for mouse input). The DX version receives mouse input by setting the window handle to the control handle as soon as the mouse enters the specific control. We put that not in the initialization of a control to avoid null pointers, when the user disposes the specific control in a multi viewport application. To make this available we needed to refer to an older PR from nkast and merge that with a custom build of the MonoGame.Framework, because this PR wasn’t merged with the original source so far.

Can you point me to your Gtk repo if available? I would be happy to link that in our README.

I also saw that the GitHub repo of the MonoGame.Framework has a support button now. I will update the MonoGame.Forms repo with this additional support url soon.

Thanks for your input!

BTW: I’m not experienced with Eto.Forms, so I would need to read into this topic too. I think we would need something like an EtoViewport for GL rendering which gets the graphics context from the MonoGame.Framework (SDL). Is there something like that in existence? Because then such an implentation would be not that hard, I think.

For now the Gtk version lives in my fork but I’ll try to get it into main repo once again at a later point:

1 Like

As a small update on this:

Turns out it was easier than expected. Visual Studio 2017 templates are now available for Windows, Mac and Linux (Windows and DesktopGL templates):

Visual Studio

They are completly pre-setuped to jumpstart the editor creation process. So they include all necessary libraries (nuget), the MonoGame content response file (.mgcb) included as a MonoGameContentReference and the MonoGamePlatform based on the selected template.

The MonoGame.Content.Builder.targets and MonoGame.Common.props are imported as well (like it would be when the user creates a new MonoGame.Framework project).

I also included a SampleControl which inherits from MonoGameControl of MonoGame.Forms to demonstrate the general usage idea of the library.

If the user builds and runs the solution he should be greeted with this welcome screen:

It shows the content of the SampleControl.

Template Source:

1 Like

Tested on visual studio 2017, worked perfectly first time.

Well done.

1 Like

MonoGame.Forms 2.3.8 - Combined NuGet-Packages

  • Now importing the MonoGame.Content.Builder.targets and MonoGame.Common.props file and setting the MonoGamePlatform property in all files (DX, GL). @harry-cpp
  • Added MonoGame.Content.Builder content/libs/nuspecs/targets for DX and GL platform.
  • Added combined NuGet-Packages which containing pre-setuped .mgcb files and the corresponding toolset as well as a custom MonoGame.Content.Builder.targets file to build MonoGame-Content.
  • Added new doc image to visualize the available nuget packages in the readme:

To comply with the recently added Visual Studio templates, now there are also NuGet-Packages available which containing all necessary files and setups to build content with the MonoGame-PipelineTool to make content compiling a breeze:



These packages are containing both, the library and the content builder, so you can install the complete setup in one go.

I created seperate packages to still allow library-only-installations just in case content compiling is not needed by the end user (like the sample projects in the repo. They are containing pre-compiled content for example).

There is still a difference between the combined NuGet packages and the VS templates; the templates containing a sample control, which demonstrates the general usage idea of the library. The NuGet packages are full ‘skeletons’.

Hope you’ll have fun! :wink:

Have a nice day,

PS: The regular NuGet packages also containing properties like the MonoGamePlatform and they are also importing MonoGame targets and probs files, just in case the user started with these libraries and wants to integrate the .mgcb file in a later state. So he really just needs to include this file and is ready to go!


@SandboxBlizz Neat project!

I am testing it out and have a basic project going.

I am running into a minor issue where I am currently using a slightly modified version of the Monogame DLL (I have a PR with my changes still pending review and merge) which doesn’t quite work when I swap out the monogame DLL that comes in the nuget package with my modified one.

If I use your DLL, then my code doesn’t compile. If I swap out your DLL for my DLL, then everything works and runs, but the form designer no longer works.

On the github page, you mentioned that you are using a modified version of the Monogame DLL. Can you clarify what changes you made?

The weird thing is, the code compiles and runs with my Monogame DLL, but the form designer won’t work.

Hey @YTN and thanks!

Yes, you can’t easily swap the MonoGame.Framework in the moment.

Are you using the DX or the GL library?
What error are you receiving when you try to open the form designer?

@SandboxBlizz Thanks for the reply!

This is the DX version.

There was an option to ignore the error which allowed the form to render. Now I can’t get back the original error. I do get a different error now whenever I change or set any properties for the Monogame control. The error I get when I try to save after changing the property is “Code generation for property GraphicsProfile failed. Error was ‘Type Microsoft.Xna.Framework.Graphics.GraphicsProfile is not available in the target framework’”

The only way for me to modify and save the form properties is if I restore the original DLL (which means I can’t compile my code). I then switch back to my dll in order to build and run.

Would it be possible for you to build me a new Monogame.Framework.dll with this PR integrated?

This will have the changes I need so I can use the form designer and build and run without issues.

The PR should be fully backward compatible, so shouldn’t impact any existing behavior if you leave it in.


@SandboxBlizz Separate question… my current framework can draw directly to the screen (GraphicsDevice.SetRenderTarget(null) ) or to a rendertarget which I can then draw on the screen.

I tried shoehorning that into MonoGame.Forms, but I don’t get anything displayed. I suspect it’s because my framework is setting the rendertarget back to null (physical screen) when it’s done, and that’s breaking your stuff.

Are you using a RT internally?

If so, how do I get access to your RT?

How does MonoGame.Forms work with existing frameworks that usually have direct access to the GraphicsDevice?


I think I will push the modified source of the MonoGame.Framework to the repo, so you can modify it for your own custom build as you wish.

But I currently don’t know when I have time for it. Maybe during this weekend.

Yeah, this don’t work like this in MonoGame.Forms. You would need to set the render target back to the SwapChainRenderTarget: GraphicsDevice.SetRenderTarget(SwapChainRenderTarget)

You can generally find alot of hints/examples/explanations in the wiki:

Like for your problem:

There is also a RenderTargetManager, which simplifies work like that:

@SandboxBlizz Thanks for the details!

I figured out my RenderTarget issues. The only thing left is the dll problem.

If you could upload your modified MonoGame source to GitHub, I’d be more than happy to build my own modified version with the PR I submitted.

Thanks again!

The source is now up:

Sorry for the late reply.

@SandboxBlizz Thanks! I built a modified version of the DLL with your modified Monogame code and my PR and it works great!

1 Like

@SandboxBlizz Hey mate. I added MonoGame.Forms to MonoGame Awesome when I added MonoGame.WpfCore because I think they are both equally awesome projects.

I was surprised it wasn’t in the list already :smile:

1 Like

Thank you very much @craftworkgames :thumbsup:

It’s also nice to see a modern Wpf implementation. Good work :slight_smile:

1 Like

Just wanted to inform you what i’m currently working on.

It’s the Runtime Content Compiler (RCC) for MonoGame.Forms (suggested by @harry-cpp) . It’s a WIP but I thought it would be nice to share my current state and what decisions I made. So, let’s start!

Helper class or re-implementation?

I originally thought about how the implementation of this thingy would look like or rather what would be the best possible way of having the RCC integrated into the MonoGame.Forms library.

I started creating a simple helper class which interacted with the original MGCB and the PipelineManager from the MonoGame.Framework.Content.Pipeline namespace. It worked but I was not satisfied with it because a couple of reasons:

  • It was a “Single-Task-Job” and you needed to wait till it’s finished.
  • It was not customizable.
  • It cluttered the output with MGCB binaries in every project - regardless if they use the RCC or not.
  • [insert more issues here] :wink:

However, I rethought everything and came to the idea / conclusion that it would be way nicer to integrate the original MGCB class (BuildContent.cs), the PipelineManager (and adjacents) and re-implement it at least asynchronously and as a seperate project which can be installed per NuGet on demand.

This also has the advantage, that the RCC will have all the original features of the MGCB as well as its exception- and log system.

So, I decided to go that route and just created a small wrapper around it, which is easy to use by the end user and very practial in a MonoGameControl, but still works independently from the MonoGame.Forms library - yup, that sounds nice®.

The Prototype

I already created all the basics. Take a look:

I picked a bunch of .jpgs & .pngs and let the RCC do the rest. You don’t need to set importers or processors for regular content, because it will fallback to the default ones based on the extension of the raw content - thanks to the features of the original MGCB!

Basically you can do everything what is possible with the MGCB now and the content compilation happens asynchronously - that’s why I wanted to re-implement all the pieces.

The Release Date

I think during this week.

Still need to do a couple of things and general cleanup. The MonoGame.Forms version to be expected is 2.4.0, which is the next milestone (we are currently at 2.3.8).

See you then and have a nice day!

-Marcel | Sandbox Blizz


BTW: The Visual Studio templates went pretty well. In about 2 Months we received 2,477 installs :tada:

Thank you very much for your ongoing support!


MonoGame.RuntimeBuilder - out now!

The MonoGame.RuntimeBuilder builds your raw content asynchronously to the .XNB format during runtime.

This library is a part of the MonoGame.Forms project,
but it is fully usable without the MonoGame.Forms library!

Hello Com,

The basic work on the RuntimeBuilder is done and depsite the fact that it is a part of the MonoGame.Forms familiy ( :sweat_smile: ), it don’t need to live in the MonoGame.Forms repo or library. It’s generally usable as a standalone library to build your own tool with runtime content builder functionality - hurray :tada:

Using the MonoGame.RuntimeBuilder is fairly easy:

// Creating the property.
private RuntimeBuilder _RuntimeBuilder { get; set; }

// Initialize the RuntimeBuilder.
_RuntimeBuilder = new RuntimeBuilder(
                Path.Combine(Application.StartupPath, "working"),           // working directory
                Path.Combine(Application.StartupPath, "working", "obj"),    // intermediate directory
                Path.Combine(Application.StartupPath, "Content"),           // output directory
                TargetPlatform.Windows,                                     // target platform
                GraphicsProfile.Reach,                                      // graphics profile
                true)                                                       // compress the content
                Logger = new StringBuilderLogger()                          // logger
// Pick Files & Build Content.
private async void ButtonPickFiles_Click(object sender, System.EventArgs e)
    if (openFileDialog.ShowDialog() == DialogResult.OK)
        await _RuntimeBuilder.BuildContent(openFileDialog.FileNames);

And… that’s it!

Read more on GitHub!

Of course it’s also available on nuget:


Feel free to follow me:

Twitter Follow

I wish you a happy day! :smiley:

-Marcel | Sandbox Blizz

1 Like

:four_leaf_clover: Yesterday, Friday the 13th, was my lucky day (it has always been my lucky day) :four_leaf_clover:

I got 2 beta invites on this special day:

I’m telling you this mainly because of the GitHub thingy. As a result packages of all my libraries are also available on GitHub now!

These are the packages of MonoGame.Forms.
These are all packages currently available on my GitHub profile.

Have fun checking these out!

I wish you a nice and lucky weekend! :four_leaf_clover: :wink:


Follow me for the extra portion luck in your life:

Twitter Follow

( lol )