Analyzers -> Restarting VS when simply changing branches is not acceptable.

[tig]

Every time I switch branches I need to exit VS, re-build them, and restart VS. This is not acceptable.

On my fast desktop this is painful. On my laptop it's excruciating. It takes many minutes just to change branches and I do that frequently.

@dodexahedron can you please find a solution to this that does not require such a painful workflow. When I agreed to merge it, I was under the impression that I'd only have to do the song-and-dance if I actually changed something that utilized them. But that's not the case, apparently.

Given the current value Analyzers provides is extremely limited I'm prone to just ask you to yank it out for now unless there's a way of them working that doesn't provide such a cruddy developer experience.

[dodexahedron]

There are options.

At a high level, I think the one that would be most natural for everyone, since they already use it without even realizing, is sticking them into a nuget package of their own and just reference the package.

Whether that package is local or actually published on a nuget repo is unimportant, as far as visual studio is concerned.

If this were a corporate team where everyone were guaranteed to have at least a similar baseline environment, I'd typically publish to a local shared nuget repo. Since that's not what this is, one option is to "publish" the package to a directory in the repo for that "shared" nuget repo.

Then it'll just be pulled in as part of the normal restore step.

Or the same thing can be done, but not nuget-flavored, and just stick the assemblies themselves in a central place to be referenced. The nuget way has the advantage of being more adaptable to different CPU targets, though.

[dodexahedron]

Oh. Forgot to mention the second option I meant to mention..

There's a visual studio extension to address this shortcoming that basically just hacks it by generating new names for the assemblies each time, so they can be loaded "dynamically."

It's an absolute kludge for sure, but it does seem to be a viable workaround.

[dodexahedron]

As for the first option (nuget packages or other pre-deployment that takes the project out of the solution), we could even just put them in their own repo under the org, and either publish them to nuget.org or as releases right here on github to be pulled in via nuget or any other mechanism.

Basically, as long as the analyzer project is not in the same solution, the pain goes away. I had actually originally written it in a separate solution, but was trying to avoid anything that involved deploying anything, since I couldn't do that to test it out.

[dodexahedron]

And, with how the newer ones are intended to be designed in a more target-agnostic fashion, I could even just publish them on nuget myself as not specifically bound to or dependent on Terminal.Gui. 🤷‍♂️

[dodexahedron]

My inclination (without me publishing them separately, anyway) is to do it via a bit of a hybrid approach, doing all of the following:

• Analyzer project not in Terminal.sln
• Most recent compiled assembly included as a fallback in source control directly.
• Fallback version compiled as generically and compatibly as possible (so, AnyCPU and anything potentially platform or runtime specific turned off)
• Analyzer project outputs to a gitignored path, and Terminal.Gui.csproj just conditionally references that or, if it does not exist, the fallback assembly.

This is a quickly-doable change to the process that will remove the pain and make an alternate/more formal means of distributing and referencing any custom analyzers a much less pressing need (but still something I'd suggest is a good idea before tagging TG as beta).

[dodexahedron]

That would be temporary only¹, btw, until a long-term solution is implemented. Not great practice to keep binaries in source control if you can help it.

Footnotes

1. And not temporary as in "the most permanent solution is a temporary solution" either. ↩