Alright, so doing that got the normal MGCB editor to open and successfully build a “bin” and “obj” folder into the Content folder in the project directory.
It is not copying that folder over to the ProjectRoot/bin/Debug though.
This is definitely much closer though, was there anything you did to allow MGCB to copy the Content/bin folder to the bin/Debug folder?
Edit: also the Content folder in VS is not showing the newly added content even though it is there in the normal file explorer
After you opened the Content.mgcb in the editor, were you able to run the build command?
if so, can you check the lines one by one and check the folder that is being used for the output xnb files?
I found sometimes the folder is something else and that can cause your mgcb file to build in the wrong location. I guess it is building in wrong location.
Check the mgcb file in notepad if you can… the top part should have something like this:
#----------------------------- Global Properties ----------------------------#
/outputDir:bin/$(Platform)
/intermediateDir:obj/$(Platform)
/platform:DesktopGL
/config:
/profile:HiDef
/compress:False
#-------------------------------- References --------------------------------#
the reason that it may not be copying the files is the outputDir
One thing I noticed that didn’t happen before, is that when I build in Debug or Release, I do not get the xnb files compressed, it used to compress them in release but somehow not doing it, I need to dig more into it, it used to do it automatically with 3.7.xxx but after moving to 3.8.xx it is not.
My output and intermediate directories look the same but the others look different
/outputDir:bin/$(Platform)
/intermediateDir:obj/$(Platform)
/platform:Windows
/config:
/profile:Reach
/compress:False
The build does work within the editor and it does build the files.
These are the properties within the editor for Content:
But as you can see, even after building and rebuilding the solution it still isn’t copying it over to the Debug bin:
Though the build .xnb files do appear in here:
Edit: after doing some comparison between the MonoGame.Forms project and a normal MonoGame project. It seems like the MGCB is building the same. It doesn’t actually build to the debug bin. It looks like the problem is with VS when I build the solution there.
When I build in the normal MonoGame project it will create the Content folder with the built content while in the Forms one it will not copy it.
Have you tried a simple monogame game with nothing and build it?
I guess there may be something wrong with the project you are using.
Yeah, normal MonoGame projects work. Right now I am using the MonoGame.Forms template from the VS Marketplace:
Okay, well for anybody who is having the same issue as me, this is A solution:
<ItemGroup>
<Content Include="Content\bin\Windows\*">
<Link>Content\bin\Windows\%(RecursiveDir)\%(Filename)%(Extension)</Link>
<TargetPath>Content\%(RecursiveDir)\%(Filename)%(Extension)</TargetPath>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>
I went into the .csproj file and added a this code which takes the built directory of Content and adds it to a subdirectory called Content to the output directory. The code snippet should go somewhere within the tag.
Also, I know this is probably not the best way to do it so if there is a better way, please post it. I hope this helps anyone who was having the same troubles as me!
Hey all, I had a lot of trouble with MonoGame.Forms so I made this little guide for others who might also struggle with using it in the future!
1. Add the Extension
This extension is available for Visual Studio. It contains project templates and templates to create a new MonoGame Control class:
2. Change the Namespaces
By default, the MonoGame.Forms template starts you out with the namespace “MonoGame.Forms.DX” which is not our project’s namespace.
Before:
After:
You need to change the following files’ namespaces:
For Windows Form designer classes, you will need to right click and select “View Code” to change their namespaces:
I’m not sure if these properties’ namespaces need to be changed because it works without changing them, but I usually do:
You will probably still see this error if you try to open the form inside the designer:
You actually haven’t done anything wrong, all you need to do it build and it will open correctly.
After it is built, close the tab with the form and now open it back up. It should look something like this:
3. Add the MonoGame Configuration Folder
In order to be able to open the MGCB editor and for it to build, you will need to add a folder called “.config” to the project. The easiest way to do this is to copy the folder from an existing MonoGame project.
If you want to add it manually, then create a folder called “.config” and add a file called “dotnet-tools.json”
Inside the file, add the following text:
{
"version": 1,
"isRoot": true,
"tools": {
"dotnet-mgcb": {
"version": "3.8.1.303",
"commands": [
"mgcb"
]
},
"dotnet-mgcb-editor": {
"version": "3.8.1.303",
"commands": [
"mgcb-editor"
]
},
"dotnet-mgcb-editor-linux": {
"version": "3.8.1.303",
"commands": [
"mgcb-editor-linux"
]
},
"dotnet-mgcb-editor-windows": {
"version": "3.8.1.303",
"commands": [
"mgcb-editor-windows"
]
},
"dotnet-mgcb-editor-mac": {
"version": "3.8.1.303",
"commands": [
"mgcb-editor-mac"
]
}
}
}
The version may vary so the best thing to do would be to copy the “.config” folder from an existing MonoGame project.
4. Add the Build Tasks
In order to get Visual Studio to build the content of the project and add it to the output folder, you need to edit the “.csproj” file. To do this, you need to unload the project by right clicking the project and choosing unload:
If the “.csproj” file doesn’t open automatically, double click the unloaded project. You can add the following tasks anywhere inside of the “Project” tag:
<!--Start of the extra build tasks for Content-->
<ItemGroup>
<None Include="Content\**" />
<PackageReference Include="MonoGame.Framework.WindowsDX" Version="3.8.1.303" />
<PackageReference Include="MonoGame.Content.Builder.Task" Version="3.8.1.303" />
<PackageReference Include="MonoGame.Forms.DX" Version="3.0.0" />
</ItemGroup>
<!--End of the extra build tasks for Content-->
For example, it can go right at the top like this:
If you are using a repository system like git, comment out or delete the following lines:
The reason for taking out that line is because if you use this project in a repo and clone to a new location, it will throw this “error” even when the build would work otherwise. Not quite sure why…
Save the “.csproj” file and then reload the project by right clicking on the project and pressing “Reload Project”:
You will probably see two “Content.mgcb” files. These are actually the same file so don’t try to delete one.
If this bothers you, you can comment out or delete this line:
If you are interested in what each line is doing here is why:
This line allows you to view your content inside the Solution Explorer:
Without it, you would only see the “Content” folder with the “Content.mgcb” file inside even if there are other files or folders inside:
Before:
After:
Note: after adding content, usually the files won’t show up in the solution explorer until you unload and reload your project again. Don’t worry, they are there, Visual Studio just isn’t showing you them
These lines tell Visual Studio to make the MGCB Editor build your content:
The version might vary for you so if you want to make sure, create a DirectX MonoGame project and copy these two tasks from that projects “.csproj” file:
This line includes the MonoGame.Forms.DX package. Normally this isn’t needed but if cloning from a repo to a new location, it will think the NuGet package for MonoGame.Forms.DX is missing and you would have to install it again through NuGet manager. This does what NuGet would have done but it is a bit easier since you are already in the “.csproj” file.
This shows what it should look like if you view the NuGet package manager:
…and that’s it. Yeah, it’s a pretty long process but now you can create a Windows Form using MonoGame as a control!
Here is the short version of all the completely necessary steps:
Thanks to @MysticRiverGames for helping me understand how to add the “.config” folder, DKR for the stack overflow answer on “missing” but not actually missing NuGet package error, and @BlizzCrafter for making this tool in the first place!
If you have any corrections or suggestions please reply!
Have a great day! -ReBuff
Hey ReBuff!
Thanks for adding this post with your findings here. I will take a closer look and see were I can improve the process of installing and using the MonoGame.Forms library.
Normally the process should already be very easy and it should work right out of the box, but I will test it again on different machines to make sure.
I also have the plan to move the project to .NET 6 in the future and therefore I need to update the templates anyway.
However, I am currently very busy and I have also very busy times ahead. Probably I can do it at some point this year, but I can’t promise that.
I wish you and everyone else here in the community a very nice day and thank you very much for using MonoGame.Forms 
:: BlizzCrafter 
MonoGame.Forms is build on the KNI framework.
What you had to do was to update the nuget to the latest version and install the KNI-sdk (MGSetup3.x.9xxx.exe) which contain the building tools.
By porting the template back to MonoGame you are loosing Mouse input, two thirds of performance and a handful of other fixes.
Hey Community,
I just wanted to inform you that I created a Net6 version of MonoGame.Forms. It is on a seperated branch for everyone to try out.
Here it is:
Also please take notice of the current issue with generating a working nuget package for Net6.
Here it is:
I don’t have discovered any problems with the Net6 port itself so far.
If you nevertheless encounter one, then please open an issue on github for it.
Thank you very much for your support and have a nice day!
Cheers
Now that MonoGame.Forms is available on Net-6.0, I thought about a little experiment:
Blazor + Winforms + MonoGame.Forms
This is a Windows Forms project - modified to be a Blazor project which can host MonoGame.Forms controls.
And all 3 techniques combined, you have a nice way of modernizing your Windows Forms and MonoGame.Forms projects, because you can utilize the full functionalities of Blazor by using a Blazor-WebView, which is available as a package here:
In the moment there seems to be a bug, which makes it impossible to give the Blazor-WebView control a transparent color. As soon as this bug is resolved it would be possible to use the Blazor-WebView control as a full overlay, which would give even more design capabilities.
In the demo video above you can see that I only use the web view component as a docked-to-the-top control to act like a navbar with additional controls to interact with MonoGame.Forms.
The Blazor-Branch is located here:
Enjoy and have a nice day! 
Cheers,
:: BlizzCrafter 
Wpf Support ?
Nope, this is only for Windows Forms.
Without your input & suggestions the MonoGame.Forms library wouldn’t be as feature-rich and good as it is today.
Take care and have a nice time!!
Hi! Are there plans to support KNI in the Forms project?
tl;dr Always has been 
MonoGame.Forms used the nuget builds of my fork long before I got it rebranded to KNI.
Mostly because of the Mouse.WindowHandle fix.
I’ll put the question in another way: is Monogame 3.9.9001 planned to be supported? I have a class library. which refers to KNI 3.9.9001. She categorically refuses to work with Forms (I get the error: “Could not load type ‘Microsoft.Xna.Framework.Graphics.SwapChainRenderTarget’ from assembly ‘MonoGame.Framework, Version=3.9.9001.0, Culture=neutral, PublicKeyToken=null’.”)
SwapChainRenderTarget is accessible only by the WindowsDX library.
if I had to guess I’d say that the MonoGame.dll from some other platform found its way to the \bin\ folder.
In libraries I use the following code in the .csproj to stop the references from ‘leaking’ into the project
<PackageReference Include="nkast.Xna.Framework.Ref" Version="3.9.9001">
<PrivateAssets>all</PrivateAssets>
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>
However 3.9 has a new structure, with the core types moved to a separate dll.
That requires all 3rd party libraries to be recompiled for 3.9.
I’ve not tried the new KNI version so far, but I will in the future and then report back.
Globally apply an antialising render target:
protected override void Initialize()
{
ControlState += ApplyAntialising;
}
private void ApplyAntialising(object? sender, ControlStateEventArgs e)
{
if (e.ControlsState == NET.ControlState.StartDraw)
{
Editor.BeginAntialising();
}
else if (e.ControlsState == NET.ControlState.EndDraw)
{
Editor.EndAntialising();
}
}
This is espacially useful when working with Components. Before this update it was only possible to have either a MonoGame.Forms.Control or one GameComponent at the same time on the antialising render target or rather on render targets in general.
Of course you can use this new event system for many more things!
Have fun :))
PS: This update is only available on the Net6.0 version of the library.