Monogame: Add NuGets MonoGame.Framework.Content.Pipeline?

[tomspilman]

We currently don't have MonoGame.Framework.Content.Pipeline up on NuGet.

We are about to add the PCL version of MonoGame.Framework.Content.Pipeline to NuGet in https://github.com/mono/MonoGame/pull/4712.

Still should we put up the platform ones for Windows, Mac, and Linux as well?

[KonajuGames]

Would the platform specific ones include all the supporting executables and
native libraries for that platform?

[tomspilman]

Would the platform specific ones include all the supporting executables and
native libraries for that platform?

Yes... everything but MGCB.exe or Pipeline.exe as those are separate things.

Not sure how stuff like ffmpeg.exe would work... I assume that if it is included as part of the NuGet it will get copied into the final bin folder of your project. So I guess it would work.

[SimonDarksideJ]

So it can be managed/deployed in a separate steam, it should be it's own package. Ensuring the msi installers are not a dependency for getting started with MG (remembering some institutions can't install just any msi, and definitely not regular updates)

Should be able to use all of mg from nuget like other solutions

I did do CP pcl and nugget for dean but it likely needs bit more for other platforms

[tomspilman]

So it can be managed/deployed in a separate steam, it should be it's own package.

Of course... we would add:

• MonoGame.Framework.Content.Pipeline.Windows.nuspec
• MonoGame.Framework.Content.Pipeline.MacOS.nuspec
• MonoGame.Framework.Content.Pipeline.Linux.nuspec

I did do CP pcl and nugget for dean but it likely needs bit more for other platforms

I've already done this as part of #4712.

[craftworkgames]

Yes... everything but MGCB.exe or Pipeline.exe as those are separate things.

In an ideal world _everything_ required to build a project would be contained in or referenced from the source code repository.

In other words, the goal is to be able to download the source code and _build it_ without needing to install any other dependencies on your system.

This means you should be able to have a MonoGame 3.4 and MonoGame 3.5 project on your computer _at the same time_ and they both should build!

Unfortunately, this is not currently the case, because the version of MGCB.exe and Pipleine.exe installed are _directly tied_ to the version of MonoGame you've got referenced in your project. If you've got the 3.4 Pipeline installed, your MonoGame 3.5 content _won't build_ and visa-versa.

The entire point of using NuGet packages is so you're source code references the correct versions of it's dependencies and downloads them as required. The Pipeline _is_ one of those dependencies and should be treated the same way as any other DLL reference, ideally.

I'm ranting a little; I know. And to be honest, this issue doesn't bother me as much as it seems but I just wanted to make it clear that it _is an issue_.

So in conclusion, yes, I'm in favor of making NuGet packages but it's still not ideal if you have to also run the installer. It's a step in the right direction.

[SimonDarksideJ]

Agree, separation on the dependency to the installer and the nuget packages. The nuget can enhance the installer but shouldn't be dependant on it. Version independence.

[Firedragonweb]

I'm trying to move the content creation tools for my engine to Nuget dependencies. I cannot go full Nuget however, because (as I learned here), there is no package for the pipeline tools. So I fully second the notion of creating Nuget packages for that :)

[harry-cpp]

I'll point out that I did upload MGCB nuget several months ago if someone wants to use it (just remember to remove .targets link that default templates create for the system MGCB calling): https://www.nuget.org/packages/MonoGame.Content.Builder/

[harry-cpp]

We do have the nuget on the develop branch now.