Microsoft-ui-xaml: Proposal: UWP Hot restart

Created on 3 Oct 2019  路  8Comments  路  Source: microsoft/microsoft-ui-xaml

Proposal: UWP Hot Restart

Xamarin Hot Restart was announced in .NET Conf 2019.

Hot Restart enables for quick redeployment of any changes in the app.
This feature has existed in other technologies such as Flutter from day one.

My request is that the UWP team provide us with this great feature that makes development and debugging so much easier.

area-Tooling feature proposal team-Markup

Most helpful comment

This would be great, the build/deploy/iterate cycle is too long for simple UI changes.

@knightmeister we have XAML hot reload today, have you tried it out?
https://docs.microsoft.com/en-us/visualstudio/debugger/xaml-hot-reload?view=vs-2019

The Xamarin Hot ~Reload~ Restart feature allows for quick changes to non-UI edits, which I think is what @weitzhandler opened this issue for

All 8 comments

This would be great, the build/deploy/iterate cycle is too long for simple UI changes.

This would be great, the build/deploy/iterate cycle is too long for simple UI changes.

@knightmeister we have XAML hot reload today, have you tried it out?
https://docs.microsoft.com/en-us/visualstudio/debugger/xaml-hot-reload?view=vs-2019

The Xamarin Hot ~Reload~ Restart feature allows for quick changes to non-UI edits, which I think is what @weitzhandler opened this issue for

Yes, I use XAML hot reload all the time - talking about speeding up the iterative development the build and deploy cycle is so slow.

@knightmeister ahh cool, I'm glad to hear that you do :)

I totally agree, improving the build pipeline is on our radar of things to invest in. I can't say much for the deploy side of things, that is largely outside of our control. Are you referring to deploying to a remote machine or even just deploying locally?

/cc @fabiant3 @pag3

I totally agree, improving the build pipeline is on our radar of things to invest in. I can't say much for the deploy side of things, that is largely outside of our control. Are you referring to deploying to a remote machine or even just deploying locally?

Hi @stevenbrix, overall the UWP dev story is pretty good - certainly better than Xamarin for example, in my opinion. Without hijacking this I issue, the one thing I'd love to see is the ability to better diagnose UWP error handling (without getting COM errors, or when an app crashes get an error message of some sort rather than just have it disappear).

Regarding my build and compilation times, I'm developing and deploying locally using 1903 on a fairly competent system (i7 6700, 970 Pro m.2, 32gb ram). I find that for non-trivial solutions, the iterative cycle is quite slow (faster than Xamarin, but slower than WinForms, Console, ASP.NET and WPF). I think the deploy side is what kills the speed.

I'd love to see is the ability to better diagnose UWP error handling (without getting COM errors, or when an app crashes get an error message of some sort rather than just have it disappear).

@weitzhandler would you be able to provide a minimal repro app we could use so that we have a better idea of exactly what your issue is? Even just a few screenshots of the error messages would help us understand what is going on. As for app's crashing, are you referring to when a debugger is attached or no?

would you be able to provide a minimal repro app we could use so that we have a better idea of exactly what your issue is? Even just a few screenshots of the error messages would help us understand what is going on.

I'm congnisant that this doesn't apply to the original issue and don't want to hijack too much.

On the assumption you wanted to @ me, I'm not sure what you want me to give you a repro on. To give you an example of obtuse errors, I'm talking purely as a C# developer, consuming the UWP API (including WinUI) from .NET. Last night I was troubleshooting a cross thread update to a view model which rightly crashed. The error is surfaced in App.xaml.cs and comes through as a COM error. The call stack was incomplete (but gave me enough to figure out where the update was happening, breakpoint there then step backwards through the correct stack).

The core of the issue is that for new developers, and people learning the framework, figuring the exceptions out and why they happened is too difficult. Quite often the description makes no sense.

More frustrating than that for me though is the time it takes to build/deploy/debug, or the iterative cycle. This is trivial for a small app but as soon as you start having multiple projects and a larger UWP project, this slows down the cycle. I'm comparing to running WPF and Winforms solutions in the same project - Xamarin iterative cycle is also quite slow.

As for app's crashing, are you referring to when a debugger is attached or no?

I'm talking about with no debugger attached, how they just disappear. I suspect this behaviour has been copied from iOS. Windows in the past has always given an indication that the crash occurred. There is a record in the event log, but nothing which makes sense to me as a .NET developer. A stack trace would be beneficial, and even just a "Sorry, this app crashed" message box would make the experience as a user less jarring.

@weitzhandler yes I'm sorry! :)

@knightmeister, can you open a new issue and include the repro in there? If you can provide a repro or screenshot it will help us make sure we know exactly what issue you are facing and not leave us guessing. I appreciate you not wanting to hijack this issue.

I can't speak to the app crashing/disappearing, I believe there is supposed to be some mechanism for you to get diagnostics when your app crashes out in the wild? I'll admit I don't know much here though. Either way, you could open a different issue about this and we could try to find the right team to look at it.

Was this page helpful?
0 / 5 - 0 ratings