Sharing Content Between Projects - How To & Best Practice?

Content
#1

Hi,

Up until now I have been maintaining separate Content.mgcb files for both my MacOS and Windows builds. This is a PITA and I really want to move to using a shared .mcgb as I add additional platforms.

What is the correct way to do this? I see I can set up a shared MG project which has its own .mgcb file but I cannot seem to remove the Content directory from my platform-specific projects. Selecting ‘Exclude From Project’ does nothing so I presume it has some special MSBuild commands associated with it or something?

I’m using 3.8. - any pointers appreciated!

cheers

#2

I have a shared .mgcb file in folder separated from everything else. Then I include it in each project like this

  <ItemGroup>
    <MonoGameContentReference Update="..\Hero6.Content\Hero6.Content.mgcb" Link="Hero6.Content.mgcb" />
  </ItemGroup>

As for removing it, exclude from project doesn’t actually delete the file file or anything, it justs add a Remove command in your csproj that tells it to ignore it, however that it is not going to help if your csproj has other commands that actively tells it to include it again. You need to open your csproj files with a text editor and verify the contents.

#3

Thanks, that’s helpful. I did wonder what was going on with those ‘remove’ references when I was combing through the text of the .csproj looking for clues!

Having an additional Content.mgcb in the platform-specific project doesn’t seem to affect anything (it’s just a bit annoying that it’s there) so for now I think I’m going to leave it as it is.

#4

You should be able to get rid of it by just right click and delete in your IDE, it’s your choice though

#5

The best way I’ve found is to maintain several mgcb configs.

But.

Here’s how you can make it much much easier:

I wrote a tool called Nopipeline which generates mgcb configs for you. You still need several nopipeline configs - one for each project - but the thing is, you wrote it once and forget about it. All the resources will be managed automagically afterwards.

The configs look like this:

#6

Why is that better than one common config?

#7

I’ve encountered some issues with platform-specific content like shaders. Pipeline has really hard time switching its platform sometimes. Maybe I did something wrong, but it’s much more stable for me this way.

#8

As long as you make the sure the IntermediateDir and the OutputDir saves platform specific files to a dedicated folder like obj/$(Platform) or bin/$(Platform) it should be fine as it wouldn’t need to “switch” platform. Keeping a single .mgcb should be recommended to everyone, until they develop a specific use-case that requires otherwise. Don’t add complexity and maintenance burden to your project by handling multiple config files, or managing them by a third party tool when you might not even need to do so.

#9

I have to say I agree with that statement!

For shaders I’ve been tending to precompile them anyway. I find that works better for me, I use a Mac as my main dev platform and it can’t compile them directly anyway. After compilation I keep them in platform-specific subdirectories and reference the .xnb files via one common .mgcb.

Also some of my shaders were taking ages to compile and they seemed to get unnecessarily recompiled a lot of the time which was really tedious. Precompiling them allows me to manage that myself.

#10

Except that Platform variable is hardcoded into mgcb and doesn’t always change.

Even if you’ve got a single mgcb, it’s still going to be better with nopipeline. It’s not about managing multiple configs, it’s about managing your resources correctly. You tell it “this directory is where I keep my sprites”, and that’s it. You just drop new images in there, and they are immediately recognized and packaged.

#11

Could you backup that claim? The mgcb takes the platform as a input, doesn’t sound very hardcoded to me.

That is your biased opinion as the project maintainer. Adding third party tools in general have a maintenance penalty. Every single project member will have to learn to use the nopipeline tool (which may or may not be properly documented), in addition to the .mgcb format to develop with understanding of what is happening. If there is a bug discovered that makes development difficult or even impossible they will have to go through a process of reporting the bug, hoping it gets fixed, which can take however long. There’s risk involved in introducing any additional tools or frameworks, that’s just how it is.

Don’t get me wrong, not saying the nopipeline tool isn’t cool, it definitely is. Automatically adding assets? The idea makes me misty eyed.

I still don’t think it should be introduced to any project willy-nilly just because it initially looks better though, especially when the mgcb probably works fine, at least in 3.8

#12

It will never work fine unless it’ll have the same functionality I provide. I’m sorry, but STILL not having generic wildcard support is ridiculous. ¯_(ツ)_/¯

#13

@Martenfur does your library do nuget packages? As in, can I compile my project that uses content and reference it in another project?

I’m currently using a shared project format to share my ui framework, which is, ironically, very awkward to distribute.

#14

It just generates mgcb configs. If mgcb supports it, then yeah.