Wpf: Enable WPF projects build from Unix

[daviddenis-stx]

It would be quite useful and practical (for example in CI/CD setup with Linux docker images) to be able to cross compile WPF code using dotnet build from any of the supported platforms (not only Windows). Currently dotnet build on such projects will fail with error, unless executed on Windows.

With this very simple patch (on preview5), compilation goes through (Tested on ubuntu 18.04 LTS)

https://github.com/systemathics/wpf/commit/a9b28ed2998f13ee3c9bce37f405ff820cf43b08

On our code base, the WPF assemblies produced by building from Linux seem to be almost identical to their counterparts built on Windows. The only difference being in BAML embedded resources, they are not binary identical but when decompiled with ILSPY, their XAML content are.

This issue is there to perhaps consider adding cross compilation of WPF projects and/or referencing unforeseen problems that may happen if we do

Note: It could also apply to WinForms projects, we managed to build ours correctly with the above patch, but they fail to execute because of unrelated https://github.com/microsoft/msbuild/issues/2221 (Failure occurs also if built from Windows)

[weltkante]

There was some discussion in #57 I want to bring over here. In particular, if the build process needs to actually load assemblies during builds, please make sure that the diagnostics are sensible when a Windows-only assembly cannot be loaded. Note that this includes failed type loads when they are referencing a Windows-only assembly.

An example would be if a C++/CLI assembly is used then having a reference to any type within it probably would fail to load on Linux. Even if the type to load is in a different assembly it might have a reference and the JIT may need to resolve it. If cross compiling WPF projects is going to be a thing then this needs a reasonable diagnostic.

[peterhuene]

There is also the issue of the .NET Core SDK being unable to update the resources in the apphost (the .exe that gets generated on build) from non-Windows operating systems due to a reliance on a Windows API for manipulating the PE.

Currently you'll get a warning from the SDK and the resulting .exe will not be customized (i.e. no application icon or resources such as custom manifests).

See https://github.com/dotnet/cli/issues/10405.

[wjk]

An example would be if a C++/CLI assembly is used then having a reference to any type within it probably would fail to load on Linux.

Is that not what reference assemblies are for? There is (will be) a reference assembly available for the only public-facing C++/CLI assembly in the repo, System.Printing. Here’s the proof. The other C++/CLI assembly, DirectWriteForwarder, is an implementation detail; all its public types are made visible through PresentationCore.

[weltkante]

Is that not what reference assemblies are for?

Depends on what the WPF build process needs to do. I don't know if it tries to execute any user code at build time, e.g. for custom Markup Extensions ore Type Converters, WinForms certainly does (e.g. licx control licenses, dunno if licensed controls are a thing in WPF). If you need to execute code a reference assembly isn't enough.

Also I was more thinking about 3rd party controls than the builtin C++/CLI assemblies, I don't think reference assemblies will be distributed and picked up correctly for 3rd party controls at the moment. So if you have a 3rd party WPF control which references types in a C++/CLI assembly then it could cause trouble loading those types.

[lindexi]

Make WPF cross-platform (MacOS and Linux support) · Issue #48 · dotnet/wpf

[weltkante]

@lindexi thats unrelated, this issue is about cross-compiling for other platforms which is way easier; WPF still would be Windows only but you could compile on Linux CI machines.

[lindexi]

@weltkante See https://github.com/dotnet/wpf/issues/48#issuecomment-444311347

https://github.com/dotnet/wpf/issues/48#issuecomment-444316969

[weltkante]

@lindexi you are misinterpreting his comment. He's talking about compiling WPF itself for linux/mac. We're talking about cross-compiling projects targeting WPF (on Windows), but compiling on Linux. These are two entirely different things. Cross compiling may or may not need to run the project at all (I don't know the technical details).

[lindexi]

@weltkante I do not think it is far from running across platforms when we can cross compiling.

[weltkante]

You are free to take the step from "cross compiling" to "running on Linux" yourself if you think it is "not far" (your cited comment says otherwise btw.) This issue is not about running WPF on Linux, its about running the build tools on Linux. I tried to explain the difference between the issues, please try to keep the discussion on topic now.

I'll drop out of the discussion here since I already made my point of having appropriate diagnostics when assemblies or types don't load.

[msftbot[bot]]

We appreciate the feedback, however this doesn’t currently align to the project’s goals and roadmap and so will be automatically closed. Thank you for your contributions!

[vanillajonathan]

@daviddenis-stx You should open a pull request. The patch looks simple and makes sense even if it were intended for Windows only.

[lindexi]

@vanillajonathan I try to build in ubuntu but fail. So I think it is not simple.

[xsacha]

We appreciate the feedback, however this doesn’t currently align to the project’s goals and roadmap and so will be automatically closed. Thank you for your contributions!

Roadmap:

Achieve WPF functional and performance parity compared to .NET Framework

Functionally, I can compile .Net Framework with WPF projects on Linux. Functionally, I cannot compile .Net Core 3.1 apps with WPF, on Linux.
This means I am stuck on .Net Framework for the foreseeable future, in order to effectively utilise economic continuous integration machines. Honestly, you know that projects of any decent size will do this.

[weltkante]

Functionally, I can compile .Net Framework with WPF projects on Linux.

Would you mind expanding on this? I'm pretty sure you can't do this without using 3rd party tools, as far as I know Desktop Framework doesn't support running on Linux either. The limitation I mention above that you can't load certain assemblies during build-time (or runtime) on Linux is nothing new for .NET Core so I'm pretty sure it wouldn't work on Desktop Framework given whatever tool you're using (unless you are doing a full blown Windows emulation with something like wine, but then running the same tool for .NET Core shouldn't be an issue).

[xsacha]

I have just been adding a reference to Microsoft.NETFramework.ReferenceAssemblies and it compiled with no other changes.
Switching the target to .Net Core produces the new error as mentioned.
I don't believe there is any technical reason, as the OP discovered.

[weltkante]

I have just been adding a reference to Microsoft.NETFramework.ReferenceAssemblies and it compiled with no other changes.

Not quite sure what you mean, are you using a "new style" project type and use Desktop Framework as TargetFramework? That works on Linux? Are you sure that you have actual WPF content like xaml getting compiled into resources and code?

That would kinda surprise me because as far as I know its just a bug that it ever worked on Windows, the "new style" project type accidently pulled in some build targets from Desktop Framework so compiling xaml using this project type is just an accident and was never planned to work. Though its a bit controversial since people seem to have started taking a dependency on it working on Windows build machines, so they'll probably try not to break it, but as far as I know officially its still unsupported to compile WPF this way, even on Windows.

If I misunderstood what you're doing please explain in more detail. You certainly need some build tools and can't just reference WPF assemblies, otherwise nobody is going to compile your xaml into resources and code. And I don't think the Desktop Framework build tools of WPF would run (or even get installed) on Linux.

[xsacha]

Not quite sure what you mean, are you using a "new style" project type and use Desktop Framework as TargetFramework? That works on Linux? Are you sure that you have actual WPF content like xaml getting compiled into resources and code?

I have a net471 library that uses and requires Windows Desktop with the "new style" project. However, there is no XAML content like you mentioned. Instead, it is C# usages such as 'HostVisual'.

If I add netcoreapp3.1 to the target frameworks, it then complains that I can't compile Windows Desktop and fails to compile.

If the problem is just around the ability to build XAML, then perhaps the error should happen at that stage instead.

[NKnusperer]

It would be super convenient to be able to build WPF apps under Linux for CI using Docker!
Currently we have to deal with the Windows Container shenanigan which is just a mess compared to the Linux ecosystem.
Looking forward that this might become a reality in the future...