Forum Libraries, Components, and Plugins

Walktrough : Using the Monogame pipeline tool for building CocosSharp specific content

DomiBDomiB BEBeta, University ✭✭



I had to go trough some steps to get a working CocosSharp.Content.Pipeline.Importers.dll assembly that I can use with the monogame content pipeline. I had to change a few things, as the projects that are included in CocosSharp seem to be aimed at the legacy XNA content building stack, with VS2010 etc...

The effort was mainly to get a "Any CPU" windows assembly that can be loaded by the pipeline tool. Rebuilding the pipeline tool with a reference tot the cocossharp assembly probably isn't needed, as I realized after I had done all these steps, so you can probably skip the steps for building Pipeline.Windows again (in part 3.)

Anyway, here are the steps. I have also uploaded a screenshot of the pipeline tool with the cocossharp targets included. If anyone knows a simpler way, please let me know :-) It would be nice if the project for building this could be included in the cocossharp source.

(sorry if all this is not very readable, but this forum software does strange things to formatting)

(all steps below done on a Windows7 system with VS2013)

1. Build MonoGame

Get the CocosSharp source from GitHub

Build the MonoGame project files with ./MonogGame/ProtoBuild.exe

open ./MonoGame/MonoGame.Framework.Windows.sln, Build it (Release in my case)

(--> now there is a PipeLine.exe in ./MonoGame/Tools/Pipeline/bin/Windows/AnyCPU/Release which works, but doesn't have the CocosSharp specific pipelines in it)

2. Build CocosSharp content pipeline

Open the project /cocos2d.Content.Pipeline.Importers/CocosSharp.Content.Pipeline.Importers.csproj

Save the new solution in CocosSharp.Content.Pipeline.Importers.sln in the same folder

Add to the same solution the following projects :

  • ./src/CocosSharp.WindowsGL.csproj
  • ./box2d/box2d.WindowsGL.csproj
  • ./MonoGame/MonoGame.Framework/MonoGame.Framework.WindowsGL.csproj
  • ./MonoGame/MonoGame.Framework/MonoGame.Framework.Net.WindowsGL.csproj
  • ./MonoGame/ThirdParty/Lidgren.Network/Lidgren.Network.Windows.csproj
  • ./MonoGame/MonoGame.Framework.Content.Pipeline/MonoGame.Framework.Content.Pipeline.Windows.csproj

in the PipeLine.Importers project remove the Microsoft.Xna.* references, and add references to :

  • MonoGame.Framework.WindowsGL
  • MonoGame.Framework.Content.Pipeline.Windows

in the PipeLine.Importers project remove the CocosSharp.Windows reference and replace it with a reference to CocosSharp.WindowsGL

Remove with notepad in the PipeLine.Importers the following line

Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\Microsoft.Xna.GameStudio.ContentPipelineExtensions.targets"

and save the project, you now have to reload it in VS2013

(previous step is important, it had me stumped for a while but you need it to execute the following step)

In the configuration manager add "Any CPU" to the platform box (New, copy from X86, uncheck the 'create new solutions platform' checbox)

Build the solution (ANY CPU, Release in my case)

(--> now there is a CocosSharp.Content.Pipeline.Importers.dll assembly in \cocos2d.Content.Pipeline.Importers\bin\Release)

3. (Build the PipeLine.exe tool again) and run it

Open the solution ./MonoGame/MonoGame.Framework.Windows.sln again

In the PipeLine.Windows project add a reference to the CocosSharp.Content.Pipeline.Importers.dll assembly in above folder

(this previous step is probably redundant as the pipeline assembly is loaded dynamically, see below)

Build PipeLine.Windows again

Run the pipeline.execute and create a new project

Open the references dialog in settings and add the exact path to the CocosSharp.Content.Pipeline.Importers.dll assembly! This makes the tool enumerate the importers dynamically!

--> You now have a working \MonoGame\Tools\Pipeline\bin\Windows\AnyCPU\Release\PipeLine.exe WITH support for CocosSharp specific content!
(I had to close and open the project again to get the importer and processor combo boxes filled with the cocossharp projects types, see screenshot)


  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai

    @dobi69‌ Dominique

    This is awesome and thank you for contributing this post. Maybe we can look into making this easier from our end in the future.

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai


    I opened a new issue for this. We will try to get to this for the next release so it makes it easier for you guys.

    Thanks again for the information.

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai


    Have looked at this. There is nothing we can do to automatically register the CocosSharp.Content.Pipeline.Importers to the pipeline tool but you really do not have jump through all the hoops for generating the .dll's and the pipeline tool.

    If you have Nant installed you can execute

    > nant buildwindows

    from the Visual Studios command prompt and everything will be built for you automatically. The CocosSharp.Content.Pipeline.Importers and the Pipeline tool.

  • DomiBDomiB BEBeta, University ✭✭

    @kjpou1‌ , thanks, I'll try that later. Makes my hack look silly :-)

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai


    Not at all. Thanks for bringing the subject up and actually digging in to find a solution. Let us know if it works.

  • Hi, I'm trying to modify the Pipeline tool so it would use my own pipeline. I have a big problem with building the monogame assemblies from MonoGame/MonoGame.Framework.Windows.sln. VS keeps telling me that I'm missing some types in MediaPlayer class. Additionally I can see that some of the references (like Assimp) are missing. What should I do to successfully build the monogame from source? Thanks in advance.

  • I found a solution for my problem. I needed to clone MonoGame from GitHub and then I could build it from source.

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai


    You are talking about from CocosSharp? Did you follow this It sounds like your submodules did not get updated correctly.

  • My problem was caused by downloading .zip file from GitHub. There were no dependencies of the ThirdParty libraries in the compressed .zip file.

Sign In or Register to comment.