Build .... oddities...

[dodexahedron]

OK. So...

TL;DR: I think we should flatten the MSBuild config again, removing the Directory.. files and putting their contents in the projects they apply to OR explicitly include them where they're wanted.

Do you want me to just fix it and give a quick 5 mile overview reason for them or do you want me to write that book first?

Before I write a book on this one, because it's a combination of multiple problems that are not actually our fault (bugs and limitations of various different components in the chain, mostly), are non-intuitive and have unknown impact that could be anything from wasted junk space to actual differences in program behavior that our tests don't cover (more likely closer to but not entirely the former)... But yeah... How much detail do you want/need on this one? Because, while it is a bitch of a set of issues to explain, the fix is extremely simple and understandable by everyone without explanation: Moving some build configuration around and flattening it. We're talking like 3 or 4 file deletions and moving their contents, verbatim, into the csproj files, and the problem is essentially licked. Alternatively, I can just rename them so they aren't automatically picked up by anything and we can put explicit `` elements in the csproj files we want to have them apply to.

Either way, the end result is getting every tool and process to result in as similar output with equivalent options as possible, with no advanced knowledge of the build tools necessary.

Here's a high-level and not-very-technical nor scientific intro (in the interest of the closest I can muster to "brevity") to what brought me to this conclusion and wanting to do this:

How I found out about and tracked it all down

In short? Some of it has been paper-cut misbehaviors of Visual Studio I and lots of people have just dealt with for many years. Some of it is known bad behavior and simply documented as such. And the rest became both very apparent and much more relevant and therefore irritating to me, with all the build tooling work I've been doing in various places over the past few weeks. All I know, in terms of results, is that builds done in seemingly identical ways on the same system, from clean clones, with as little difference as the directory the build was ***INVOKED*** from can result in different build inputs (like the actual monolithic XML file msbuild creates and then executes) and different build artifacts. And that's not the only way to get different builds. And that's even with the `true` element in the csproj files, which doesn't really have much to do with much more than anonymization of source paths in debug symbols. Again... Does it matter? I don't know, and I'm not about to spend the time and effort it would take to definitively prove it one way or another beyond noting that there can be 62kB of difference in the msbuild xml inputs (that's a ton!) to the build simply by running it from the solution root vs the terminal.gui project directory on clean clones, after doing everything else identically, and that the compiled dll is also not the same size. And Visual Studio has different results, too, because it doesn't even call the same targets, nor do those targets exist in the first place on a machine that doesn't have Visual Studio (not just the MSBuild tools and dotnet) installed. If you want more of the sauce, I'll write the rest of the book. This is the synopsis and prologue... Oh yeah... And all of the above also applies to the tests, samples, analyzers....Basically anything that ***should*** be affected in the expected ways by the Directory.*.* files and family....

[tig]

Please do! Thanks.

[dodexahedron]

A'ight.

A little of this already did get done and merged in PRs that were prepping to nuget-ify the analyzer project.

But I'll make a pass over everything to do with msbuild for what's in the solution, as well as nuget, first, since that'll work just fine as a self-contained PR, and then get into github workflows and scripting stuff.

[dodexahedron]

@tig

A couple of specific questions on elements in Terminal.Gui.csproj, as of v2_develop head at this moment, which is at f1fe7e7628332f354d171c0f75787ebed1ff6b26:

Why are these specified?

Line 31

    <SuppressNETCoreSdkPreviewMessage>true</SuppressNETCoreSdkPreviewMessage>

Not really a good idea to be in source control as the default. I'm likely going to put a condition on it so it only gets included if a configuration that explicitly targets a preview framework is selected (one of the new ones I'm adding).

---

Line 129

    <DocumentationFile>bin\$(Configuration)\$(AssemblyName).xml</DocumentationFile>

What is the purpose of this? It actually causes inconsistent behavior for certain build targets depending on the build environment and build procedure. Default path works for all.

[dodexahedron]

And in the packaging PropertyGroup, the authors and owners elements.

The "proper" values for those elements, according to nuget documentation, are the nuget profile names of those people or organization accounts. Other values are of course legal, but that's the documented recommendation. 🤷‍♂️

https://learn.microsoft.com/en-us/nuget/reference/nuspec#owners

https://learn.microsoft.com/en-us/nuget/reference/nuspec#authors

The docs say it's "ignored" by nuget.org, but that just means it doesn't actually assign formal ownership of the package. The metadata is still as specified in the nuspec.