Retain full assembly information for forwarded types

[dend]

As an example, System.Net.WebResponse is forwarded from System.Net.dll, therefore System.Net.dll is not included in the list of assemblies that show the origin of the API. The request is to include the full list of assemblies in the final ECMAXML output.

[mairaw]

Can we add some attributes to this information so that we can filter type forwards from the UI?

[dend]

@mairaw type forwards or assembly information for forwarded types?

[mairaw]

Let's look at my example workaround. If we fix this just by adding the assembly to the list as we do with the other regular assemblies:
dotnet/dotnet-api-docs@ad1cd87

We end up with the whole list of assemblies in the UI and in the metadata:

Ideally, this assembly info for forwarded types should only show up in the metadata and not in the UI. That's why I'm asking you to distinguish the assemblies we have there right now which is their true location and these implementation details that only matter to us internally.

[mairaw]

But as usual, I'm open to take a two- or even three- phase approach if needed. Where first we fix the most immediate issue which is recognizing the type forwards assemblies, and then later we recognize the true assemblies and filter them out from the UI.

[dend]

Hiding the assembly from the view is something we need to address on our side. @joelmartinez - something to consider here is potentially adding an attribute to the assembly node, something like forwarded="true", that will allow us to distinguish which assemblies are "true" and which are the ones we need to hide.

[joelmartinez]

Well, it's not quite as simple as that ... because the assemblies don't currently have any indication of what framework they're a part of (see #103). So there might be a scenario, where a type is present in some assembly in one framework, is forwarded from that assembly in another.

So for example (this is truly an example, I don't know if this kind of graph exists anywhere/currently, but it might):

• SomeType exists in SomeAssembly.dll in Framework1
• SomeType is forwarded from SomeAssembly.dll to SomeSecondAssembly.dll in Framework2

In that case, a naive implementation would make SomeAssembly.dll as forwarded="true". So I suspect that we might have to, by definition, solve #103 in order to solve this one.

OR we could simply list all assemblies, without any kind of additional metadata ... and then on the front-end we could filter those out entirely (by virtue of having the "truth" listed via #103 in the FrameworksIndex files).

[mairaw]

Yes, I understand is not easy. Let's start with the solution that lists all assemblies and we go from there.