search

dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
19.11k stars 4.04k forks source link

Wrong CS1574 warning in VS2015 RTM #4050

Open MichaelKetting opened 9 years ago

MichaelKetting commented 9 years ago

In line 124 of https://svn.re-motion.org/svn/Remotion/trunk/Remotion/ObjectBinding/Web/UI/Controls/BocList.cs I have <see cref="IResourceManager.TryGetString"/>. The type "IResourceManager" exists in my solution and is referenced. The method TryGetString also exists and is not ambigous on the type. Still, I receive the following warning:

Code    Description Project File    Line    Source
CS1574  XML comment has cref attribute 'TryGetString' that could not be resolved    ObjectBinding.Web   C:\Development\Remotion\trunk\Remotion\ObjectBinding\Web\UI\Controls\BocList.cs 124

Fully qualifying the reference does not have an effect: <see cref="Remotion.Globalization.IResourceManager.TryGetString(string, out string)"/>

Setting the reference to hardcoded <see cref="M:Remotion.Globalization.IResourceManager.TryGetString(string, out string)"/> works, but then it's no longer part of the reference analysis.

I believe there is some weird edgecase in the reference analysis that broke this reference. I haven't yet had time to try to set up an isolated solution containing just the two types involved, so I don't know just how much ambient noise is required to trigger this problem but the repository is open source.

leppie commented 9 years ago

I believe this was already reported yesterday

MichaelKetting commented 9 years ago

Great. Thanks. I did look but looks like for the wrong keywords :) Do you happen to have an issue number?

MichaelKetting commented 9 years ago

Okay, it happens if you have 3 project: project 1 contains the type as public. project 2 contains the type as internal (same namespace as the public one). project 3 depends on project 1 and 2 and takes a cref-dependency on the member in the type.

Lukazoid commented 9 years ago

Out of interest, why are explicit crefs such as M:Remotion.Globalization.IResourceManager.TryGetString(string, out string) not a part of the reference analysis? I can't see a good reason for it not to be.

When I am writing crefs I sometimes use the compiler generated IDs, so I would write M:Remotion.Globalization.IResourceManager.TryGetString(System.String,System.String@) instead, why are these references not analysed and marked as warnings if they are found to be invalid (either in format or not referencing anything)?