Investigate solutions for fragility between wpf and wpf-int

[mmitche]

Whenever the compiler changes its CIL version (would happen on some VS updates), WPF will break until wpf-int rebuilds and flows into wpf. This is annoying, but a larger problem now with the VMR, because wpf-int must flow to wpf, then wpf into the VMR, before the VMR will build again.

This happens because LTCG compilation to a .lib encodes the CIL rather than compiled machine code. When LTCG linking happens against the input lib + other source objs to create a PE, the CIL versions must match for things to work. This is generally not an advised way to compose a product because of the fragility of the CIL interface.

The suggestion is that LTCG should be turned off for native libraries in wpf-int that are packaged up into nupkgs and used downstream. We would need to understand the following:

• Why was this turned on in the first place
• What are the performance implications.

bilinearspan.lib appears to be at least one source of issues.

/cc @ViktorHofer @ericstj

[ViktorHofer]

cc @pchaurasia14 @agocke @MichalStrehovsky

[pchaurasia14]

@mmitche - We don't know the reason why this was done (given that this is how historically WPF builds have been working). We'll need to investigate this more.