Disable content pipeline for developement builds

My dev. build takes about 10 seconds and 8 of is takes content pipeline. Is there way to temporary disable content building?

does it say ‘Building…’ or ‘Skipping…’?
it shouldn’t build content every time.

if it’s building every time then delete the \Content\bin\ & \Content\obj\ folder and try again.

It says skipping but I have a lot of files and checking-skipping takes some time. Is there way to disable it completely? I’ve tried to remove package reference but it clears build folder removing all the files previous built

As a temporary solution I’ve stashed my content files in build directory, removed reference , then built againt (it clears built content) and copied stashed files back.

Maybe there is better solution?

Not at the moment. :wink:

What does it means? Come again after 20 years for solution? :upside_down_face:

No, maybe… :grin:

I am looking at it now. My first thought was to disable the 'Skipping… ’ message when mgcb is called with \quiet (basically when is called by the msbuild), assuming that writing to the console was what caused the delay.

That didn’t work. The result was more or less the same. But I found something else that might be a perf killer. I’ll work on it again tomorrow.

2 Likes

might get a clue from Nez… they did something special… like prebuild content… tuck in in a shared dll

There are a lot of workarounds and side projects that try to bypass the Pipeline. I don’t really see the point of fighting against the API.
Personally, I’m focusing to build on the existing infrastructure and improve things progressively.

1 Like

So, here are some tests I did on ContentBenchmarks after merging all the assets in a single .mgcb. The following numbers are the project build time average of 4 builds, after a full build.

MG 3.8.1 - 3s
KNI 3.9.9001 - 1.7s
KNI dev_mgcbTest - 1s

What I did in the test branch was removing the ‘Skipping…’ output and converting the .mgcontent files in \obj from Xml to binary.
That means breaking compatibility with mg content DB, but it’s really not a big deal. Probably will not make it to the next KNI release, it’s still a preliminary test and I need to clean things up a little bit.

1 Like

My preferred method is to actually remove the ContentBuilder task from the MG project entirely (and the Content.mgcb file as well). Instead, I use the MGCB Editor separately and build content manually whenever I need to update content. In my VS project, I dynamically include the compiled content like so:

(Android project example of including content dynamically via .csproj/MSBUILD)

<AndroidAsset Include="PATH\TO\CONTENT\Content\bin\Android\**\*.*">
	<Link>Content\%(RecursiveDir)%(Filename)%(Extension)</Link>
	<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</AndroidAsset>
1 Like

You can now test the new build task.
See? It didn’t took 20 years!

In your .csproj add a KniPlatform property with the targeted platform name (Windows, DesktopGL, Android, etc),

  <PropertyGroup>
    <KniPlatform>DesktopGL</KniPlatform>
  </PropertyGroup>

Add the nkast.Xna.Framework.Content.Pipeline.Builder.3.10.9001-rc nuget package,

  <ItemGroup>
    <PackageReference Include="nkast.Xna.Framework.Content.Pipeline.Builder" Version="3.10.9001-rc" />
  </ItemGroup>

Replace MonoGameContentReference with ‘KniContentReference’,

 <KniContentReference Include="Content\Content.mgcb" />

Save the project and restore packages.

This version contains all the improvement in develop, up to this point.
The first time it will rebuild all assets.
If you have custom or 3rd party importers/processors you need to rebuild them against the KNI pipeline.
A quick workaround is to split the .mgcb and build those assets with MonoGameContentReference.

1 Like