Build .... oddities... #3558
Description
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 <Include .../> 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 <Deterministic>true</Deterministic> 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....