roslyn: Missing AccessorDeclarationSyntax.ExpressionBody

I’m creating an CodeFixProvider for an analyzer and stepped on the following issue:

According to the source , AccessorDeclarationSyntax.ExpressionBody is public. I can see that property through VS watch, but I can’t access it through my normal code (‘AccessorDeclarationSnytax’ does not contain a definition for ‘ExpressionBody’) - note that this is not an “inaccessible due to its protection level” error. As an expression bodied property accessor contains no Body (property is null), I can’t be sure if whether my property is an “auto-prop” or not. Am I missing something here?

Please refer me to the right place to ask this if it’s not here.

About this issue

Original URL
State: open
Created 7 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

if it is a version-related problem, why does the property shows up in the QuickWatch? Shouldn’t it use the same version I’ve used to compile the analyzer?

Assembly binding redirection is used to make your analyzers operate against the most recent known version at runtime.

If you compile against the same version as the IDE uses, you’ll have a version match
If you compile against an older version than the IDE uses, you’ll see the newer version at runtime (and while debugging). The API you see when you compile will be a subset of the API that actually exists on the objects at runtime.
If you compile against a newer version than the IDE uses, your analyzer will not work at runtime.

By compiling against Roslyn 1.0.1, you fall into the second point for everything newer than Visual Studio 2015 RTM. With this selection, your analyzer is compatible with the most versions of Visual Studio possible for Roslyn, but you will not be able to specifically analyze C# 7 syntax (because they were added in the Roslyn 2.x API).

As far as the project and nuget issue, I’m not sure. @sharwell may be able to assist.

When I last tried this migration, I kept hitting issues (which may now be resolved). A pull request was submitted to StyleCop Analyzers which claims to make the change you are requesting, but I haven’t yet reviewed it in detail: DotNetAnalyzers/StyleCopAnalyzers#2327

sharwell on May 15, 2017