Extend member access analysis to events

[amcasey]

Presently, only methods and properties are handled.

Caveat: only += and -= are handled - raw event accesses didn't fit nicely, since there's no method invocation, and didn't seem high-priority (since they can only occur within the declaring type).

[amcasey]

FYI @jessetrinity

[amcasey]

I expect the tests to fail. I'm getting a MissingMethodException (for IEventAssignmentOperation.get_EventReference) at runtime because the product code targets Roslyn 2.8.2 and the tests target 3.11.0. The only difference I see is in nullability attributes and, if that's the problem, I'm not sure why the existing code is unaffected.

[amcasey]

This might fix #232?

[AArnott]

The missing method is:

[Microsoft.CodeAnalysis]Microsoft.CodeAnalysis.Operations.IEventReferenceOperation [Microsoft.CodeAnalysis]Microsoft.CodeAnalysis.Operations.IEventAssignmentOperation::get_EventReference()

The method that actually exists is:

.get instance class Microsoft.CodeAnalysis.IOperation Microsoft.CodeAnalysis.Operations.IEventAssignmentOperation::get_EventReference()

Note the difference in return type. The runtime version returns IOperation whereas the compile-time ref assembly defined a return type of IEventReferenceOperation.

This binary breaking change was made between 2.8.2 and 2.10.0. It was introduced here and @mavasani recognized that breaking change, so it was not an accident.

I think we'll have to target 2.10 instead of 2.8 to make this work. I don't know which VS version that ties to, but it's probably still a Dev15-era version so I don't think it'll be a problem.

[AArnott]

This might fix #232?

I don't think so. That issue is about how we interpret the invocations of the event handlers, rather than how we invoke the add and remove methods on the event itself.

[amcasey]

@AArnott Thanks! I missed the return type.