When I was consulting we would usually run into VB.NET in businesses that were either small or didn't have career developers. One exception to that is a lot of

When I was consulting we would usually run into VB.NET in businesses that were either small or didn't have career developers. One exception to that is a lot of financial services firms (even banks) seemed to use it a lot. The types of problems I saw VB.net used to solve were usually data entry apps, call centers etc. A lot of the times these developers are what I called "tools based", because almost without exception the only way they knew how to get a database connect or a form component on the screen was to use Visual Studio to drag and drop it. I did run into a few VB.NET projects that were super professionally done and impressive but that was the exception. I don't fault the language overall, but I would never want to maintain it long term. Funny part, one of the consultancies I started and ran for years focused on project rescues and our bread and butter was the Microsoft stack for a time. By percentage we were called for VB.NET projects in financial services firms above almost all other situations. To be fair, VB.NET wasn't the failure generally, poor project management, bad requirements and staffing almost always was the failure. Architecture and language choices were usually made by non-developers or at least non-career developers.