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. 
What does it means? Come again after 20 years for solution? 
No, maybe… 
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.
2 Likes
Nikos, sorry for such late answer, i was doing other things in my game.
I use MonoGame.Content.Builder.Task.Compute because of computational shaders. (Doesnt’t monogame has them still, did it?) so I think I cannot use your soultion.
What is the nkast.Xna.Framework.Content.Pipeline.Builder? It’s you personal monogame content builder fork? WIll all these improvements be merged into a core monogame package someday?
It’s curious that we have a lot of forks and you cannot use them all, you need to choose one:) Bot none of them has all the things you need
In case you build in a clean environment such as a build server it’s easy to archive by doing the following.
<ItemGroup Condition="'$(ExcludeAssetsBuildTask)' != 'true'">
<PackageReference Include="MonoGame.Content.Builder.Task" Version="3.8.1.303" />
</ItemGroup>
Now you can run
dotnet build -p:ExcludeAssetsBuildTask=true
In case you do a explicit dotnet restore you have to call
dotnet restore -p:ExcludeAssetsBuildTask=true
dotnet build --no-restore
Additionally for local builds you could create a build script that clears the nuget cache if the ExcludeAssetsBuildTask is set to true by using dotnet nuget locals all --clear. Since restoring the nuget packages takes time it should only cleared when you game was build with ExcludeAssetsBuildTask=false/notset previously. Therefore, you have to keep track of the state from the previous run or you have to check the nuget cache if the builder.tasks package exist.
Hope that helps