Struggling with Content Pipeline file/folder references

Content
1

So, my biggest hurdle with MonoGame is incorporating the Content Pipeline into my projects. It’s useful for many reasons. I know that. But what’s the “correct” way to use it?

I’m working on a game that targets multiple platforms. I want to have all of my assets in a shared project and simply have the mgcb reference the files. While this is technically possible, the actual folder structure that is created does not match that of the shared project.

For example, given this folder structure:

MyProject.Droid
--> Assets
----> Content
-------->Content.mgcb
MyProject.Shared
--> Content
----> Textures
--------> PlayerTexture.png

the result after compilation is this:

MyProject.Droid
--> Assets
----> Content
--------> MyProject.Shared
------------> Content
----------------> Textures
--------------------> PlayerTexture.xnb
-------->Content.mgcb

What’s the correct way to achieve a folder structure like this?

MyProject.Droid
--> Assets
----> Content
--------> Textures
------------> PlayerTexture.xnb
-------->Content.mgcb
2

You can specify the output folder in the pipeline tool, if you remove the bin from the start of output folder does that achieve it?

3

Sorry for the confusion. I always change the output folder to be ./ so that everything is copied to the Content folder instead of the bin folder. MGCB simply creates the bin and obj folder, regardless of what you actually have set as the Output Folder. I’ve updated my question to remove the bin and obj folder.

4

You should be able to set the output dir in the .mgcb to whatever you want, relative to the mgcb location. For example, …/…/Droid/bin/AnyCPU/Content/

For multiple platforms, I’m not sure of the best way. We used separate mgcb files per platform as we had slightly different sets of content. You might be able to use the {Platform} tag in your paths or a post copy step in bat files.

5

Also you can have multiple mgcb files pointing to the same target folder. We split our content into two sets: files that depended on the game assemblies (i.e. xml mostly) and those that didn’t. This can significantly reduce build times.