NodaTime 3.x makes app flagged as Malware about nodatime

[jskeet]

I'm afraid I won't have time to chase what's causing the false positives. I'm happy to review a PR that proposes fixes, but I don't want to start guessing about it being that dependency (which would also affect lots of other packages, e.g. Google.Protobuf).

I suggest you contact one of Norton or AVG and ask for support there - if they can give precise reasons, that may suggest a workaround. (For example, we haven't released a new minor version since updating the dependency on System.Runtime.CompilerServices.Unsafe to a newer one. If that would fix the problem, I can look at doing a minor version earlier than I would otherwise; that would be a significantly less disruptive change than removing it entirely. We may be able to make the dependency conditional, too - but I don't want to put in a load of work for this only to find it's not the cause.)

[jskeet]

Looking more closely, it looks like we can indeed make the dependency conditional, so it'll only be present in the netstandard2.0 build. Whether that helps you or not will depend on what you're targeting in your Xamarin Forms project - and on whether this is actually the source of the false positive in the first place.
(The code using System.Runtime.CompilerServices.Unsafe is still present - so if that's what AVG and Norton are detecting, it won't help at all.)

[jskeet]

Looking at this, I'd be happy to update the dependency to the latest version (6.0.0) and conditionalize it within the 3.1.x branch (included with netstandard2.0; excluded for net6.0). I'd then probably just wait for the next release of TZDB data as that's when we normally do a 3.1.x release.

@nord- Please let me know if you're in a position to verify whether this helps, so we can decide what to do.

[malcolmr]

@jskeet I don't see that we can bump the minimum version of a dependency without a minor version bump ourselves, can we? (i.e. I think that such a change would need to be in a 3.2 release, not on the 3.1.x branch.)

I know that we follow semver, but I'm not sure if there's anywhere that explores what that actually means in practice, wrt this kind of situation. My intuition has always been that any 3.1.x should be binary-compatible with any other 3.1.y, but that won't be the case if the two have different requirements on their dependencies.

(I think even #1796 is on slightly shaky ground for this, since an in-place downgrade from 3.1.12 to 3.1.11 should work as well, and with #1796, a downgrade could potentially break a working system. However, you could also argue that the dependencies were still required with 3.1.12, just not actually enforced...)

[jskeet]

@malcolmr: Yes, you're right of course. I think we can reasonably conditionalize the dependency because the dependency is already part of .NET 6 - anyone targeting .NET 6 shouldn't see any difference, basically.

And yes, we should indeed be binary compatible. .NET dependency resolution is normally fine in terms of making binary compatibility work, and even though the dependency version change is a major version, I'd be happy to bump it in minor version of Noda Time because it's a "system level" dependency, so really won't have breaking changes... but you're right that we shouldn't do it in a patch release.

If we'd already done the TimeProvider work, I'd be tempted to do a 3.2 release to clear the backlog of unreleased features... maybe we should do that anyway, rather than delaying while I dither about time providers...