WPF support

[wjk]

This PR adds support for WPF-based projects to the new, SDK-based project system, including full designer support. It should support C#, F#, and VB.NET projects (although I have only tested it with C#).

Note that for each project that wants to include WPF code, the following code must be placed into its project file:

<PropertyGroup>
  <EnableWpfTargets>true</EnableWpfTargets>
</PropertyGroup>

This is because I didn't want the WPF targets being included where they are not needed, because they are fairly invasive. If this code is not added, the WPF targets will not be included (and weird build breakage will likely result).

This PR supersedes #20, which should be closed once this is merged. Thanks!

[wjk]

Note that you’ll have to add **/*.xml to the <None /> line in the csproj, or else the MSBuild rules files won‘t get included in the NuGet package, and weird failures will result. I’d do this myself, but it’s getting late. 😄 I can either add that code tomorrow, or you can do it yourself once this is merged. Thanks!

[davkean]

Can we contribute the built-in item rules to http://github.com/dotnet/project-system instead of adding them to this project? Rules should only be added for items that you own yourself. I will happily take the contribution.

I would definitely recommend you run this targets file under the new evaluation profiler: dotnet/msbuild#2765. Globs and updates are not free - and this adds a bunch. Slow evaluation leads to increase project load time, larger design-time builds for those projects that reference you (including .NET Framework based on the legacy project system), which can lead to UI delays and slow project manipulation.

[clairernovotny]

Can you please also add the *.XAML None include to ensure it gets all packed correctly?

[clairernovotny]

I don't see any differences in the file between the VS location and the SDK location. It's likely that the VS location just includes "more."

Given that projects built with these targets aren't supported by dotnet build (they require msbuild.exe, I think it's safe to always include these WPF additions. no need for a conditional import.

[clairernovotny]

See comment below. I think it's safe to always import these.

[clairernovotny]

The removes can have an extra condition:
https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.DefaultItems.props#L29
And '$(EnableDefaultNoneItems)' == 'true

[clairernovotny]

Can we do this without an update? Just put this on the Page include above?

[clairernovotny]

@davkean I'm going to accept this here for now. I really wish there was a VS Version property passed into the design time build that had the full version info. Closest I see now is 15.0, which isn't good enough.

I want to get these in ASAP but would prefer to condition them on specific builds of VS so we could use the in-box ones.

[wjk]

@davkean How should I run the MSBuild profiler, and how should I interpret the results? This is my first time using this feature. Thanks!

[clairernovotny]

@wjk @sharwell I'm seeing errors while trying to use this as a package.

https://github.com/onovotny/MSBuildSdkExtras/tree/wpf-sample

It seems to work in the test projects when they're directly included. Any ideas?

[clairernovotny]

There's a start of workaround that I added to the branch, but I still get this:

1>Target GenerateTemporaryTargetAssembly:
1>  Target CoreCompile:
1>    Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn
1>    MainWindow.xaml.cs(25,13,25,32): error CS0103: The name 'InitializeComponent' does not exist in the current context
1>  Done building target "CoreCompile" in project "jyurx4g3.tmp_proj" -- FAILED.

From what I can tell looking at the binlog, it's not generating the file for the XAML files.

[wjk]

@onovotny Yeah, that's what I'm seeing as well. I'm not seeing the MainWindow.g.cs file anywhere. It is generating the App.g.cs file, though. How weird.

[clairernovotny]

Wait, nm, I had an error...was missing the x:Class.

[clairernovotny]

Still have a nasty work around for NuGet/Home#5894 :(

[wjk]

Yep, that was it re the MainWindow.g.cs issue. Will submit a second PR re the NuGet bug using material from dotnet/msbuild#2701. Thanks!

[wjk]

Actually, as it turns out, the linked MSBuild issue depends on another PR (NuGet/NuGet.Client#1786), which may take a while to merge because of licensing issues (they say it contains some code that hasn't gotten the official OK from MS Legal). Nevermind my previous comment, as it wouldn't have worked.

[sharwell]

Still have a nasty work around for NuGet/Home#5894 :(

Can you point out the hack in code?

[clairernovotny]

@sharwell The fact the csproj has to have this at the top: https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/master/PackageExplorer/NuGetPackageExplorer.csproj#L3-L7

and this at the bottom: https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/master/PackageExplorer/NuGetPackageExplorer.csproj#L50-L51

[clairernovotny]

@sharwell It's because PackageReference for WPF projects is currently broken in general due to the two-pass compile and the tmp_proj file extension it uses.

[mungojam]

I tried using the extras package plus the workaround yesterday and got 2 errors:

1. It couldn't find a main method in the WPF project
2. It couldn't resolve the InitializeComponent method.

That was after using the https://github.com/hvanbakel/CsprojToVs2017 project converter

For now I've reverted to using the old style project. Let me know if you think it should work and I can try again and provide more details.