You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Xamarin.Android.Tools.AndroidSdk] Attributes can be null!
Context: #157
Context: 2d3690e
Commit 2d3690e added Nullable Reference Type support to
`Xamarin.Android.Tools.AndroidSdk.dll`. Unfortunately, it was
largely "surface level", updating *public* API, but not all method
implementations were appropriately updated.
Case in point: if `$HOME/.config/xbuild/monodroid-config.xml`
contains *no* value in `<java-sdk/>`, e.g.
<monodroid>
<android-sdk path="/path/to/android/sdk" />
<java-sdk /> <!-- empty! -->
</monodroid>
then Visual Studio for Mac may report a first-chance exception
(only reported when debugging Visual Studio for Mac, as the exception
is caught internally):
TODO: exception + stack trace
A major reason to adopt Nullable Reference Types is to *prevent* the
occurrence of `NullReferenceException`s, so what went wrong?
What went wrong with 2d3690e is that when XML attributes don't
exist, [`XElement.Attribute()`][0] will return `null`, and most of
our `XElement.Attribute()` invocations cast the `XAttribute` return
value to `string`, "asserting" that a *non-`null`* is returned.
Review the codebase for all `XElement.Attribute()` invocations, and
update all casts from `(string)` to instead cast to `(string?)`.
This ensures that we don't circumvent the C# compilers Nullable
Reference Type checks, catches the circumvention which was present
in `JdkLocations.GetUnixConfiguredJdkPaths()`, and thus avoids the
first-chance exception that VSMac could see.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.xml.linq.xelement.attribute?view=net-6.0
0 commit comments