Jens

> I also get this message if using "-blame-crash-collect-always". Its frustrating, because I try why the dump is not working on the server and I can't get it working locally...

Please continue the work on this project as main project for Maui. It’s currently unbelievable how hard it is, to write controls which look and feel the same on all...

@jsuarezruiz thanks for giving us an update, even if there is not much new information. It's always helpful, to see that there is still (at least some) "life" in it....

second that, stumbled upon that, when i tried something fancy: ``` "pwsh .\build_script.ps1 --target=Build "--AdditionalMsBuildArgs=-p:Foobar=True" # actual: is parsed into three items # $args: ["--target=Build","--AdditionalMsBuildArgs=-p", "Foobar=True"] # expected: only 2...

haha, after MSFT itself had zero activity to invest or fix the bug for TWO YEARS. They close it within ONE WEEK (of the author not responding), again without testing...

second that problem, with update to vs 17.4.4 our build broke, with the described problem, despite we do not use tizen, nor do we have added it as TargetFramework

@mstefarov thanks for commenting, always good to know that i'm not the only advanced MAUI user. And others have the same issues like me 😀

> Verified this issue with Visual Studio Enterprise 17.7.0 Preview 2.0. Can repro on with .NET MAUI Template project using default VS symbol. > > Note: If add "http://symweb/" symbol,...

@BretJohnson thanks a lot for the deep analysis. I will try the workaround next week, looks promising. (My current workaround was to unpack all nugets into a specific location, and...

it's a little bit ridiculous, that one needs to do parameter gymnastics with `--logger:"console;verbosity=detailed"` (which is one of the awkwardest parameter syntax i've seen) for a what the majority of...