Include [TypeForwardedTo] in a.html

[SLaks]

I'm trying to make Ref12 support .Net Core projects.

However, many members (eg, System.Span<>) are defined in System.Runtime the reference assembly, but is forwarded (via [TypeForwardedTo]) to System.Private.CoreLib in the actual source.

Ref12 only sees it as being in System.Runtime, so it opens https://source.dot.net/System.Runtime/Ad.html#d2517139cac388e8, which does nothing.

Can you please change the indexer to process [TypeForwardedTo] attributes and generate links to either the filename or the corresponding a.html in the target project?

[KirillOsenkov]

I thought I had a prototype of this somewhere. I'll look around, maybe someone in the community has it.

[KirillOsenkov]

Looks like @alexperovich has implemented Type Forwarders support in this branch: https://github.com/dotnet/SourceBrowser/tree/source-indexer

[alexperovich]

Yea, I did implement type forward support there. I'm not super happy with it though because I had to go through a lot of hoops because the type forwards in corefx are created with post-compile IL transformations. So the process has to load the compiled binaries to find the typeforwards.

[alexperovich]

If the type forwards were all expressed in C# as [assembly: TypeForwardedTo] attributes then it wouldn't require built assemblies.

[KirillOsenkov]

Now I'm noticing that I seem to have support for resolving forwarded types:

SourceBrowser/src/HtmlGenerator/Pass1-Generation/DocumentGenerator.References.cs

Line 544 in 6c316ee

var forwardedTo = symbol.ContainingAssembly.ResolveForwardedType(metadataName);

Need to investigate why this is not enough.

[Gav-Brown]

@KirillOsenkov Any luck with resolving forwarded types? Ref12 is one of the most useful and frequent extensions I use.

[KirillOsenkov]

@SLaks @Gav-Brown can one of you folks provide a very detailed repro of what's not working as expected? Which codebase, which symbol, which hyperlink? It'll help me investigate. Thanks!

[Gav-Brown]

@KirillOsenkov, @SLaks can probably describe it better than I can, but the following code illustrates what I see.

1. Install the Ref12 Visual Studio extension.
2. Create a new solution with each dll type below.
3. Paste in the same code to each project.

using System.IO;

namespace SomeDll
{
    public class Class1
    {
        public static void TestRef12()
        {
            string a = Path.Combine("hi", "there");
        }
    }
}

4. Right click on Path.Combine
5. Select 'Goto Definition'

.NET Framework dll

Expected: Opens ReferenceSource website on 'Combine' method (.NET Framework version).

Actual: Works as expected and opens

https://referencesource.microsoft.com/#mscorlib/system/io/path.cs,2d7263f86a526264

.NET Core dll

Expected: Opens source.dot.net website on 'Combine' method (.NET Core version).

https://source.dot.net/#System.Private.CoreLib/shared/System/IO/Path.cs,2d7263f86a526264,references

Actual: Opens Metadata

#region Assembly System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.2.0\ref\netcoreapp2.2\System.Runtime.Extensions.dll
#endregion

.NET Standard dll

Expected: Opens ReferenceSource or source.dot.net website on 'Combine' method.

Actual: Opens Metadata

#region Assembly netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
// C:\Program Files\dotnet\sdk\NuGetFallbackFolder\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll
#endregion

In this case there is no "source" but perhaps Ref12 could be enhanced to select a default implementation to show? .NET Framework or .NET Core source? I would certainly find this more useful than just the metadata.

Hope this helps.

[Gav-Brown]

As Microsoft are retiring .NET Framework in favour of .NET Core (.NET 5), for .NET Standard projects I would just stick to the .NET Core source. No need to update Ref12 to specify choice.

[KirillOsenkov]

Apologies I never followed up.

I'm not sure how to get from System.Runtime.Extensions.dll reference assembly to System.Private.CoreLib. There isn't a TypeForwardedTo attribute that would bridge the two.

I'll ask around and see what can be done here.

[Gav-Brown]

@SLaks As an interim solution, for .NET Standard and .NET Core projects, could Ref12 be altered to open source.dot.net with the search parameter set to the fully qualified method name System.IO.Path.Combine e.g. https://source.dot.net/#q=System.IO.Path.Combine

This isn't as streamlined as opening the source page directly, but is close, and adds more value than the metadata.