Here in New Zealand 'rangehoods' (the extractor/vent fans) are very common. I wouldn't say *everybody* has them, but most people do. Those that don't often have a broken one they haven't bothered to repair. Those would all be exterior venting systems as far as I know, I've never heard of a filter/vent internally one. They aren't perfect, you can overwhelm them (and still need to open doors/windows), but they definitely vent a lot, and for gentle cooking often mean you can leave the house shut up if you need to. We had an electric hob in our previous house (also very common here, probably the most common type), but gas in our current place. Induction is becoming quite trendy, and common among new builds/wealthy people.

Not using .Net 7 yet, but using this in .Net 4.8, .Net Core 31, 5, and 6. Yeah, the warnings can be annoying, but the benefit can be significant too. Especially with junior devs who aren't used to null checking everywhere/don't have the experience to spot all the potential problems... but it's good for us oldies too, everybody misses stuff sometimes. The first warning in that list is the one that annoys me most. There are several potential work arounds depending on the specifics, but I often feel none are good :(

A couple of years ago, against my better judgement, and for no good technical reason, just that the customer insisted on blockchain, we implemented an ethereum based payment system for both an online and in-store retail system. We had some supposed experts from the Ukraine working on the ehtereum/blockchain side and they gave us a json rpc API to communciate with to make our lives easier since we weren't working in javascript and didn't know anything about ehtereum/blockchain really. When we eventually got the initial system working it took almost 15 minutes for a block to be confirmed, and a payment to therefore be considered complete (or at least recorded in a way that was good enough to avoid potential fraud/theft/accidental transaction loss etc). Imagine buying something in a store and having to wait 15 minutes for your payment to go through. Needless to say that didn't work. I'm not 100% sure what the blockchain team did to solve this, but I think they put some sort of persisted cache in front of the blockchain with some retries back into ethereum if the initial block didn't commit or something. So basically papering over the the cracks in an unnecessary system. I still can't stop myself shaking my head when I think about it.

All day every day. Well most of the day most days, there's a few 'web' back ends around now as well as some Windows Services etc. But most of our software is WinForms. Struggling with what tech to migrate to though - need something that targets desktop as first class, but also want it to be both cross platform and cross-form factor (desktop to mobile and back agai etc) as well as play more nicely with touch. I guess what UWP tried to be, but failed. Now we're considering... react and the web *shudder*. Sigh.

I spent a little time playing with it, decided it looked interesting/good enough to suggest to my boss we look into it. We went to Unoconf in Montreal together and drank the kool aid etc. Conceptually it is exactly what we want, and we wish Xamarin Forms had been more like this. Let me also say the work done/being done by the Uno team is amazing. However, after we got back from the conference we got some of my colleagues to work with it on actual commercial projects. We had one small Xamarin iOS app that needed an Android version, and another app that was UWP and also needed an Android version. Sadly I didn't get to work on these myself, they were mostly done by junior/intermediate devs and I, along with another senior colleague, helped guide them as much as I could in between our regular work. That means I'm not familiar with all the various problems we encountered - but there seemed to be a lot. We were successful in the end, the first app now has iOS, Android and UWP versions, the second app is UWP and Android (because that's all we need) and they work well enough from the user's point of view. Unfortunately it was a longer, harder road getting there than we hoped. Without going into too much detail, my personal opinion is that Uno currently feels like it's where Xamarin Forms was 4-5 years ago. There's a lot that isn't implemented (and you often can't tell at design time), each release is prone to breaking existing projects when you update the Nuget packages, and the tooling/code generation/build chain is fragile. That is not to say it's not usable or not valuable, and I'm certain the number & degree of problems you'll have will vary depending on the scope and complexity of your projects so YMMV. I also think we probably would have had a better time if we were building something from scratch rather than trying to port existing code. That said, one of the things we tried to port was a UWP app and the promise of 'write the UWP version and it just works on Android and iOS' definitely is there yet. At this point we are still betting on Uno for future cross platform dev in .Net, over Xamarin Forms etc, and are hoping that it will continue to improve and catch up to other more mature options. Certainly the Uno team seems to be working hard and moving fast. However talking to my colleagues they seem to have similar feelings to myself, they really want to like it but the experience they've had so far left them 'on the fence'. We also just struggled with another project we looked at due to a combination of stu

Have not seen this, but I don't do web/razor view stuff so maybe I'm avoiding it.

I (and the company I work for) was late to package management, and even now we avoid it where possible, but some Nuget packages have crept in out of necessity. When I first started with it about 2-3 years ago, it worked flawlessly every time for me (though admittedly our usage was light). Unfortunately it seems to have been broken and then gotten worse with every iteration released since then. I really don't know why. I had a problem the other day where a project showed a broken reference, but Nuget insisted the package was installed ok. Checking the csproj file showed it was referencing version 9.x.x.x of a package, but the packages folder contained only 8.x.x.x. No amount of cajoling would convince Nuget that it needed to download the new version even though VS knew the reference was broken. Only thing that worked was forcing a reinstall of the package. Having said that not all problems are caused by Nuget itself. Strong named packages are evil - we have some solutions that have a mix of .Net 4 and .Net 4.5 projects in them that all reference the same package (don't ask). All the assemblies ship and run together and it all works fine until you get strong named package and you can't reference the newer version from the .Net 4 projects. Then you're in a world of pain trying to manage the dependencies. On top of that, at least one of the Microsoft provided Azure packages decided it would be a good idea to rename an entire namespace (or move types to another namespace at the very least), so upgrading from version X to version Y is breaking at the source level with no explanation or release note to say so. When it works I prefer it to downloading and running installers, then having to manually locate the right assemblies (are they in the gac? in a folder? which folder? somewhere under program files or program files x86? what was the company name again?) etc. Especially nice when you don't have to do this on build servers. Sadly the experience is so broken we do everything we can to avoid it now. Really the only thing I want from Nuget is for the package restore to work properly, i.e I add a package to a project and check in, my colleague gets latest and builds, and the package is downloaded and referenced correctly on their PC. We've had zero success with this in the last year or so. It's always broken and people are always checking in csproj changes just to fix references/broken reference paths. I really don't get why since it used to work. Haven't tried Paket - sort of appealing, but I'm led to bel

I *tend* to use everything exception Windows Explorer full screen, often because I have multiple copies of that open to different folders and drag files between. I also don't use console/powershell windows full screen. Oh, and calculator, because why would you. Everything else, VS, Outlook, browsers, games, office apps etc. I use full screen with one on each of 2 or 3 monitors, and task switch between instances/apps via the keyboard. That's probably just me though. I'm usually in the minority.

We have two LoB UWP applications being shipped to customers. Mostly they are being used on Windows Phones, or on devices like the (Honeywell) Dolphin CT50. WPF & WinForms don't really work on those devices due to the OS. Prior to that we were using the Motorola 3090/3190 devices which ran WinCE, so they required use to use .NET CF and the tooling for that was abandoned around 2008-2010. So basically, yeah, there is a point to UWP *for us*. Also, UWP has some nice API's that could benefit regular desktop apps (settings that sync across devices, credential vault etc), and some improvements to XAML (triggers/relative panel etc) to make stuff easier when you want to alter the UI based on screen size/input mode (important if you want to write one app to run on tablet or desktop PC - and Surface while small is still a viable tablet market - it's not dead the way WP is). Yes, you can use at least some of those API's from a regular desktop app if you edit the project file and add the right references, but at that point, why not just go with UWP? Unless you really need to support Win7 which is officially EOL (except for the WePOS version), or possibly Win8.1 (which is a tiny market share) you might as well go UWP. The user's largely can't tell the difference except it came from the store. Not saying it's perfect, or always the right choice, but I don't think it's always the wrong one or has zero benefts either.

Haha. If you think the store hoops to jump through for UWP are painful, don't ever try pushing an iOS app. Apple is the worst :(

Always nice to be appreciated :)

I believe you're correct in that you can't do this on the event itself, but you could make something nearly as good (depending on your definition of 'nearly as good').

await source.WaitForEvent(nameof(source.Event));

Would be possible. Using nameof in VS2015 means you have any issues with refactoring, though it is a bit uglier than your preferred syntax. Something like the following would implement the method (and returns the EventArgs if you need them). An alternate overload would be needed for non-generic event handler based evevents, but that's not hard.

public static class EventExtensions
{
public static Task WaitForEvent(this object eventSource, string eventName) where T : EventArgs
{
var tcs = new System.Threading.Tasks.TaskCompletionSource();
var eventInfo = eventSource.GetType().GetEvent(eventName);

		EventHandler eventHandler = null;
		eventHandler = new EventHandler(
			(source, e) =>
			{
				eventInfo.RemoveEventHandler(eventSource, eventHandler);
				tcs.TrySetResult(e);
			}
		);
		eventInfo.AddEventHandler(eventSource, eventHandler);

		return tcs.Task;
	}
}

The company I work for is doing UWP for some of our warehousing and retail based mobile devices. Currently shipping two 'apps' (from the store's/binary perspective, they have multiple funtions each). So you're not alone in doing UWP dev, just in a very small minority (I think) :) I agree the lack of UWP specific resources is annoying, but much of the older WinRT stuff still applies. Still annoying when you're trying to find the right way to do something *now* and you find WPF/Silverlight/Windows Phone/WinRT stuff that doesn't apply or is old. Since I mostly skipped WPF and my previous (limited) XAML experience has been WPSL/WinRT, I don't find too many differences in the UWP except for the changes in controls etc. The UWP API itself is obviously different to what we've had before, but that's sort of to be expected. The stuff that really grinds my gears is things like the crappy error handling. Years of being taught not to throw or catch System.Exception and now the framework throws it all the time so you have to catch it, then try and figure out what the HResult from the dark ages means. There's a few helper functions for that (one specifically in the Windows.Web namespace somewhere), but they're all disparate functions and you end up with quite a lot of logic and much Googling to produce good error handling. Thank goodness they gave us exception filters in C#. I blame jscript for all of this. I once heard (at Build?) supporting jscript and having language projections is the reason we don't have inheritance in 'Runtime Components'. I suspect it's also the reason for using COM and the poor error handling. So once again, jscript is the reason we can't have nice things.

I had a lot of stability problems pre "update 1", and with 3rd party addins loaded. Removing the addins and applying update 1 fixed almost all my issues. The only real paint point I have is that it's much slower for alot of things (refactoring/smart tags etc) than VS2013 was. When I say much, it probably isn't a lot in terms of actual time - but it's everytime you use those features, so it seems painful. Other than that, I quite like it now.

I had huge problems with crashes and hangs pre-update 1, but a combination of update 1 and unloading various 3rd party VS add-ins solved almost all of them. I won't touch VS2015 without update 1 now - odd that you are having the opposite problem!

Some VS debugging sessions require admin rights, at least under some configurations. I think debugging code running in full IIS might require it, though I'm not sure of the exact details. Also attaching to services or other processes as an administrator usually needs admin rights. Writing to program files, windows/system folders, editing the registry all need rights. I think they might also be required to start/stop/restart some services, and I believe even viewing some Windows event logs requires admin rights, though might depend on the specific logs. I think a lot of it depends on policies and what rights are assigned to other apps/folders/executables.

Sad. I've been using VS2015 even in pre-release and it's been very stable for me, but then I'm not working on web projects (no HTML/knockout etc. for me)... so that may be why you've got a different experience. I will say it feels a bit slower. Not for typing, but a lot of the right click/refactoring style stuff seems to take a little bit longer to display new menus/apply the changes etc.

Probably it used to work that way by oversight back in v1 or something. They figured out it was dumb but were afraid of upsetting users by changing existing functionality (something they've gotten over :( ), hence the option being added to turn it off. Of course the default is on so no one used to the old behaviour complains. Can't really see why it's useful myself, but backwards compatibility and options for all the things used to be MS' forte.

F1, but it's always by accident :((

I don't know so many people are against it. I quite like Win 8/8.1 and some of the changes coming in Win 10 annoy me because they're going 'backwards'. I like the new start screen (always hated the old start menu) - though the visible button in the corner to access it in 8.1 is sensible for new users. I love Metro IE too.I use Win 8/8.1 mostly on a non-touch laptop for work and non-touch desktop for home, occasionally on a Surface Pro 1. I have no issues. Likewise I had very few problems with Vista which everyone hated, and basically see Win 7 as Vista with lipstick but no one else really admits that. Not every change is going to suit every person, or every workflow so I can understand some people being upset but it seems like a lot of other people are just anti-change or jumping on the bandwagon. One small problem with 8/8.1 is I find the 'close' gesture for metro apps is very difficult for most people using touch (and they don't know how with the mouse). They either don't drag far enough or the system doesn't register the interaction the right way (usually does with the mouse to be fair). The new title bars kind of fix that, but I personally dislike them. Also, sadly, the 'store' is filled with crap. I would love to use more Metro apps, but there are so few that are actually any good I don't bother with most.