...and our core development team is using C++ and MFC. It's an ECAD system which is in devolopment for over 20 years. Was once ported from HP workstations to windows (Electrical Design Software | E3.series | Zuken EN[^]) There is no way to rebuild all of this in WPF, MAUI or what ever.

At "my" company we create a lot of small applications. Many of them have data grids to display e.g. a bill of material, tree-views, little bit of drag and drop, etc. We wire this up way faster with Winforms than with WPF. The WinForms data binding isn't that bad. And there are almost never surprises that make you google for hours how to solve this weirdness. Maybe if we would use 3rd party controls like we do in WinForms (DevExpress), it would be easier. But plain WPF takes a ridiculous amount of time to make things work. We also have two teams which work on big WPF projects for years now. They created awesome UIs. But the effort they put in for this is tremendous. So, if your customer is willing to pay for WPF, go for it. If you need it yesterday, go with Winforms ;-)

Thanks all for sharing your opinion! I will try to stay away from this kind of decoupling!

And in this case a decoupled solution would make life easier :-)

We all know that we should program against interfaces not implementations, because when we decouple that we get a lot more manageable code. There is no question about that. I think almost all IoC-frameworks (Castle Windsor, Ninject, etc.) are able to scan assemblies for interface implementations and instantiate those classes at run-time. That means that we do not even need a reference to the assembly which is implementing the needed functionality. Cool, a lot of decoupling is going on... But that means, that we have to copy all the needed assemblies manually somehow. VS can't do this for us any longer. Same with the VS-Setup project. It isn't able to detect the necessary assemblies any more. Is that a goal? It feels to me like this makes life harder as it needs to be... What do you think?

Yes, Excel is another favorite! I remember that we had an issue with a French customer when we tried to select the appropriate Excel-sheet. The sheet names are also translated :(

Awesome! Thanks a lot!

Oops. I thought I'm at the lounge... Can I move this topic?

Should exceptions be visible to user? I don't think so. Does showing a "raw" exception help the user to fix the problem? In 90% of cases, no. Exceptions are for programmers. If you don't have basic knowledge of English, it will be hard to write good software (read specifications, tutorials etc. would be a big problem). So why the heck does MS think it's a good idea to translate exception-messages? Ever tried googling a German (Italian, French, Japanese... ) exception-message? On a non-English OS you get language specific exceptions and it's a nightmare to figure out what the English message of this exception "could" be. PLEASE MS: Stop translating exceptions!! Sorry for my English.... der Vorgang ist aufgrund des aktuellen Zustands des Objektes unültig.