如何忽略NodaTime nuget包xml文档文件中对jetbrains.annotations.dll的引用

Question

I lean quite heavily on Resharper context actions to generate boilerplate code. The Check parameter for null context action had, up until recently, generated code that performs the null check and throws accordingly. However, now it is adding a Resharper specific [NotNull] annotation to the parameter as part of the method signature.

Looking at this related question Stop ReSharper from Adding Annotations , I've checked across my solution codebase for jetbrains.annotations.dll references but not found any.

However, searching across all files I've found references to jetbrains.annotations.dll in the xml documentation file for NodaTime (NodaTime.xml).

Specifically, entries like this: <member name="T:JetBrains.Annotations.NotNullAttribute"> .

Im not categorically stating that this is the root cause. However, NodaTime is the most recent nuget package I have added since the issue began, and a grep across the solution shows this to be the single point of reference.

Should xml documentation files be including these references, and if so, is there a way for me to configure Resharper to ignore them?

UPDATE I've decompiled the NodaTime assembly and although it doesn't have any binary references to jetbrains.annotations.dll it does appear to (re)declare the offending JetBrains.Annotations namespaces and annotations within itself.

As per citizenmatts suggestion, Ive used the Resharper take me to definition tool for the [NotNull] attribute and this goes to the NodaTime.dll

I've also just noticed that the NotNull attributes Resharper is including do not compile and complain of Cannot reference internal class NotNullAttribute . Hence I obviously don't have the jetbrains.annotations.dll included anyway.

UPDATE 2 Just done the obvious thing of creating a new blank project in VS2013 and checking the null check context action in Resharper works. Then added NodaTime nuget package and rechecked - and indeed it adds the [NotNull] attribute and the project wont compile.

UPDATE 3 As suggested by Jon Skeet I've tried "turning off" data annotations using Resharper-->Code Inspection-->Code Annotations-->Unticking JetBrains.Annotations. However, this has no affect and the NotNull attribute continues to be included.

Looks like I may just have to return to System.DateTime.

Answer 1

Noda Time deliberately ships with an internal copy of the R# annotations, so that those who do want them can benefit from them - it will know which methods are pure, etc.

It sounds like you don't actually want to use annotations at all, so it's just worth disabling them. That's easy from the R# options - under Code Inspection / Code Annotations, uncheck the JetBrains.Annotations option.

We can certainly consider moving the annotations into a specific namespace for Noda Time in the future, so that it's more opt-in than opt-out, but this is probably a good solution if you don't want to use annotations, as it makes it absolutely clear to R# that you really don't want to use them, even if other libraries include annotations.

EDIT: Just to promote Matt's comment into this answer:

Sadly, this is a bug in ReSharper - it doesn't take visibility of the NotNullAttribute into account before applying it. Here's the ticket to track and vote on: http://youtrack.jetbrains.com/issue/RSRP-413425

Answer 2

NodaTime.dll ships with the JetBrains annotations compiled in as internal symbols, which means they're used internally to NodaTime and not visible for anyone else to use. However, ReSharper can see these annotations that have been applied to the NodaTime classes and methods.

NodaTime doesn't have any binary references to JetBrains.Annotations.dll, and neither ReSharper nor Visual Studio should be adding a reference to a dll based on xml documentation. If ReSharper is able to add a [NotNull] annotation to your code, the dll must be being referenced from somewhere. I'd suggest invoking ReSharper's "go to definition" on the [NotNull] and see where it takes you - it should show you where the annotations dll is being referenced from, and you should be able to remove it easily from there.

Update: As noted above, and in the other answers, the issue is a bug in ReSharper that doesn't check the accessibility of the attribute before applying it. Here's the YouTrack ticket to track and vote on: http://youtrack.jetbrains.com/issue/RSRP-413425