Release automation #1872

The x64 platform didn't actually build most of Bonsai, it's an artifact of fb65c18 when Bonsai64 was added (before becoming the default and leading to Bonsai32.) The "Mixed Platforms" platform is something Visual Studio used to automatically add to solutions when multiple projects had conflicting platforms. Technically Mixed Platforms was the default before, but Any CPU was equivalent and makes more sense in the context of Bonsai.

The XML declarations are an artifact of the fact that Bonsai is old enough to have use the legacy csproj format. They aren't present the official .NET templates anymore and only serve as noise. The Microsoft.NET.Sdk.WindowsDesktop distinction no longer actually exists. (For modern projects you'd generally add a -windows suffix to the target framework instead, although in the case of Bonsai that wasn't actually necessary anywhere since we still target .NET Framework which is implicitly Windows-only.) https://learn.microsoft.com/en-us/dotnet/core/tools/sdk-errors/netsdk1137

This is being done in preparation for having auxiliary files for organization purposes. The csproj-specific files pattern is intended to avoid issues when projects of multiple types share the same repo. This isn't strictly necessary in the case of Bonsai, but I did it out of habit. This also adds a dummy Directory.Build.rsp (another lesser-used ambient MSBuild configuration mechanism) to avoid searching for one outside of the repo.

…'s output Most of the side-effects of this mistake were not externally observable, but they can (and did) result in extremely confusingly broken builds.

The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core. This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.) ------------------------------------------------- The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph. There exists two paths to this package from the main Bonsai project (versions noted where important): 1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3 2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0 Path bonsai-rx#2 is private to Bonsai, while Path #1 is not. Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32. As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict. This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)

Source link is enabled by default in .NET 8, so this mostly just means removing things that were interfering with it and enforcing building with the .NET 8 SDK. Release automation will rely on Source Link being made default in .NET 8 and we're going to be moving to .NET 8 soon anyway, so no time like the present.

…s` projects This reference is causing bogus warnings on build and isn't actually being used. I think this is an artifact from older versions of Visual Studio, the current VSIX project template doesn't include it.

More info: https://learn.microsoft.com/en-us/dotnet/core/sdk/artifacts-output This also applies to the setup executables and VSIX projects even though they use legacy .NET SDK.

Also add it to the main solution since it was orphaned and it'll be able to be built from it.

The ancient version of ILRepack we were using was broken due to a bug in Mono.Cecil that caused it to crash when running in a modern .NET context. Even ignoring that, it chokes on modern resources embeddings. The package we were using hasn't been updated since early 2019. There is a fork that branched off in 2013 https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task but it doesn't work quite the same way (it tries to work automagically) and isn't a drop-in replacement. As such this change just invokes the executable from the official distribution of ILRepack. This change also makes it so that repacking is no longer done automatically during release builds. It'll be done explicitly by release automation.

…d bootstrapper

This commit also comes with some major changes to how versioning of Bonsai and its components works: * All packages within Bonsai are versioned together now (packages with no changes skip version numbers instead of getting out of sync) * This means Bonsai.Shaders and friends are no longer using initial development (IE: 0.y.z) version numbers * It is now forbidden for projects to explicitly specify their versions (this is required for package diffing * The now-unnecessary revision octet of the file versions has been eliminated (RIP days since first commit Easter egg) * The origin and purpose of Bonsai binaries is now labeled clearly: Developer (local) builds, unstable CI builds, preview builds, and final release builds * The title of Bonsai's editor will be tagged as such for anything other than the final release builds

The labels in the table try to use word wrap when they're too long, but only the first line is visible so the wrapped text just disappears instead. AutoEllipsis prevents the wrap and instead cuts off excess information with an ellipsis. Version was disappearing entirely when build metadata was included. The copyright year range was being cut off as well, made the form a bit wider so it's fully visible.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Release automation #1872

Release automation #1872

Commits on Jul 3, 2024