Uncle Bob Style OOP In .NET?

I've been professionally writing VB.NET software for seven years. However, I don't have a strong computer science background - four courses while studying education at university in the 90s that gave me some CS basics and exposure to Pascal, C and Lisp. Anyway, there are a whole bunch of practices that I'm missing - testing, patterns, "real" object-oriented design, etc and I'm trying to pick them up. If you look at most of my applications, you find blocks of fairly old-school procedural code being triggered by form events. Where I write my own classes, I'm mostly using them as data-structures with overloaded New() methods and maybe a custom output method. I consider myself quite proficient at this kind of work and none of my employers has had any problems with it. But it's not really right and I'd like to learn more of the craft of my trade.

Since the early 90s, I've looked at several different intro to objects kind of documents -- books, tutorials, etc. They seem to all use dogs and cars as analogies and examples with tons of responsibilities per object. And they've never stuck with me even as I wanted to learn from them.Lately, I've been reading "Uncle" Bob Martin's notions of OOD and I like what I see. But it's hard for me to follow the C/Java syntax and I get hung up on that difficulty rather than just ingesting it smoothly. So I'm looking for good sources with VB examples because that is (by far!) the syntax with which I am most comfortable. There's not much around. The stuff that I find doesn't seem to advocate or exemplify e.g. the Single Responsibility Principle.

I've been looking for books, but they mostly seem like they're either OOP and not in VB or VB and not (really) OOP. I've checked out the following topics here: 1, 2 and 3 -- among others. I've scrutinized the Amazon reviews of most of the books listed in those threads and keep coming up with reasons to suspect that they aren't really what I'm looking for.

So, any ideas? If you're going to suggest a book, I'd like to hear how well it fits the needs that I've outlined. If you think I'm on the wrong track, I guess I'd be interested to hear why. If you have other suggestions on how to pursue this avenue of improvement, that too would be great.