MonoGame Content Pipeline Tool Doesn't Build XNBs

It certainly generates a .xnb, but it ends up in the obj directory because the output directory and intermediate directory are back-to-front in the .mgcb file.

/outputDir:obj/$(Platform)
/intermediateDir:bin/$(Platform)

That should be

/outputDir:bin/$(Platform)
/intermediateDir:obj/$(Platform)

With projects created from the latest templates, you don’t need to change anything with the Build Action or Copy to Output Directory properties. The project is already setup to build and copy the content output to the relevant place in the project output directory.

Even after those changes it’s still not doing anything for me. Nothing happens when I click Build.

I had the same thing just now. It gives no output whatsoever. Restarting my PC fixed it… then it happened again, restarting my PC didn’t fix it that time. Restarted my PC a third time and it was fixed… kind of makes me scared to use this tool.

What are you building? Are effects included? Can you post your .mgcb file when the tool doesn’t work? What MG version are you using, some work was done recently so there was some unstable behavior at times.

It’s version 3.5.1.1679, according to the About MonoGame Pipeline Tool dialog.

I created a new Windows project called Game1, double-clicked Content.mgcb in VS which opens up the pipline tool. I added one file to it, I don’t think the file type matters as I’ve tried with a .wav and a .png and they had the same problem. I’ve attached the png, it was called debris.png and I tried saving it in the root Content folder, or creating a subfolder for it, with the same results:

I’ve tried switching between HiDef and Reach profiles, no difference. Click Build or Rebuild, it asks me to save the project, I click Yes then nothing happens. Try again, nothing happens. Clean works though.

Here’s the entire contents of my mgcb file:

#----------------------------- Global Properties ----------------------------#

/outputDir:bin/$(Platform)
/intermediateDir:obj/$(Platform)
/platform:Windows
/config:
/profile:HiDef
/compress:False

#-------------------------------- References --------------------------------#


#---------------------------------- Content ---------------------------------#

#begin debris.png
/importer:TextureImporter
/processor:TextureProcessor
/processorParam:ColorKeyColor=255,0,255,255
/processorParam:ColorKeyEnabled=True
/processorParam:GenerateMipmaps=False
/processorParam:PremultiplyAlpha=True
/processorParam:ResizeToPowerOfTwo=False
/processorParam:MakeSquare=False
/processorParam:TextureFormat=Color
/build:debris.png

(I’ve been trying to convert my XNA project to monogame having quite a few issues, I may post some more of them later).

Hmm, in that case it really should work… You can try to install a newer version of MonoGame, not sure what else to do :confused:

Please do! One of the goals of MG is to make this as painless as possible

I think I should have realised this earlier, but it seems to always happen when you access the project by double clicking on the Content.mgcb in the Solution Explorer of Visual Studio (2015 - Community edition).

If you access it by opening the MonoGame pipeline directly, it doesn’t happen… I think.

I’ve been opening the MonoGame pipeline directly and it happens to me.

That shouldn’t matter. There was a version of MG where I had the same issue, I think upgrading should fix it.

Which release is it fixed in? I’m currently on 3.5, the latest major one that I know of.

Not sure if you checked this, but be sure that the Build Action for the .mgcb file is MonoGameContentReference. If that option is not available (as it is not in a shared project), then you can try manually editing the project items file and changing the None tag to MonoGameContentReference. For shared projects, this makes the .mgcb file disappear from visual studio, but it still seems to do the actual build of the .xnb files. I am using Visual Studio 2015 Update 2 with MonoGame 3.5.1 (the current stable release). In Xamarin Studio on the Mac, the .mgcb file shows up fine in the shared project.

When you open the .mgcb file, make sure the one it loads is the one you tried to open. I ran into a bug a while back that (I think?) eventually got fixed where if you tried to open the pipeline tool by double clicking a .mgcb file it would instead open the most recent mgcb file the tool last opened with. I spent a while hitting build and checking the directory wondering why nothing was there, when it was actually just building an older unrelated mgcb file.

It shouldn’t be broken in 3.5 stable release as far as I know. You could try the latest develop build

I just downloaded MG 3.5. The MonoGame Pipeline doesn’t build anything for me (so far I tried a .x, a .xml, a .dae and a .wav). I’m using Windows 7 and VS2010. When trying to build nothing happens. Any ideas?

After reformatting my computer I downloaded MonoGame 3.5.1 and it started working again. I haven’t tried building any file formats you mentioned except .wav files. Make sure you have 3.5.1.

I had the same problem: build and rebuild didn’t seem to do anything. So I downloaded the sourcecode and tried debugging the cause. Turns out the very first lines of DoBuild cause the problem:


The ArgumentException is not caught and hence nothing happens. Replacing the try-block with “encoding = Encoding.UTF8;” fixed the problem for me.

Since I’m pretty new to monogame I don’t really know what to do with this information except post it here - hope somebody can use it to fix it appropriately.

I dunno but this doesn’t sound right.

OEMCodePage

… more information ?

Gets the original equipment manufacturer (OEM) code page used by the writing system represented by the current TextInfo.

The bit of info on that particular call is fairly obscure the (OEM) looks ominous.
Though that might just mean windows code page encoding it makes me think ascii.


If you want a breif history on character sets encoding decoding.

Here is the ms

Selecting an Encoding Class
If you have the opportunity to choose the
encoding to be used by your application, you should use a Unicode
encoding, preferably either UTF8Encoding or UnicodeEncoding. (.NET also supports a third Unicode encoding, UTF32Encoding.)
If you are planning to use an ASCII encoding (ASCIIEncoding), choose UTF8Encoding instead.

Just had this issue. Thanks to @Deeem2031 I was able to solve it by changing my Windows display language to en-GB. (It had been set to some odd variant of en-XX that doesn’t seem supported by most things.)