Bug 60493 (vs-521356) - Red "squiggles" under every usage of a netstnd2 lib in XM project that builds/runs fine
Summary: Red "squiggles" under every usage of a netstnd2 lib in XM project that builds...
Alias: vs-521356
Product: Xamarin Studio
Classification: Desktop
Component: Project Model (show other bugs)
Version: Trunk
Hardware: PC Mac OS
: Normal normal
Target Milestone: 15.7
Assignee: Matt Ward
Depends on:
Reported: 2017-11-02 14:44 UTC by Chris Hamons
Modified: 2018-05-04 14:29 UTC (History)
3 users (show)

See Also:
Tags: vs-sync
Is this bug a regression?: ---
Last known good build:

Image (23.03 KB, image/png)
2017-11-02 14:44 UTC, Chris Hamons

Description Chris Hamons 2017-11-02 14:44:06 UTC
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

Software installed:


Restarting VSfM or running does not change behavior.

Image of error attached
Comment 2 xamarin-release-manager 2017-11-13 16:04:21 UTC
[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:
Comment 3 Matt Ward 2017-11-13 16:05:31 UTC
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:

Comment 4 Matt Ward 2017-11-13 17:24:35 UTC
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
Comment 5 Matt Ward 2017-11-14 09:56:58 UTC
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:

Comment 6 Greg Munn 2018-05-04 14:29:42 UTC
Fixed in version (d15-7)
Pull Request #3080 merged by: Lluis Sanchez
Author: xamarin
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 when applicable.

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 description here:

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.

Note You need to log in before you can comment on or make changes to this bug.