Federation doesn't work against source.dot.net

[mconnew]

I'm trying to set up a source browser for the CoreWCF project and would like all the links to the .NET types to go to https://source.dot.net. I used the following command line to generate the SourceBrowser site:

$(PkgSourceBrowser)\tools\HtmlGenerator.exe $(SourceDir)CoreWCF.sln /out:$(OutputPath)Index /nobuiltinfederations /federation:https://source.dot.net /federation:http://sourceroslyn.io /force

The indexing of the CoreWCF solution worked, but the offsite links are incorrect. When viewing TextMessageEncoder, one of the fields is of type System.Text.Encoding. The link generated for the type is https://source.dot.net/netstandard/A.html#3b6090c501893c25 but the link should be https://source.dot.net/System.Private.CoreLib/A.html#3b6090c501893c25. I presume this is because the CoreWCF libraries are compiled against netstandard2.0 and the name of the referenced assembly is netstandard.

Is there a way to fix these federated links to go to the right place?

[KirillOsenkov]

@ljcollins25

[ljcollins25]

@mconnew
I'm curious about your use case. I'm working on a successor to SourceBrowser, in which all repos will be aggregated together on a central server and can be incrementally updated independent of each other. Essentially, this would mean you code add corewcf directly to an equivalent of https://source.dot.net. Would this fit your use case? Do you have particular requirements or preferences around the update cadence? Currently, I'm updating repos once a day, but individual repos could be updated more or less frequently.

[mconnew]

That would satisfy one use case. What I have been planning is to have two sites available, one for the current GA release, and one for the current in-development release (updated on every merge as we don't have a lot of merges). Our current 1.x release supports netstandard2.0 and runs on .NET Framework. At some point we're going to drop netstandard2.0 support and have a minimum requirement of the latest .NET LTS release. When that happens, our latest 1.x version will be a perpetually supported version so we would have 3 sites available. The latest GA release, the latest 1.x release, and the dev version. If there's an opportunity to have our code published to a central site, then the latest GA release would be the one we would want published. We'll work out the hosting of the dev/1.x version ourselves.

A bit of feedback with you developing the successor, currently source.dot.net hosts the source as is built for Linux. I use source.dot.net as a replacement for having to clone the repo and load it in VS as navigating the source is really easy. When trying to explore the source code on source.dot.net, it would be nice to be able to choose different compile time defines, e.g. building for Linux vs Windows. When I was implementing NetNamedPipe and I needed to understand the behavior of the runtime named pipe classes, I had to browse the source code on github.com as the implementation is a lot different on Linux (and NetNamedPipe is a Windows only feature).
Anothing thing which would be great, to be able to filter the set of projects/packages used to search. There's a lot of overloading of type names. As a simple example, WCF and another package both have an IChannel interface. CoreWCF has a lot of the same types as WCF, but in a different namespace. Having them both exist in the same search space without having a persistent filter (don't want to apply it for every search done) will make searching a little more noisy.