Add property UsingGodotNETSdk to Godot.NET.Sdk

[invino4]

The Godot.NET.Sdk (for C# use) should define the property UsingGodotNETSdk in its SDK.props.

Why

Defining this property allows shared build configuration (e.g. Directory.Build.targets or other imported msbuild files) to detect deterministically when they are operating within the scope of a project controlled by Godot.NET.Sdk. This enables shared build configuration that may span many different projects within a folder to have Godot.NET.Sdk-specific configuration that only applies to Godot projects.

Why named UsingGodotNETSdk

This naming scheme is common practice in Microsoft Dotnet SDKs. For example, the property UsingMicrosoftNETSdk is defined by the default SDK, UsingMicrosoftTraversalSdk is defined by Microsoft.Build.Traversal, UsingMicrosoftNoTargetsSdk by Microsoft.Build.NoTargets, and so on. The property UsingMicrosoftNETSdk is even used in the implementation of Godot.NET.Sdk for conditional logic of the type predicted here.

Note that these "Using*" properties are additive in the sense that more than one can be defined for a given project (as SDKs can effectively be built upon other SDKs, using them as components). So, it is normal and appropriate for both UsingMicrosoftNETSdk and UsingGodotNETSdk to be simultaneously defined within the same project.

[paulloz]

Hello, thanks for the PR 🙂
I'm not especially against this, but I am wondering if the use-case isn't already covered by the SDK defining GodotDefineConstants here?

[invino4]

Hey Paul, I had similar thoughts about just using GodotDefineConstants but I decided I didn't really like it. My reasoning stems from one of a set of design principles I usually try to follow (4: Code Not Convention) which argues "If it matters, then make it explicit". Being able to distinguish in a shared context (such as Directory.Build.targets) whether you are operating within a Godot project matters for both the correctness and the determinism of the build.

While it might be possible to distinguish using some coincidental property, such as GodotDefineConstants, this is not the explicit purpose of GodotDefineConstants. Assuming additional semantics for GodotDefineConstants has a code smell since it violates the abstraction boundary of Godot.NET.Sdk. GodotDefineConstants isn't meant to be part of the external interface of Godot.NET.Sdk, and so using it directly is like accessing a private variable in a class. It's an implementation detail of the SDK. If a future SDK author decides to come along and rename, split, make conditional, or otherwise change the nature of GodotDefineConstants they would likely not think at all about the consequences to outside projects that have taken an external dependency on these additional semantics. Instead, those projects would be broken by the change. This makes an assumption brittle.

Defining UsingGodotNETSdk, however, has the opposite impact. It makes a deliberate external specification and defines an interface with external contractual guarantees. It will never be a property that is used for some other purpose and would never be subject to unrelated refactoring. Lastly, since its defined semantics are an external contract, refactoring UsingGodotNETSdk cannot be done without considering the impact to dependent projects (because doing so is, by definition now, a breaking change).

Plus, this PR is trivial. :)

As a historical note, the Dotnet SDK didn't originally define UsingMicrosoftNETSdk and coincidental properties within the SDK were often used as a workaround. Over time, evolution of the SDK demonstrated the brittleness of this usage, and projects were broken. UsingMicrosoftNETSdk was introduced to solve that real-world problem.

[paulloz]

Thanks for the detailed write up. Yes. I agree with explicitness being a good thing, and the fact the constants might evolve with time, etc.
Not sure how other people see this, but this looks good to me.

[raulsntos]

This makes sense to me, it's a small change and seems consistent with other SDKs.

[akien-mga]

Thanks!