I add my vote here. I wish I could see next to the message "Publish Succeeded" in the 'Web Publish Activity' panel also the date a time when it happened.
I understand that other requirement is to see date of last deployment if it happened through other technologies than Web Deploy or FTP deploy.
I understand that this requirement is only to keep the date together with the "Publish Succeeded" log history.
I agree and I also wish there was a prompt before publish.
My stressy scenario is if I just read publish profile file from my downloads and the publish starts straight on.
Often I am just organizing the publish profiles, deleting and configuring them without the need to publish right now.
Thank you for using Visual Studio and for your commitment to improving it. We are currently evaluating whether we will be able to address this suggestion in a future release. Thanks for capturing the pain points you feel when stepping through multithreaded applications while debugging. We will be providing an update soon.
Additionally, I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated. So if you hit a breakpoint, disable it, and then begin stepping you should not stop on a different thread. If you have other breakpoints in your application and another thread hits one, then you will be debugging in the mixed thread state as described in this item.
Program Manager, Visual Studio
I have a feeling that with the async await model the whole thing gets even more complex. I also have a feeling that statement:
" I wanted to clarify that the debugger will only ever complete a step on the thread from which the step was originated."
it not true in many cases. My bet is that the "current" thread is maybe running some continuation after some await in totally other awaitable context (possibly the same thread) but my brain is lost ;-)
I absolutely understand that this is no trivial development at all. And for modern ASP Net applications it is quite critical.
And I wanted to state that maybe we need more than current thread locked debugging. Maybe we need current "awaitable context" locked debugging.