WPF SDK feedback - netfx/corefx multitargeting about installer HOT 7 CLOSED

I believe all of the feedback has been addressed at this point. Let me know if I'm missing something and we can reopen.

from installer.

Everything's working well in the builds I've tested.

from installer.

cc/fyi @nguerrera

from installer.

Thanks for this feedback.

The SDK doesn't contain a glob for Page items, nor does it nest them using DependentUpon.

We would like page items to be globbed. There are some challenges around it, but that is the goal.

Building in visual studio sometimes takes a couple of tries. in particular the first clean rebuild seems to fail. This seems related to the generated xaml project.

I haven't seen this yet, it might be worth opening a separate issue with repro steps.

When importing the props and targets, netfx must not use Microsoft.NET.Sdk.Wpf, because it already has winfx.targets coming from Microsoft.NET.Sdk. However, corefx needs the WPF targets imported after the core sdk targets. this means we can't use Project Sdk= but must instead decompose the sdk into hand-written imports.

This should sort itself out once we have build working on core.

dotnet build cannot be used yet

Folks are working on it.

in particular, failures to load xaml will be reported at runtime as a ArgumentNullException failing to format an error.

This is fixed in recent WPF builds. I'll try to get it inserted.

The lack of a Properties.cs in .net core projects - for the most part a good thing - means that there's no obvious place to put the ThemeInfo attribute required for control xaml discovery.

This one seems minor. You can just create a ThemeInfo.cs or even Properties.cs without the other assembly info attributes in it.

from installer.

Good to hear that much of this stuff is already known. I'll create a repro for the rebuild-fails thing as well as for any issues i encounter when porting some existing libraries and applications to the alpha. On a couple of specific points:

You can just create a ThemeInfo.cs or even Properties.cs without the other assembly info attributes in it.

Yes, this is what I did in the linked repository. The new dotnet wpf template doesn't do that, though, which means if people try to build custom control libraries without having fully understood the requirements they might be surprised that what worked on framework seemingly doesn't work on core.

This should sort itself out once we have build working on core.

It would be great if Microsoft.NET.Sdk.Wpf just worked when multitargeting - with the way it works now you could achieve this by making its targets conditionally import winfx depending on whether it's building for full framework. But, the whole scenario is slightly weird: sharing code between desktop-wpf and core-wpf will be necessary for businesses to transition, which means multitargeting, which means using the new project system... which hasn't been supported previously.

In short, to get adoption for WPF on .NET Core it will require some nontrivial build process changes for WPF on .NET Framework! This probably doesn't have to be a first class scenario, because library authors are more likely to know what they're doing than app authors, but it does have to be possible (as it currently is, though I get the feeling the tooling is going to change a lot).

from installer.

Agree that multi-targeting is important.

When library authors moved to netstandard, most of them switched to multi-targeting to avoid braking changes to existing consumers. If companies and control / lib authors now also want to enable consumption from .net core, multi-targeting is also going to be an important scenario.

from installer.

@gulbanana Have you tried multi-targeting with Preview 1 or more recent bits. It should work now to dotnet new wpf and change TargetFramework to TargetFrameworks=net46;netcoreapp3.0.

from installer.