Created attachment 25544 [details]
Steps to reproduce:
- git checkout https://github.com/chamons/mac-samples/tree/netstandard_red_line_bug
- Build and open TacoFinder/TacoFinder.Mac/Outline/TacoSource.cs
- Move to line 42 and Options.Brands.Count (); will be marked up
Restarting VSfM or running does not change behavior.
Image of error attached
May be related to https://developercommunity.visualstudio.com/content/problem/142152/the-type-or-namespace-name-could-not-be-found-erro.html
[VS-5] Comment by Matt Ward:
Also seem to have a similar problem for .NET Framework projects. With a .NET 4.7 project using basically the same code from the TacoSource's GetChildrenCount you see the same errors about missing the IEnumerable from netstandard. When you build the project msbuild resolves the netstandard.dll from:
Original VSTS comment did not sync across for some reason so duplicating it here:
Initial investigation into this. VS Mac's type system does not receive the netstandard.dll when it calls DotNetProject.GetReferencedAssemblies. The iOS project in comparison does return netstandard.dll from this method.
In DotNetProject.OnGetReferencedAssemblies there is some code that adds the facade assemblies to the results if the project references a PCL project or a .NET Standard project. For Xamarin.iOS this works since there is a netstandard.dll in its facades directory:
The Xamarin.Mac project targets .NET Framework 4.7 so it uses that folder when finding the facade assemblies.
This directory does not contain netstandard.dll, presumably deliberately. Which results in the netstandard.dll not being available to the type system and so you see errors in the text editor about types from it being missing.
The facades folder used here seems to be incorrect for Xamarin.Mac Full, which is what the project is using. There is a Xamarin.Mac full 4.5 folder but no 4.7 folder - which I believe results in the References showing errors for all references apart from the project reference:
Just wondering if mhutch's ResolveReferences change would fix this:
Currently VS Mac uses ResolveAssemblyReferences and then adds the facades.
The ResolveReferences MSBuild target looks like it returns the correct assemblies including netstandard for the TacoFinder.Mac project. Although my test is currently limited to running 'msbuild /t:ResolveReferences /v:diag TacoFinder.Mac.csproj' and I may be misinterpreting the output.
Another idea would be to override the DotNetProject's OnGetReferencedAssemblies method and implement it in the Xamarin.Mac project extension. Although ideally we want to be able to use the DotNetProject's RunResolveAssemblyReferencesTarget method, which is private. Otherwise I guess the DotNetProject's OnGetReferencedAssemblies method could be called and then the facade dlls could be removed and then the correct facade assemblies could be added - but this is not ideal
Tried a build of the resolve references pr 2445 branch locally and also created one on Wrench and there seem to be other problems with this branch so I am unable to see if it fixes the problem. Currently this branch, which is a few months out of date, throws a null reference exception when the TacoFinder solution is opened, the class information icon remains in the status bar and no code completion information is available:
Fixed in version 18.104.22.1681 (d15-7)
Pull Request #3080 merged by: Lluis Sanchez
Commit: ca9bc3575ea53c0940a34569fd1630a0df96bb2f (xamarin/md-addins)
Included in Commit: 086c5cc9cf20e6559540a05385a8604b1cf5bf48 (mono/monodevelop)
Notice (2018-05-21): bugzilla.xamarin.com will be
switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.
Please join us on
Visual Studio Developer Community and
GitHub to continue tracking
issues. Bugzilla will remain available for reference in read-only mode.
We will continue to work on open Bugzilla bugs and copy them to the new
locations as needed for follow-up. The See Also field
on each Bugzilla bug will be updated with a link to its new location
After Bugzilla is read-only, if you have new information to add for a
bug that does not yet have a matching issue on Developer Community or
GitHub, you can create a follow-up issue in the new location. Copy and
paste the title and description from this bug, and then add your new
details. You can get a pre-formatted version of the title and
In special cases you might also want the comments:
Our sincere thanks to everyone who has contributed on this bug tracker
over the years. Thanks also for your understanding as we make these
adjustments and improvements for the future.