I was just writing up a post to see what the general consensus was with the content build system as it stands with MonoGame. I’ve been tinkering a bit with it lately and have come across a few issues mostly relating to combining the usage of MonoGame.Framework libraries with XNA in order to make Content Processors that are select-able as a property on items that are included in the Content Project.
Having discovered that this is not possible (because of type-redefined errors when linking against both MG and XNA), I’ve concluded that the best way to achieve automated content build is to simply include items as part of the content project and then make a basic “Task” (Microsoft.Build.Utilities) that uses similar code to that of MGCB to build the content for me automatically.
Refer to the “AfterBuild” extension for Microsoft.Common.targets, that’s essentially where I am including my task assembly there and then executing it later on.
The only real problem with this is that you cannot define from VS the type of importer or processor that you wish to make use of on a particular item in the project.
I was just writing this post to see whether this was something that the MG team had considered already moving forward with addressing the problems with the content build system.
I certainly have, but that is still an external application that requires me to lose focus of VS2012 to interact with. What I meant in my my thread was that I was looking into something more automated that happened at build time of my games.
In Protogame http://protogame.org (which uses MonoGame), the asset management system automatically invokes the content pipeline at runtime (if needed) during development. The only time I need to explicitly build assets is when I want to compile them for release, in which case I just run the bulk compile tool.
Hachque, that’s exactly what I was avoiding with it having to be built at runtime. My current integration consists of doing it with MSBuild as part of the AfterBuild event target.
At least when I do it then it means that I can generate the checksums for the files that are generated by the content build pipeline. Useful for content validation afterwards to ensure the lack of corruption or external modifications. But this is something that relates more to my own personal need rather than the MonoGame project.
The Pipeline GUI tool is meant for editing of the content project. Adding new content, changing settings, etc.
The MGCB.exe command line tool compiles content as defined in a content project. This is what the Pipeline tool uses under the hood to actually do content building.
We are currently working on a .targets file to use from your csproj which will manage building content using the MGCB.exe command line tool.
Finally we plan to revamp the template projects to always include an empty MonoGame content project with the correct .targets to have it automatically build content.
Note that @dellis1972 is working on the Mac side and XamarinStudio integration as well.
Some differences with XNA…
To edit the content you will double click the .mgcb file in the VS tree view and the Pipeline GUI will pop up.
Rebuild in VS will not clean and rebuild all content. It will simply build.
Clean in VS will not clean your content. It will do nothing.
So in the end it will be pretty much like how XNA worked except we have a stand alone (and cross platform) editor for content and rebuilds/cleans won’t accidentally cause you an hour of content building.
Yes… that is the goal. To make it the official way to manage and process content.
That is specifically why we wrote it as a stand alone command line tool. I expect to see teams use it in different ways.
Simple templates, some .targets files, and some registry keys… nothing more.
I’ve always found extending VS with custom code something that was tricky and required constant maintenance to keep working. It just isn’t worth the hassle when you are already struggling to maintain a project like MonoGame.
yes one last build please and add everything into the download 3.2 doesn’t seem to include the pipeline gui tool
i didn’t even know there was one till this post, no wonder i could never get a fx file to work.
i thought it was just a code pipeline or the command line exe was it
and then i still couldn’t get it to work on vs2013 (everything else i got to work fine but the fx files)
i thought it was just undo-able without vs 2010 which i don’t want to reinstall
Actually when the content pipline changes
you should make it monogame version 4.0
since its running off 4.0 .net / mono 4.0
it’s targeted to xna 4.0 = monogame 4.0
its a major change and avoids confusion later on
between were the new content pipeline was added
and bug fix’s then are just minor build changes 4.0.1 or 4.1 ect
breaking changes should get a major revision number change anyways
