The good news is I’ve had some client changes and I’m doing even more interesting and rewarding work than I was the past year or so, which is saying a heck of a lot.
The bad news is it’s all in VB.NET.
This isn’t really all that bad except for the configuration side of things. After all, once up on a time, I toiled for years in the salt mine that is VBScript.
But I still run afoul of Visual Studio’s VB.NET configuration defaults. It wants to turn things off by default so I can’t find them, hide “advanced” features behind innocuous buttons, and make really presumptuous defaults in order to save me from the horrors of having to declare things in code.
Case in point: today I created an empty class library project with VB.NET as the language. I wanted this to be in a namespace, call it MyCustomer, so — as I would have in C# — I wrapped the class definition accordingly:
Namespace MyCustomer
Public Class MyClass
End Class
End Namespace
I got that solution set up with a project reference and a couple of public members and got a clean compile.
Then I went to another solution and added the new class library project to it, added a project reference to my new class library, and so on. And proceeded to spend the next 30 minutes pulling my hair out trying to figure out why “Imports MyCustomer.MyClass” was not finding the namespace or at least not any public members within it.
Then I calmed myself down and stopped to think about what I had done in all this that is not an everyday thing that might have tripped me up last month or so. The older I get, the fuzzier memories prior to the past few days seem to get. Then it hit me: VS wants to assign a “default namespace” to a VB.NET project. That default namespace in my new project happened to be named MyClass. So to get to my class I actually had to “Imports MyClass.MyNamespace”, which was of course insane. So I changed the default namespace (in the project properties, Compile tab) to the empty string and all was sweetness and light again.
This “helpful” default effectively destroys some of the one-to-one correspondence between VB.NET and C# code. It’s writing code via configuration, effectively. I can understand why it was done — to get novice VB.NET people who come from the VB6 world up and running quickly, writing code without the annoyance of declaring namespaces. But for a person who has lived in the C# world since 2002 this is just idiotic. A C# project template would have the namespace laid in already for you, what’s wrong with that? Then you can see that it’s there, and change it or take it out of you want. No phantom code in sight.
So now I could spend another 20 minutes hunting around for configuration settings that would make VB.NET project behavior more C#-like. But I’ve already lost 30 minutes of my life I’ll never get back, and besides, I’m trying to use defaults that most VB.NET people would so that I can talk intelligently about working in the VB.NET world.
Thus endeth the rant.
