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
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
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
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
* Remove NetCoreReference 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 #9168 * Put back test projects in solution * Enable xunit testing in VS with the dispatcher This change enables writing and debugging unit tests in the Test Explorer in Visual Studio. I added a new test project for WindowsBase that has a unit test that launches the SplashScreen as an example. In order to make this happen I had to reference the xunit.stafact package which introduced a number of challenges to overcome. The package has a reference to the desktop sdk and needs to be used in a project that targets `net10.0-windows`, not `net10.0`. To make everything work seamlessly I had to: - Strip the platform reference - Apply actual versions from the sdk - Get rid of AnyCPU and explictly use x86 (everything has a native dependency) - Enable transitive copying of references for the unit test projects - Target the 10.0 SDK (would get version confusion otherwise) - Add an override setting for WinForms which still targets the 9.0 SDK - Remove other targets that were trying to fixup WindowsBase references from the .NET SDK - * Make PresentationBuildTasks always AnyCPU * Update versions and tweak / simplify some version related stuff * Attempt to turn on the binlog for the CI * Update binlog names for both build and test run * Try 17.12 preview * Move back off of scout image * Update versions * Push back to 9.0 * Uncheck D3DCompiler in ConfigurationManager * Have ref projects only reference ref projects and move ref and cycle breaker projects to AnyCPU. * Normalize ARM64 to arm64. Having multiple casings was causing projects to be built multiple times to the same folder. * Revert RuntimeFrameworkReference.targets changes * Final cleanup pass * Tweak SdkReferences.targets * Respond to feedback
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: