I feel like @tux0r should have a say here :D Be kind ;-)

Hi Tux0r, thanks for you're answer. I'm interested in the reasons or criteria oficina the recommendation. Could you please elaborate?

I am assuming it is a line of business app. I would probably have a server-side API for the business logic and integrations (like SQL), if possible. This helps to logically separate UI concerns from business and integration concerns. When it is all within the app, it becomes easier to mix concerns. Having your own API also establishes a path for providing data to other apps. Otherwise, it creates a huge dev limitation when you let other systems directly connect to your SQL database. Because then it is difficult to make database changes without breaking others. It is better to expose an API for them. Then you provide exactly what they need through the API and can still make database changes internally without breaking them.

It seems pretty natural given the other Microsoft-based constraints to choose the .NET platform. Visual Studio is a great IDE for this platform. Language and framework is probably where I will differ from common recommendations. Assuming it must be a desktop app, I would probably use F# and WPF + Elmish for the UI. This mostly constrains WPF to just be for display elements, and using Elmish (MVU pattern) to handle UI behavior. I do not care for WPF's behavioral abstractions like MVVM (nor just about any UI framework's), so I had rather use MVU here.

WPF because of backward compatibility. UWP is the latest tech, but it only works in Windows 10. If the app is only used inside of a specific business, and you have guarantees that all PCs run Windows 10 there, then UWP might be more viable. If you want to go for compatibility for even ancient/unsupported windows versions, then you might want to look at WinForms. Altho WPF can run on Windows versions all the way down to Windows XP.

.NET Core 3 is supposed to add support for Desktop apps in 2019. But today, you would likely have to target .NET Framework for the app project itself. You could still target .NET Standard for libraries, and those would work on .NET Core apps in the future.

C# making either a WinForms or UniversalWindowsPlatform application.

VB6...

Nah, just kidding...

I'd suggest Visual Studio and C# but where to go from there really depends on the app(s) to be developed and the time frames involved.

Winforms applications can be created quickly, have near automatic backward compatibility with Windows XP to Windows 8 (if that's needed) and are quite easy to understand when written right. The problem is that it is easy to write a bad application with it and end up with a huge mess.

WPF is a little more tricky since it mostly requires writing applications using the MVVM pattern. So, if you aren't familiar with that it is a bit of a learning curve. On the flipside, if you're comfortable with separating UI from backend, this may be a good fit for you. Backwards compatibility is occasionally an issue, depending on what the app is doing. Going forward, it is likely that WPF will work better in .Net Core 3.0.

On the backend, I'd recommend developing a Web API to serve the data rather than tightly coupling the database to the application. This isn't always possible but it has become a lot more practical now. In my work in manufacturing applications, we are in the process of moving all data access to Web API, leaving only the UI and connectivity to hardware devices (barcode readers, scales, etc) to the front end.

Pretty much everything Phil said :).