I’ve noticed in working on my Monogame-based game that the build speed in Visual Studio is too slow. It seems to be related to the MGCB content pipeline. Even when all of the content files are skipped, it still takes a while. I have about 4000 content files and I can’t trim it down any more.
Is there a way to speed things up? Like can I de-couple the content building from VS somehow? I don’t need VS to check the content, I have no problem clicking “Build” in the MGCB editor when I need to build a new piece of content.
Can I do that and still use the content pipeline in the code? I tried removing the “MonoGame.Content.Builder.Task” from the Dependency packages, but then the ContentManager class doesn’t seem to work. The only thing that I have an issue with is just the way that the content pipeline seems to want to try to build content each time I compile. I like the other pieces of the content management, just want to disable that build-check which seems to take a while probably checking hashes on all of my content files to see if they need a rebuild.
Two hours later, I finally managed to upgrade to 3.8.1.303 after some pain. And I was able to remove the build task using the NutGet package manager, and it now works without doing the whole content build from VS - saves me a lot of time! Thanks markus, very much appreciated.
EDIT: Spoke too soon.
There must be a build step in the VS build task that copies the xnb files to the correct location in the /bin folder which is not happening when I remove the task from VS. Is there a way I can have the updated files copied to the correct locations without having the task actually check all the content files?
I think it’s just the one.
There’s a few macros you can use, like $(Configuration). Those get replaced with the corresponding parameter: Debug or Release.
And then you can always launch the content builder from the command line. So you could create a command line script that does all the copying you want after the build.
Also dev studio has a way that lets you tell it what is a dependency… It gave me a warning that it thought my build , could be speed up… See it doesnt know about the custom build stuff. I saw a hint once that my core was being rebuild unncessarily but i forgot it… In my project X Shader, i touch an fx file and it builds and any platfrom runs. It copies the XNB and it only builds the touched ones since i put Copy newest somewhere… Level and DATA and shared game code is in one place but XNB gets buidl only when touched, and collected from folder named after targets… But i feel your pain i think if you have a ton of shaders they seem to slow the whole buid every time. . But i like you said doenst konw that all those get packed up and should on get copied if newer and such. There are settings to play with. if you google around or see the warning you , find a way can tell the caching thing that XNB is a dependency or , not, or something… feel free to try it in my “SHARED TROUBLE REPO”
… what i want to host is one shader code that just touch and fx files and it quickly builds and runs… on Mobile and X platfroms… In not sure but its well organised, like the old Netcore Sample… But now that maui exists, im confused… So im going to leave it for a while. So if you are just working on one shader, mabye command line like Markus says is a beter way and forget all the UI stuff… make some of your own tools. learn some shell commands… press up and such… you can also prebuild shaders and commit to your vault… But idealy this could all be solved in a nicely set up project and solution Sample. Thing is Visual Studio Communtity dev 2022 preview updates every week … i have 3 branches… net 7 which has Maui now… A Compute branch where Markus branch is being expermented with, and the net 6 / MG 3.8.1 out of box Xamarin one.