Wpf: Convert C# Reference Assembly Generation to Use GenAPI

[rladuca]

Currently, C# assemblies are building reference assemblies via ProduceReferenceAssembly (corresponding to the CSC flag -refout).

This causes several issues:

• Reference assemblies contain internal types due to WPF's use of InternalsVisibleTo in many of its assemblies.
• Due to this, several reference assemblies may have dangling type references as we move toward the same reference assembly surface as .NET Framework. This was also the case in .NET Framework for some reference assemblies, but this wasn't as strictly enforced.

Currently, the known dangling references are in the PresentationCore and PresentationFramework reference assemblies, the later only when PresentationUI's reference assembly is removed.

To fix these, we want to switch to using the GenAPI tool so that we can tailor the content of the reference assemblies to only contain necessary API surface area.

Our builds directly use ProjectReference for needed assemblies that are in the same repository and will alter these for those that are not available in the same repository (via WpfProjectReference.targets). We likely will have to update this mechanic if internal building assemblies require internals from the reference assemblies.

• [x] Call GenAPI to generate PresentationCore's reference assembly
• [x] Trim output to only needed types
• [x] Do the same for the rest of the publicly building C# assemblies
• [ ] Test package ingestion against dotnet-wpf-int to validate WpfProjectReference.targets
• [ ] Fix issues as needed
• [ ] Apply GenAPI changes to dotnet-wpf-int C# assemblies

[tannergooding]

Reference assemblies contain internal types due to WPF's use of InternalsVisibleTo in many of its assemblies.

If this is the only thing blocking, would it not just be feasible to log an ask on Roslyn to allow this to be configured (that is, to not emit internals to the reference assembly if IVTs are enabled)?

As much as having those internals is non desirable, it is very easy (especially when using new language features) to deviate from what Roslyn considers to be part of the public surface area (and therefore to break downstream consumers who may be dependent on that).

CC. @jaredpar, @jcouv

[tannergooding]

Also CC. @ericstj

[vatsan-madhavan]

I don't know if Roslyn can turn around a feature request for us in <2 weeks... we may want to use GenAPI for now and see if a future Roslyn feature can be adopted.

We need to use GenAPI anyway because Roslyn is not a magic-bullet for WPF (because of C++/CLI).

[jcouv]

I don't know if Roslyn can turn around a feature request for us in <2 weeks...

Probably not at this moment.
@tannergooding, I tried to stop by your office, but missed you. Come find me when you have some time.

[rladuca]

I don't know if Roslyn can turn around a feature request for us in <2 weeks... we may want to use GenAPI for now and see if a future Roslyn feature can be adopted.

We need to use GenAPI anyway because Roslyn is not a magic-bullet for WPF (because of C++/CLI).

I agree, we can pivot back to using Roslyn generated C# ref assemblies when the ability for configuration exists, but for now GenAPI seems like the fastest path toward Preview 7.

[tannergooding]

don't know if Roslyn can turn around a feature request for us in <2 weeks... we may want to use GenAPI for now and see if a future Roslyn feature can be adopted.

Right, and I wasn't meaning to suggest that using GenAPI temporarily for C# code is a bad thing.

I just want to ensure that:

• The Roslyn team is aware that the WPF team had an issue and you are needing to move off the RefOut feature
  
  
  
  • If the Roslyn team isn't made aware, there is little chance they can address the problem
  
  
• It was raised that there may be some limitations or other pain points to utilizing GenAPI instead
  
  
  
  • As extern to Roslyn, it can naturally get out of sync and has to be revisited as impactful features are used in consuming libraries and it becomes aware that there is something that needs to be fixed
  
  

I think it would be generally beneficial to log an issue on https://github.com/dotnet/roslyn/issues tracking the issue here.

[rladuca]

@tannergooding Thanks, I filed an issue for some way of excluding internal surface area from generated reference assemblies.

[rladuca]

Currently building ref assemblies for all C# projects (that require it). Working branch is https://github.com/dotnet/wpf/tree/dev/roladuca/genapics