Clean up ref files to more closely match GenerateReferenceSource

[stephentoub]

Running /t:GenerateReferenceSource leads to a ton of differences between the generated files and what we currently have for the refs. Some of the differences are by design, e.g. ifdefs, but many are not:

• Out-of-order members
• Missing _dummy or _dummyPrimitive fields (which seems like it could be a bug)
• Missing protected ctors on abstract classes
• Whitespace differences, e.g. blank lines, spaces between generic type parameters, etc.
• Missing namespace qualifiers
• Numeric vs named Flags enum attribute arguments
• etc.

It would be good to clean all of this up, in order to a) do an audit to make sure nothing important is wrong, and b) make it easier in the future to use GenerateReferenceSource for minor additions without then needing to deal with a ton of noise.

[AraHaan]

tbh if the netcore packager for netcoreapp#.# and netstandard#.# projects supported generating reference assemblies from the actual sources instead of making reference only projects to make them it could be a better yet approach to not only clean up some of the source tree, but also be consistent with what netframework also supports. I think that would be a better yet solution for things like this.

So like:

- **/ref/* (anything in a ref folder)
+ (have the projects set to produce a reference only assembly based on the code in it).

That way the ref folders in the projects can be deleted.

Or better yet, do not strip the documentations on the actual assemblies of those target platforms (in the case of the xml documentations not being included in the nupkg's).

[ViktorHofer]

From the issue description it doesn't seems like we need infrastructure work, moving back to area-Meta.

[joperezr]

@stephentoub Is this required for 3.0?

[stephentoub]

Is this required for 3.0?

Nope.

[tannergooding]

Here is the baseline patch that I generated for dotnet/corefx#36966: Baseline.patch.txt

I think we would want to review these at the very least, as they can be impactful to some scenarios (like interop or unsafe code):

• Missing _dummy or _dummyPrimitive fields (which seems like it could be a bug)
• Missing protected ctors on abstract classes

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

[ericstj]

@Anipik /@safern didn't we do something like this already? I thought we got the diff pretty clean after supporting follow-type-forwards.

[Anipik]

I thought we got the diff pretty clean after supporting follow-type-forwards.

We fixed the scenarios(there was a couple of them) where it was not working, but we never did a whole sweep up.

[safern]

I think we should do another pass. I remember for stuff that was manual added into the ref src files we added a feature to specify a file with ignored APIs so that should help us get it better for complicated assemblies like System.Runtime.