Monogame: Include Content Pipeline Tool in NuGet Packages

[trommlbomml]

As I have my monogame projects in git I woul prefer to use Nuget-Packages instead of installations for better dependecy handling. Unfortunatly the NuGet-Package for MonoGame does not provide the content pipeline tool, so I needed to install MonoGame from the installer too. This is bad because now I have MonoGame twice installed + probably some issues when I switch to a different MonoGame Version in NuGet.

[tomspilman]

Is that even something you do with NuGet? Distribute GUI apps?

[trommlbomml]

Why not? As I see the Nuget-Packages are per platform this seems to me no problem. A compromise for me would to have a separate command line only tool provided by nuget. Don't you think installing and having nuget-packages is a bit weird?

[craftworkgames]

Doesn't Chocolatey do something like this?

Chocolatey NuGet is a Machine Package Manager, somewhat like apt-get, but built with Windows in mind.

[mattleibow]

@trommlbomml I would maybe create a separate package "MonoGame.Content.Pipeline.Build" or something. This will allow the projects to only install all the other things if they really want to.

All the bits can go in there from the two installers. NuGet is better than Choco as it allows the build process to restore it to a location known to the build agent. If is has to be installed via some other tool (such as choco), it needs to be done before the build. We don't have to chuck out the installers though, as this is still useful for other situations where one installation is required.

@craftworkgames Another issue comes in when building separate versions on the same machine. If it is in a NuGet, then everything is contained in the package directory. From what I can see (and I didn't look very hard) Windows just copies stuff into the MSBuild directory. We could instead just keep everything in the packages folder for the same effect. On Mac, I am not sure about how applications are managed exactly. but it could be possible, maybe?

[craftworkgames]

@mattleibow Yeah I agree with you on that one.

I've been thinking about this a bit lately because we've experienced a related issue with MonoGame.Extended.

The problem really boils down to using a different version of the Pipeline tool compared to the version of MonoGame referenced in your project. In this case referencing 3.4 and using Pipeline 3.5 or visa-versa.

It stands to reason that the Pipeline tool is just another dependency of your project and should be treated that way. If the Pipeline tool was kept in the packages folder, or somehow otherwise kept with the project it belongs to then the problem would go away.

For people using the NuGet packages the solution seems relatively simple on the surface. We just store the Pipeline tool in the packages folder. However, there's another piece to the puzzle.

In a MonoGame project file there's a reference to the content builder targets file which is used to build content at compile time.

<Import Project="$(MSBuildExtensionsPath)\MonoGame\v3.0\MonoGame.Content.Builder.targets" />

On my machine this path resolves to

C:\Program Files (x86)\MSBuild\MonoGame\v3.0\MonoGame.Content.Builder.targets

This file is also stored next to where the Pipeline tool is installed.

So if we where to put the Pipeline tool in the packages folder we'd also have to figure out how to deal with the targets file so that it points to the correct copy of the Pipeline.

[trommlbomml]

@mattleibow I agree with that. it also seems a windows (and linux?) only problem as I can install the pipeline tool or mac separately from the monogame on the website.

[mattleibow]

@craftworkgames If we add a .targets file to the build/ folder, then it will automatically be managed by NuGet and add it to the project file. No actual work is needed on our side. I am busy testing things here and will see if I can get a PR that does this all.

[mattleibow]

@trommlbomml We can let the user know that it is either or. If we use the NuGet, then it will use the NuGet. If they want to use the main install, then they will have to do the work manually. It should be no problem as the one is in the packages/ folder and the other is somewhere else.

[mattleibow]

@craftworkgames I created a PR to show the current working: #4332

[craftworkgames]

Looks great.

[craftworkgames]

What ever happened with this? I can see the issue is still open but the related PR is closed with no explanation.

[harry-cpp]

What PR? Also NuGet is no place to include Pipeline Tool in so I don't think anybody will set it up.

[SimonDarksideJ]

The main issue with a CP Tool NuGet was the size as I recall, it was almost a 100mb package due to the dependencies required.

[harry-cpp]

The main issue with a CP Tool NuGet was the size as I recall, it was almost a 100mb package due to the dependencies required.

No, that was MGCB nuget. Also I fixed the size issue:

• https://www.nuget.org/packages/MonoGame.Content.Builder/
• https://www.nuget.org/packages/MonoGame.Content.Builder.Windows/
• https://www.nuget.org/packages/MonoGame.Content.Builder.Linux/
• https://www.nuget.org/packages/MonoGame.Content.Builder.Mac/

[SimonDarksideJ]

Ahh, wasn't aware of that update, thanks @cra0zy :D
I guess we need more announcements / detail on that availability now.

SO is it, "done"?

[harry-cpp]

I guess we need more announcements / detail on that availability now.

SO is it, "done"?

Nope, they are still unofficial ones, I didn't make a PR for it (mostly waiting for Protobuild removal which is scheduled for 3.8).

[craftworkgames]

What PR?

PR #4332 was the last one mentioned in this issue (before I made the comment). I mean, I really have no other context other than what's written on this issue so..

Also NuGet is no place to include Pipeline Tool in so I don't think anybody will set it up.

Why do you say that?
I mean, maybe NuGet is not the right solution to this problem.
Ultimately though, having some way to install a particular version of the Pipeline Tool into your project would be useful and have it versioned with your source code is important.
It's quite annoying to grab the source code of a project and not have it build because it used to use a different version of the Content Pipeline tool.
An alternative approach is to have a some sort of build script the user can run or at worst it's just instructions in your readme.
Either way though, last time I checked having 2 different versions of the Content Pipeline installed on the same machine wasn't possible. Maybe this has been fixed now, I don't know.

No, that was MGCB nuget. Also I fixed the size issue:

Thanks for publishing those NuGet packages. That's the kind of thing I was looking for when I posted here the other day. I had a look on nuget.org but I didn't notice these. I'll take a closer look at them later.

Nope, they are still unofficial ones

"Official" or "unofficial" doesn't really matter if it solves a problem. We appreciate it all the same @cra0zy

[harry-cpp]

Why do you say that?
I mean, maybe NuGet is not the right solution to this problem.
Ultimately though, having some way to install a particular version of the Pipeline Tool into your project would be useful and have it versioned with your source code is important.
It's quite annoying to grab the source code of a project and not have it build because it used to use a different version of the Content Pipeline tool.
An alternative approach is to have a some sort of build script the user can run or at worst it's just instructions in your readme.
Either way though, last time I checked having 2 different versions of the Content Pipeline installed on the same machine wasn't possible. Maybe this has been fixed now, I don't know.

That mostly gets solved with the MGCB nuget (since you only want to use the Pipeline Tool to edit .mgcb files anyways).

Thanks for publishing those NuGet packages. That's the kind of thing I was looking for when I posted here the other day. I had a look on nuget.org but I didn't notice these. I'll take a closer look at them later.

Reference only the main one, to see it in action check out .NET Core template I did:

dotnet new --install MonoGame.Template.CSharp
dotnet new mgdesktopgl

[craftworkgames]

dotnet new --install MonoGame.Template.CSharp
dotnet new mgdesktopgl

I used this on the weekend when I was converting MonoGame.Extended to .NET Standard. It works really well, thanks for your efforts @cra0zy.

[harry-cpp]

Content Pipeline Tool will never be available as a nuget, however maybe as a dotnet tool in the future. Anyway if anyone is interested feel free to open a feature request about it.