Monogame: Drop the installer

[Jjagg]

The MG installer is causing a high maintenance burden and there are a lot of issues with it. We really don't need to have it anymore if we provide alternatives. That means

• Publish development nugets to a feed. They're published to the TeamCity feed, but IMO we should move to GitHub package feed or MyGet so the publishing of the packages can be done in the CAKE script and finally upgrade from nuget v1. We should also better promote the feed.
• Distribute templates with VSIX and as dotnet new template packages (on the aforementioned nuget feed).
• Distribute CLI tools as dotnet global tools.
• Distribute the Pipeline Tool in some way. Need some discussion for this one, I'm not sure how we best go about this. The Pipeline Tool can use MGCB as a dotnet global tool and will not be tied to any version. We will be able to version it separately. We should make MGCB version configurable in the Pipeline Tool.

cc @tomspilman @cra0zy

Related: #5262

[mrhelmut]

While I'd like to agree, that would probably make VS2015 not usable anymore, right? (trying to think ahead console support and figure out how to manage the CLI tools like mgcb without having to install them to the MSBuild folder).

But yeah, I'm all in to work without installers, it's a mess when working from source.

[Jjagg]

Why do we still need to support VS2015? I'm not sure that it isn't supported with the dotnet new template engine vsix wizard (it probably isn't though), but if it is users can still use dotnet new from console to set up a project.

(trying to think ahead console support and figure out how to manage the CLI tools like mgcb without having to install them to the MSBuild folder).

I don't understand what you mean. You mean for building content as part of building the project? We can do that by using a targets file that pulls the MGCB global tool and runs it (just like cra0zy's MonoGame.Content.Builder package does).

[harry-cpp]

Technically speaking you only need to open the BRUTE and BRUTE exported projects with lower version of visual studio.

[Jjagg]

So since dropping the installer only means templates don't integrate with VS2015 or lower, I guess it's not that much of an issue?

[mrhelmut]

It is required that the C# projects for consoles are built with VS2015 and a max target of Net 4.5.
The C++ project resulting of BRUTE can be built with any toolchain.

So if using mgcb as a global dotnet core tool and dropping the installer means we can't build content on VS2015 anymore, it will most likely break most console pipelines.

I think we need some way to workaround this. I totally agree that we should remove the installer, though we should come up with something to accommodate console users in the absence of an installer (e.g. an "install" script that deploys mgcb to the MSBuild folder to support VS2015-style projects?).

[Jjagg]

If you install the mgcb tool it can be invoked from the command line. So we can execute MGCB from msbuild as long as the dotnet SDK and the mgcb tool are installed (and you correctly add the dotnet global tool folder to path, or have it installed as a local tool which we could set up in the templates), regardless of VS version.

[mrhelmut]

We're all good then, we can handle that with a good old .target file then. Thanks for the clarification.

[harry-cpp]

On a related note, the MGCB nuget works with the console stuff, I've gotten Endi to use it for Raining Blobs XD (you can specify the local path of the MGCB.exe assembly with a property)

[vpenades]

About the pipeline tool, I would consider these options:

• Simply, it can be compiled, zipped and made available through the Releases tab of github.
• It's essentially an application, so make a basic installer just for it.
• Maybe it's possible to package is as a visual studio extension, but then content project files could be opened from within visual studio. I like opening content project files directly with explorer.

[jnoyola]

So we can execute MGCB from msbuild as long as the dotnet SDK and the mgcb tool are installed

I'm curious about the details regarding local or global tools. I started another thread #6898 to dive deeper into the expectation/recommendation.