Fix startup crash on .NET 11+ (#710)

[nil4]

Fixes #710

When targeting net11.0 or running on .NET 11 (e.g. via RollForward=Major), Fallout projects crash on startup with:

System.TypeInitializationException: The type initializer for 'Fallout.Common.FalloutBuild' threw an exception.
---> System.ArgumentException: Expected condition to be true (Parameter 'assemblyLocation == string.Empty || assemblyLocation == invokedLocation')

Testing .NET 11 RC1 and RC2 on macOS and Windows, the clause assemblyLocation == invokedLocation no longer holds.

On macOS:

• assemblyLocation = "Fallout/build/bin/Debug/_build.dll"
• invokedLocation = "Fallout/build/bin/Debug/_build"

On Windows:

• assemblyLocation = "Fallout\build\bin\Debug\_build.dll"
• invokedLocation = "Fallout\build\bin\Debug\_build.exe"

Update the assertion to canonicalize extensions to .dll before comparing.

[ChrisonSimtian]

can we please come up with some unit tests / specs for this as well?

[nil4]

I am not sure this can be unit tested. The problem I see is that the FalloutBuild static constructor invokes this code path here:

Fallout/src/Fallout.Build/FalloutBuild.Statics.cs

Lines 17 to 22 in fcf5cbb

	static FalloutBuild()
	{
	RootDirectory = GetRootDirectory();
	TemporaryDirectory = GetTemporaryDirectory(RootDirectory).CreateDirectory();
	BuildAssemblyFile = GetBuildAssemblyFile();

Which means that, as soon as any member (static or instance) of FalloutBuild is accessed, the static constructor kicks in, calls GetBuildAssemblyFile, the assertion runs, and the TypeInitializationException can be thrown.

But since reproducing this requires either targeting net11.0, or running on .NET 11, I think that only a runtime/CI test would confirm it.

Would you be able to help with, for instance:

• install .NET 11 SDK in CI
• run any Fallout build (be it a newly-generated one, or even https://github.com/Fallout-build/Fallout/blob/develop/build/_build.csproj) with DOTNET_ROLL_FORWARD=Major set in its environment?

I think doing something like that should reproduce the issue as reported in #710 without this change, and confirm the fix with it. I don't think I can add such a test but I would appreciate it if a maintainer would be willing to try it.

[nil4]

Perhaps the better fix would be to simply remove this assertion:

Fallout/src/Fallout.Build/FalloutBuild.Statics.cs

Line 124 in fcf5cbb

Assert.True(assemblyLocation == string.Empty || assemblyLocation == invokedLocation);

It worked up to and including .NET 10, but stops working as of .NET 11. It is now, and will likely continue to be, very impactful because it failing throws from the static constructor, making the FalloutBuild type effectively unusable.

Removing the assertion would at least give builds a chance of starting on .NET 11 and later. I can update the PR if you prefer this instead.

[ITaluone]

Or you add some sort of a env var switch.. default behavior matches this behavior right now. If you know what you are doing, turn this assertion off.

like: FALLOUT_RUN_BUILD_ON_NET11 or similar

[nil4]

I'll defer to the maintainers to decide, but I don't think adding an env var or any configurable knob is needed.

In my testing, builds worked once this assertion was removed or fixed to pass. assemblyLocation is returned from GetBuildAssemblyFile and invokedLocation never gets used.

Thus I see it as a matter of deciding whether the assertion is worth keeping; I'm not sure what value it provides, or what it is supposed to guard against. The downside of it failing, bringing everything down with it if/when that happens, seems disproportionate to any utility it might have had once.