Project size, Monogame needs to do sport

I just did a migration from XNA to Monogame and what i see is just mind breaking.
The original XNA project folder have a size of 447mo.
The new Monogame project folder have a size of 934mo.
And nothing have changed inside the code (well maybe there is now a hundred of new characters but not more) and i didn’t add any asset.

Someone can explain why is it happening ?

Delete the bin and obj folders in your project then rebuild and recheck the size. It is likely old build configurations for XNA.

Thanks, it was that in a way but in the end it didn’t work.

To be clear, i created completely new monogame project and i basically copy/pasted my code in and imported 2D assets .

Why these folders were created ?

And secondly, after building the project, these folders were recreated again to replace the ones i just deleted.

But it’s weird to have these folders because i didn’t added them to the new Monogame project.

Those are standard build folders. When compiling an application in visual studio (or similar IDEs) the compiler will first create the /obj folder where intermediate program objects are stored. Once compilation of a project is complete, it outputs the binary file to the /bin folder from where it can be ran.

If you need more information on that, read up here:

It seems fair but with old XNA, you need half size for same result.
Yes, that sounds like Monogame needs assets twice (it’s totally that because there’s same content twice in folders).
That is really odd.

It is most likely compression settings on some of the assets. Compare the sizes of the XNB files in the XNA output to the same files in the MonoGame version’s output.

Exactly same size. So ? Sorry I don’t understand what i should do or how it should be.

We’re trying to determine which part of the game is so much bigger. Is it the content? The assemblies? The data? Only you can tell us in more detail which parts of it are so much bigger.

This is my project folders and you can see my issue.

You have

Drone - Bin
Content

the stuff in the bin folder here is your actual game, the content folder inside there is where your game is looking for graphics and fonts etc…

The Content folder in the drone root is your content pipeline. Its what converts the files to the xnb… you shouldnt have to delete it, its basicly instead of putting the content into a whole separate project like xna did. In this case the content pipeline ALSO creates an obj and bin folder just like visual studio does with an application where it build your pngs or other game files into xnb files.

Like MrEmo said about the bin and obj from vs, it makes your files and moves them to a bin folder… just in the monogame case, theres an afterbuild process that copies them AGAIN to your physical applications compiled directory which appears to be in Bin/x64/debug

Ok i understand the principle.
But my problem is still present.
It could be great if Monogame doesn’t double size of a project if you build it.
Xna project didn’t double project like that.
My whole project (content files and content pipeline also) was about 450 Mo after a build with Xna and the exact same whole project is 950 Mo with Monogame afteer a build.
It’s disappointing.

just wondering. What is the reason the size of the project in the development directory to the point to consider it disappointing?

I would understand it’d be a problem if the final installation had a 2x space growth, or if the memory used by MG would be twice the memory used by XNA (which in fact, happens in WP8).

The only reason I could think of is backup time, but you could add the dummy directories to the excluded list (I do that with all the obj/ and bin/ directories in my development drive)

@MonoGame team and contributors:

why not considering adding links to references ? At least for platforms which handle symlink like all Unix* + windows > 7.

I can imagine why MS do the best they can to makes us use as much resources as possible (especially hard drive space), as:
-dll are supposed to be SHARED, MS with .net/XNA just forget this basic concept
-nuget is even worth in this matter, to allegedly promote user’s laziness, they decide to waste more and more disk space (as nuget packages are ONLY common to the solution they are added to)

It would be great if also MS do this (one day when they finally stop messing with their very own customers!): put/assume libraries are in given place (like /usr/(local)/lib and all on Unix*), and system use the location to get them at runtime.

For the original post, there appeared to be confusion because they were measuring the size of the entire project tree, not just the output folder. Therefore they were including the intermediate files in the calculation, which have no effect on the final size of the output folder.

There is the GAC (Global Assembly Cache), which is where common .NET Framework and some other signed assemblies are placed. Assemblies like MonoGame are not good candidates to go into the GAC though because it is still a very fluid project and developers can build their own copy of MonoGame.

System locations for shared libraries are fine if those libraries do not change very often, and for when application installers don’t write their own versions of the libraries over them. DLL Hell is often referred to for Windows, but Lib Hell is a very real problem for *nix systems as well (I’ve been going through it at work a lot recently).

Games should never install their own libraries into system locations on the user’s machine. XNA could be installed as a runtime because once released, it never changed. As stated before, MonoGame is still quite fluid and developers can build their own version at any time with any changes they want.

If you are talking about the development process, the MonoGame installer does install into a common location that projects reference into. During the build process, the required libraries from MonoGame are copied into the output folder to ensure that all required libraries are available to the application at runtime in a known location that does not affect any other application on the system, and they are all of the required version that the application was built with.

1 Like