`Analyzers` -> Restarting VS when simply changing branches is not acceptable. about terminal.gui HOT 7 OPEN

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.

from terminal.gui.

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.

from terminal.gui.

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.

from terminal.gui.

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. 🤷‍♂️

from terminal.gui.

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).

from terminal.gui.

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.

from terminal.gui.

@dodexahedron I just setup my new ARM-based Surface Laptop 7. Excited to get working on it.

Only to find the ./Scripts report:

``The current processor architecture is: MSIL ... The module 'xxx'reqjuires the following architecture: Amd64`

For now I removed the settings from the psd1 files that required AMD64.

I'd appreciate it if you made it a priority to fix all this stuff. It really negatively impacts my productivity for very little benefit.

from terminal.gui.