Over time I could understand two parts of SOLID – the “S” and “O”.

“O” – I learned Open Closed Principle with the help of Inheritance and Strategy Pattern.

“S” – I learned Single Responsibility principle while learning ORM (the persistence logic is taken away from domain objects).

In a similar way, what are the best regions/tasks to learn other parts of SOLID (the “L”, “I” and “D”)?

References


msdn - Dangers of Violating SOLID Principles in C#
channel9 - Applying S.O.L.I.D. Principles in .NET/C#
OOPS Principles (SOLID Principles)


I was in your shoes couple months ago till I found a very helpful article. 

Each principle is nicely explained with real-world situations that each software developer may face in their projects. I am cutting short here and pointing to the reference - S.O.L.I.D. Software Development, One Step at a Time.

As pointed in comments, there is another very good pdf reading - Pablo's SOLID Software 
Development.

In addition, there are some good books that describe SOLID principles in more details - Good Book on SOLID Software Development.

Edit and comments of a short summary for each principle: 


“S” – Single Responsibility Principle is driven by the needs of the business to allow change. “A single reason to change” helps you understand which logically separate concepts should be grouped together by considering the business concept and context, instead of the technical concept alone. 
In another words, i learned that each class should have a single responsibility.
The responsibility is to just accomplish the assigned task
“O” – I learned Open Closed Principle and started to "prefer composition over inheritance" and as such, preferring classes that have no virtual methods and are possibly sealed, but depend on abstractions for their extension.
“L” – I learned Liskov Substitution Principle with help of Repository pattern for  managing data access.
“I” – I learned about Interface Segregation Principle by learning that clients shouldn't be forced to implement interfaces they don't use (like in Membership Provider in ASP.NET 2.0). So interface should not have “a lot of responsibilities” 
“D” – I learned about Dependency Inversion Principle and started to code that is easy to change. Easier to change means a lower total cost of ownership and higher maintainability.


As a useful resource from CodePlex was mentioned in comments, reference is included to SOLID by example


