WPF build projects hand pick the Microsoft.NETCore.App references #9168
Comments
|
The core problem is that we don't put any effort into testing subsets of our reference sets. There isn't really any effort into verifying a particular feature works with a subset of references, instead we put the effort into making sure that features work with the .NET X reference set. When you subset references you risk running into a number of problems:
There is also no meaningful perf benefit to referencing less assemblies. The compiler aggressively caches references, particularly ones in the core .NET reference set. |
|
@singhashish-wpf who is the right person on your team to chat about this? |
|
@rchauhan18 and I will look into this, Let us know if there is something which should be changed. |
singhashish-wpf
added
the
Investigate
|
We basically want to understand why you hand pick references, i.e. in wpf/src/Microsoft.DotNet.Wpf/src/PresentationUI/PresentationUI.csproj Lines 229 to 257 in 47efe46 ... instead of just letting the TFM + FrameworkReference bring everything in automatically. |
This has been the same since WPF was open sourced. So basically this has origins in .NET FX, same code. |
|
@singhashish-wpf sure but why do we do this? As I mentioned above it's a recipe for hitting a number of problems because it's explicitly not tested. For WPF this turned into friction shipping .NET 9 features where as if WPF used the full reference set this wouldn't have happened. It's reasonable to expect that this will happen again in the future. Is there a reason you all can't use the normal full reference set here? |
|
@jaredpar We are going run the experiment, to remove these references and use TFM + FrameworkReference thing, validate that first. Will update the thread with the findings. |
|
I did some snooping around to try to find if there was a reason for I looked at the System.Xaml project because it was the first project open sourced in this repo and I saw that it hasn't always used I also saw this comment in the build files that might give some clues about the use of wpf/eng/WpfArcadeSdk/tools/Pbt.targets Lines 29 to 37 in 675f95f An explanation could be that it is to require explicit reference to new assemblies to avoid loading too many assemblies at runtime. WPF has a bad rep about slow startup and it employs a couple of "tricks" to reduce the need to load assemblies so this might be one of them. I don't know if those "tricks" are still needed or if this particular issue is one of those "tricks". |
The number of (reference) assemblies that are passed to the compiler don't impact the number of assemblies that are loaded at run time. The runtime probes for and loads an assembly (with non-deterministic ordering) when it finds a type that needs to be resolved. |
That's true but what I meant was that with explicit references it means that you cannot use types from an assembly not explicitly referenced so it won't trigger the load of the assembly at runtime. |
This removes the `NetCoreReference` infrastructure and replaces it with `DefaultReferenceExclusion` to remove the one problematic implicit reference to WindowsBase. Manually picking references was blocking using System.Private.Windows.Core from the WinForms repo. Not having this also greatly simplifies the projects. This also tweaks the solution to add folders docs and eng items. Fixes dotnet#9168
This removes the `NetCoreReference` infrastructure and replaces it with `DefaultReferenceExclusion` to remove the one problematic implicit reference to WindowsBase. Manually picking references was blocking using System.Private.Windows.Core from the WinForms repo. Not having this also greatly simplifies the projects. This also tweaks the solution to add folders docs and eng items. Fixes dotnet#9168
Projects in this repository hand pick the targeting pack references that come from the Microsoft.NETCore.App.Ref targeting pack which recently caused issues that required actions:
I would like to understand why wpf projects hand pick references. @jaredpar mentioned that there isn't really any benefit in doing. Libraries in runtime that are out-of-band did this as well in the past but we changed that a few years ago.
cc @ericstj
The text was updated successfully, but these errors were encountered: