Неизвестная ошибка сборки файл не найден wpf

I don’t think WPF has been/will be ported to MacOS

Does the bug reproduce also in WPF for .NET Framework 4.8 on MacOS?:

Does the bug reproduce also in WPF for .NET Framework 4.8 on MacOS?:

LOL

I don’t think WPF has been/will be ported to MacOS

Correct. WPF is Windows only.

Thanks for the confirmation that WPF projects won’t be supported on macOS.

I don’t think we should block anything on dotnet new. You could just as easily clone or type in the same project. As such, the right place to verify is in the build. That said, without committing to anything, building wpf from non-Windows (cross compilation) is separate from running an application. The former can be made to work without the latter. Again, I am not committing to anything here, but it might be possible to make dotnet build work and leave the failure to dotnet run, which would tell you that there is no WindowsDesktop runtime.

Guessing from the error message, it looks like the first thing hit here is a ‘/’ vs » mixup.

OK, that makes sense. Let’s see if more people hit this problem then and if it is something we should address sooner rather than later to provide more clarity …

Quick inspection, there are some hard-coded » in the build task source. There is also a mismatch of Microsoft.WinFX.targets in import vs Microsoft.WinFx.targets, which will cause this to fail even earlier on Linux. These are easy enough to fix, the question is whether something bigger lurks behind them.

@nguerrera I just encountered both issues that you mentioned, but I couldn’t find the Microsoft.NET.Sdk.WindowsDesktop.targets sources anywhere. Am I right to assume that they have not been open sourced yet?

OK, that makes sense. Let’s see if more people hit this problem then and if it is something we should address sooner rather than later to provide more clarity …

FWIW I just hit this issue as well. Running

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010184
 Commit:    c57bde4593

I’ve also understood it that WPF is not and will not be supported on mac OS but after being encouraged by this post I gave it a try, which lead led to the issue at runtime.

In fact it seems possible to build WPF/WinForms projects from non Windows (Tested with bionic/amd64, we don’t use mac) with a quite simple patch (here on .NET Core 3.0 Preview5). There was two problems to address

1. Microsoft.WinFx.targets casing required to be harmonized (for case sensitive file systems)
2. PresentationBuildTasks assembly source code used hard coded const string » as directory separator in several locations

As a result, we seem to be able to build WPF/WinForms assemblies from Linux (cross compilation). I see the two markup compilation phases happening for WPF and diffing assemblies between plain Windows non patched build and Linux patched build gives the exact same outputs. Cross compiling is quite useful as we now can CI/CD using a lightweight Ubuntu-x64 docker image (instead of a quite big Windows VM). It should also probably work from other Unix flavours (Mac, etc …).

If someone is interested I will create a PR

Patch (Could do PR)
daviddenis-stx@a9b28ed

Docker images (Testing, not for PR)
daviddenis-stx@d122d93

@daviddenis-stx did you test this with custom Controls and MarkupExtensions? I don’t know the technical details of the markup compilation phase but I’d expect it to require loading the assembly and possibly even running some code? If so, then cross compiling could become pretty fragile as soon as 3rd party controls using Windows features are involved. When going this route it should be made sure that the error messages are appropriate when loading or execution of assemblies fails during markup compilation.

I tried to compile code using controls from Xceed extended WPF toolkit (restored as net 461). The build goes through and diffing the assemblies give something identical (the baml resources are not binary identical but decompiling them with ILSpy gives binary identical xaml text). Ideally we would need a great deal of unit testing. I’m curious of anybody willing to try to compile something of their own making to see how all that goes

At least this patch would correct self evident mistakes that prevent the build to even occur. I agree that it requires a lot of testing. We will do that on all our UIs and get back with more materials (proper runtime testing on Windows) but it’s probably not covering all the possibles. I guess it mostly boils down to underlying dependencies (are they net standard? do they use pinvoke? properly made nugets ?) if assembly loading happens it’s not clear why it would work on netcore windows and not linux?

Let’ s compile more WPF code with the proposed docker images, then diff assemblies, then execute. We should know rapidly if something bites.

if assembly loading happens it’s not clear why it would work on netcore windows and not linux?

C++/CLI doesn’t load on Linux/Mac, so if you’re using any type from such an assembly (possibly indirectly) it could trigger a failed assembly load, possibly cascading back to types failing to load in other assemblies.

I don’t expect it to be the common case, I just want to make sure this edge case is considered and has a reasonable diagnostic.

Makes sense. We had to just exclude C++/CLI assemblies from our codebase when migrating to netcore (I talk non UI assemblies). We may want to find a thirdparty with such a construction to test but it’s probable that those are going to dissappear eventually.

For the record, we stumbled upon some WinForms only issues when building with dotnet build (even on Windows). The build goes through but exceptions are thrown when executing.

As of .NET Core 3.0 preview5, you still have to build WinForms assemblies with msbuild.exe because .resx files are not handled correctly if you build with dotnet build.

For example the code below will execute without problem if built using VS2019 and fail with exception if built using dotnet build

(System.Windows.Forms.ImageListStreamer)resources.GetObject("imageList.ImageStream");

dotnet/msbuild#2221

WinForms will have more problems, for example licensed controls (licx) need to execute at build time to generate the license. Also natively wrapped controls are far more common in WinForms than in WPF. If they are licensed those will definitely not work on non-Windows builds. WinForms already has issues dotnet/winforms#947 and dotnet/winforms#971 for enabling Linux builds though, and I added corresponding remarks there.

If someone is interested I will create a PR

Patch (Could do PR)
systemathics@a9b28ed

Hi!
I tried to use your PR(fork) on my Ubuntu 18.04(x64) + net core 5.0.0-preview.1.20120.5, so I updated configuration file global.json to such state:
{
«tools»: {
«dotnet»: «5.0.100-alpha1-015536»,
«vs»: {
«version»: «16.1»
}
},
«sdk»: {
«version»: «5.0.100-alpha1-015536»
},
«msbuild-sdks»: {
«Microsoft.DotNet.Arcade.Sdk»: «5.0.0-beta.20171.1»,
«Microsoft.DotNet.Helix.Sdk»: «5.0.0-beta.20171.1»,
«FIX-85B6-MERGE-9C38-CONFLICT»: «1.0.0»,
«Microsoft.NET.Sdk.IL»: «5.0.0-alpha1.19513.3»
},
«native-tools»: {
«strawberry-perl»: «5.28.1.1-1»
}
}

Now after executing build.sh I got the error message (I report it here because don’t now whether is possibility to report about issue in fork):
maestro@mmeniac:~/..msv_links/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf$ sudo ./build.sh
/home/maestro/Documents/code/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf/eng/common/init-tools-native.sh: line 120: /home/maestro/Documents/code/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf/eng/common/native/install-strawberry-perl.sh: No such file or directory
Execution Failed
Is there a workaround to somehow build this fork?

I don’t think WPF has been/will be ported to MacOS

Does the bug reproduce also in WPF for .NET Framework 4.8 on MacOS?:

Does the bug reproduce also in WPF for .NET Framework 4.8 on MacOS?:

LOL

I don’t think WPF has been/will be ported to MacOS

Correct. WPF is Windows only.

Thanks for the confirmation that WPF projects won’t be supported on macOS.

I don’t think we should block anything on dotnet new. You could just as easily clone or type in the same project. As such, the right place to verify is in the build. That said, without committing to anything, building wpf from non-Windows (cross compilation) is separate from running an application. The former can be made to work without the latter. Again, I am not committing to anything here, but it might be possible to make dotnet build work and leave the failure to dotnet run, which would tell you that there is no WindowsDesktop runtime.

Guessing from the error message, it looks like the first thing hit here is a ‘/’ vs » mixup.

OK, that makes sense. Let’s see if more people hit this problem then and if it is something we should address sooner rather than later to provide more clarity …

Quick inspection, there are some hard-coded » in the build task source. There is also a mismatch of Microsoft.WinFX.targets in import vs Microsoft.WinFx.targets, which will cause this to fail even earlier on Linux. These are easy enough to fix, the question is whether something bigger lurks behind them.

@nguerrera I just encountered both issues that you mentioned, but I couldn’t find the Microsoft.NET.Sdk.WindowsDesktop.targets sources anywhere. Am I right to assume that they have not been open sourced yet?

OK, that makes sense. Let’s see if more people hit this problem then and if it is something we should address sooner rather than later to provide more clarity …

FWIW I just hit this issue as well. Running

.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview-010184
 Commit:    c57bde4593

I’ve also understood it that WPF is not and will not be supported on mac OS but after being encouraged by this post I gave it a try, which lead led to the issue at runtime.

In fact it seems possible to build WPF/WinForms projects from non Windows (Tested with bionic/amd64, we don’t use mac) with a quite simple patch (here on .NET Core 3.0 Preview5). There was two problems to address

1. Microsoft.WinFx.targets casing required to be harmonized (for case sensitive file systems)
2. PresentationBuildTasks assembly source code used hard coded const string » as directory separator in several locations

As a result, we seem to be able to build WPF/WinForms assemblies from Linux (cross compilation). I see the two markup compilation phases happening for WPF and diffing assemblies between plain Windows non patched build and Linux patched build gives the exact same outputs. Cross compiling is quite useful as we now can CI/CD using a lightweight Ubuntu-x64 docker image (instead of a quite big Windows VM). It should also probably work from other Unix flavours (Mac, etc …).

If someone is interested I will create a PR

Patch (Could do PR)
daviddenis-stx@a9b28ed

Docker images (Testing, not for PR)
daviddenis-stx@d122d93

@daviddenis-stx did you test this with custom Controls and MarkupExtensions? I don’t know the technical details of the markup compilation phase but I’d expect it to require loading the assembly and possibly even running some code? If so, then cross compiling could become pretty fragile as soon as 3rd party controls using Windows features are involved. When going this route it should be made sure that the error messages are appropriate when loading or execution of assemblies fails during markup compilation.

I tried to compile code using controls from Xceed extended WPF toolkit (restored as net 461). The build goes through and diffing the assemblies give something identical (the baml resources are not binary identical but decompiling them with ILSpy gives binary identical xaml text). Ideally we would need a great deal of unit testing. I’m curious of anybody willing to try to compile something of their own making to see how all that goes

At least this patch would correct self evident mistakes that prevent the build to even occur. I agree that it requires a lot of testing. We will do that on all our UIs and get back with more materials (proper runtime testing on Windows) but it’s probably not covering all the possibles. I guess it mostly boils down to underlying dependencies (are they net standard? do they use pinvoke? properly made nugets ?) if assembly loading happens it’s not clear why it would work on netcore windows and not linux?

Let’ s compile more WPF code with the proposed docker images, then diff assemblies, then execute. We should know rapidly if something bites.

if assembly loading happens it’s not clear why it would work on netcore windows and not linux?

C++/CLI doesn’t load on Linux/Mac, so if you’re using any type from such an assembly (possibly indirectly) it could trigger a failed assembly load, possibly cascading back to types failing to load in other assemblies.

I don’t expect it to be the common case, I just want to make sure this edge case is considered and has a reasonable diagnostic.

Makes sense. We had to just exclude C++/CLI assemblies from our codebase when migrating to netcore (I talk non UI assemblies). We may want to find a thirdparty with such a construction to test but it’s probable that those are going to dissappear eventually.

For the record, we stumbled upon some WinForms only issues when building with dotnet build (even on Windows). The build goes through but exceptions are thrown when executing.

As of .NET Core 3.0 preview5, you still have to build WinForms assemblies with msbuild.exe because .resx files are not handled correctly if you build with dotnet build.

For example the code below will execute without problem if built using VS2019 and fail with exception if built using dotnet build

(System.Windows.Forms.ImageListStreamer)resources.GetObject("imageList.ImageStream");

dotnet/msbuild#2221

WinForms will have more problems, for example licensed controls (licx) need to execute at build time to generate the license. Also natively wrapped controls are far more common in WinForms than in WPF. If they are licensed those will definitely not work on non-Windows builds. WinForms already has issues dotnet/winforms#947 and dotnet/winforms#971 for enabling Linux builds though, and I added corresponding remarks there.

If someone is interested I will create a PR

Patch (Could do PR)
systemathics@a9b28ed

Hi!
I tried to use your PR(fork) on my Ubuntu 18.04(x64) + net core 5.0.0-preview.1.20120.5, so I updated configuration file global.json to such state:
{
«tools»: {
«dotnet»: «5.0.100-alpha1-015536»,
«vs»: {
«version»: «16.1»
}
},
«sdk»: {
«version»: «5.0.100-alpha1-015536»
},
«msbuild-sdks»: {
«Microsoft.DotNet.Arcade.Sdk»: «5.0.0-beta.20171.1»,
«Microsoft.DotNet.Helix.Sdk»: «5.0.0-beta.20171.1»,
«FIX-85B6-MERGE-9C38-CONFLICT»: «1.0.0»,
«Microsoft.NET.Sdk.IL»: «5.0.0-alpha1.19513.3»
},
«native-tools»: {
«strawberry-perl»: «5.28.1.1-1»
}
}

Now after executing build.sh I got the error message (I report it here because don’t now whether is possibility to report about issue in fork):
maestro@mmeniac:~/..msv_links/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf$ sudo ./build.sh
/home/maestro/Documents/code/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf/eng/common/init-tools-native.sh: line 120: /home/maestro/Documents/code/C#/libs_and_so_on/Enable_WinForms_WPF_Unix/wpf/eng/common/native/install-strawberry-perl.sh: No such file or directory
Execution Failed
Is there a workaround to somehow build this fork?