Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Discrepancy in analyzer behaviour between IDE, msbuild, and MSBuildWorkspace #20373

Open
saquibmian opened this issue Jun 21, 2017 · 4 comments
Open

Discrepancy in analyzer behaviour between IDE, msbuild, and MSBuildWorkspace #20373

saquibmian opened this issue Jun 21, 2017 · 4 comments
Labels
Area-Analyzers
Milestone
Backlog

Comments

@saquibmian
Copy link

saquibmian commented Jun 21, 2017 •
edited
Loading

Version Used:
Microsoft.CodeAnalysis 1.2.0
Visual Studio 2013 Update 3

Steps to Reproduce:

  1. Write an analyzer that calls ITypeSymbol.GetMembers() on field types.
  2. When running in Visual Studio or through msbuild/csc, only public members are picked up.
  3. When building through MSBuildWorkspace, all (private, internal, and public) members are picked up.

Expected Behavior:
Not sure. Definitely expect analyzers to do the same thing no matter where they are run, otherwise analysis can differ between whether running in the IDE, building via msbuild, or building via MSBuildWorkspace.

Actual Behavior:
See (2) and (3).
@saquibmian saquibmian changed the title Discrepancy in analyzer Discrepancy in analyzer behaviours between IDE and msbuild Jun 21, 2017
@saquibmian saquibmian changed the title Discrepancy in analyzer behaviours between IDE and msbuild Discrepancy in analyzer behaviour between IDE and msbuild Jun 21, 2017
@saquibmian
Copy link
Author

See also these related issues:

@j3parker
Copy link

👍

If this is intended to increase performance for builds perhaps DiagnosticAnalyzers could specify their requirement upfront so that it would only decrease perf for builds that needed this based on the analyzers they use.

@saquibmian saquibmian changed the title Discrepancy in analyzer behaviour between IDE and msbuild Discrepancy in analyzer behaviour between IDE, msbuild, and MSBuildWorkspace Jun 22, 2017
saquibmian pushed a commit to Brightspace/D2L.CodeStyle that referenced this issue Jun 28, 2017
Hack the relevant analyzers to import all metadata.
9050c43 
We do this because analyzers can behave differently depending on what context they're running in (see: dotnet/roslyn#20373).

This should solve the problem, because as far as I was able to dig into the code, member enumeration is completely lazy and checks that option from `Compilation.Option` all the time. This works in `msbuild`, but Visual Studio seems to override the behaviour. Still working on that...

We also just throw completely if the options are not set correctly, as we can't be safe.
@saquibmian saquibmian mentioned this issue Jun 28, 2017
Merged
@jinujoseph jinujoseph added this to the Unknown milestone Jul 23, 2018
@themightyzek
Copy link

themightyzek commented Oct 21, 2020 •
edited
Loading

I am experiencing an issue like yours when calling SemanticModel.GetOperation(SyntaxNode node).
When called during live analysis, it returns an ISymbolInitializerOperation object for a corresponding EqualsValueClauseSyntax.
During an MSBuild execution, it returns null and throws a System.ArgumentException for that same EqualsValueClauseSyntax.

Also, Compilation End actions are not being called during live analysis. @heejaechang has said in 2017: #4068 (comment)

I think we should make compilation end analyzer on opened files should work even if FSA [Full Solution Analysis] is off.

Has this been done? No issue was mentioned in the discussion back then.

@ronimizy ronimizy mentioned this issue Feb 9, 2022
Open
@dennis-yemelyanov
Copy link

Has anyone found a solution for this? I also noticed the discrepancy when running an analyzer/source generator, even with MetadataImportOptions explicitly being set to All. Opened an issue here: #72369

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Area-Analyzers
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
6 participants
@Pilchie @j3parker @saquibmian @dennis-yemelyanov @jinujoseph @themightyzek