Simplify workflow surrounding roslyn projects

[dodexahedron]

Quick Version:

Going to split the Roslyn-related projects off to their own solution, pack as a nuget package, and reference that in Terminal.Gui.csproj.

The Problem

Initially, I was a bit over-optimistic about the impact to some workflows these would have, since I hadn't considered the fact that other project members still end up switching branches between v1 and v2 as needed for bugfixes.

Unfortunately, Visual Studio just doesn't make things easy to begin with, but everything involved in switching back and forth just compounds the issue for everyone.

Available Workarounds

There are some available workarounds to ease those workflows, including:

• There's a VS extension that takes advantage of how assembly loading works and just gives roslyn projects a unique name on every build, so a brand now assembly can be loaded.
• Contributors could clone v1 and v2 to two separate work trees so switching between v1 and v2 isn't required.

But these are both non-ideal to force people to do, and I certainly don't want to depend on that stuff either.

So....

Solution

Pun of course intended.

The solution that requires the least interaction and fewest workflow changes for team members is to just go all the way and pack any Roslyn generator projects as NuGet packages, and then to reference those packages like any other in the projects that need them.

Options for nuget packaging

There are a few ways to go about this, but at a basic level it comes down to 2 general options:

1. Pack into a local nuget repository and consume the packages from there.
   • This is the simplest on the initial setup of things and can be done entirely within branches here.
   • This does, however, have drawbacks in that it's placing the responsibility of packing the nupkg on any contributor and it still needs to be done before the package can be successfully restored. Pre-build events can handle that sort of thing, but it can potentially mean slowing local builds down a bit, plus spurious errors being flagged by VS until restore happens, which is kinda janky if you ask me.
2. Pack into a nupkg for consumption via a remote repository. a. I was already planning to make the minor changes necessary to make the existing generator project-agnostic and publish on NuGet from the SnapsInAZfs organization, so it could just live there. b. We could also make a new repo in the gui-cs organization, if desired. c. For either of those, the code will be the same. 

None of these are mutually exclusive - just redundant if more than one is done.

The Plan

I intend to do 2a no matter what, especially since it doesn't innately have anything to do with TG other than a few strings, and is quite likely to get continued development from my company in the future that would just be noise to have over here.

In any case, the work to do this is relatively minimal.

The basic/rough procedure is:

1. Remove all 3 of the Roslyn projects that live in the Analyzers directory from Terminal.sln and remove corresponding ProjectReference elements for them in any projects that have them in Terminal.sln.
2. Clone the Analyzers tree to a repository specifically for them.
3. Set up NuGet packaging for it and publish.
4. In Terminal.Gui.csproj and anywhere else that needs it, reference that package like any other.
5. Live happily ever after.

That looks to me like probably 2 or 3 commits on the TG side.

The part that will take the longest is just administrative junk, since only superficial code changes are needed.

The Terminal.Gui.PowerShell.Analyzers powershell module will be rendered obsolete by this, too, so I'll delete that at the end, once it's all set up.

[tig]

Contributors could clone v1 and v2 to two separate work trees so switching between v1 and v2 isn't required.

This is not limited to switching between v1 and v2 branches. I regularly have to shutdown VS, Build-Analizers, restart VS when simply switching between v2 related branches.

[dodexahedron]

Even more relevant, then. 🙂

[dodexahedron]

I'm starting the administrative junk behind this in a few minutes. Once that's all in place, it should be a pretty quick transition.

[dodexahedron]

New repo is up here.

I started the reorg and renaming, and will set up CI and nuget publishing once I'm finished with making it independent.

[dodexahedron]

Obviously further issues related to it will be over there.

This one should stay up and be closed when I'm finished with the reorg and packaging and make the changes to the references for Terminal.Gui, which will be a PR for this issue over here.

[dodexahedron]

I should be able to finish up tomorrow most likely.

Likely no more from me tonight. Family function. :)

[dodexahedron]

Just checking in.

I have had a lot of stuff going on, lately (including some rabbit-hole distractions), but am getting back to this again.

Silver lining is that, since we revamped a lot of our workflows internally, at work, I'm going to be able to borrow some of those improvements for use in this stuff, too. At the moment, I'm actually working on carving out the parts of the github-related stuff to make it repo-agnostic and a bit simpler to use (not so many parameters and whatnot, mostly). I'll be publishing those on nuget and psgallery, when ready.

The generator project will then be able to use them, as can this repo.

In particular, the workflow/action stuff is greatly enhanced, offering more control/customization of build/test runs, dynamic matrix execution strategies, branch selection, utilization of github caches, and more, with automatic and manual invocation options.

I don't have an ETA, yet, since I've also got other stuff going on, but rest assured it is in progress. :)