Six different .NET solutions using reflection to interface with each other just made OOP look a lot like spaghetti code.

I'm curious, any idea why reflection was chosen rather than simply creating interfaces or even using the concrete types explicitly?

@xalez, I have no idea. The only area I see where it makes a little bit of sense is in the Reports module, where developers create custom reports using ActiveReports6, and all the namespaces and types are stored in the metadata portion of the database. Everywhere else, though, is just one solution calling into another solution. My educated guess is that somebody didn't want to make each solution build dependent on the others...?

@Theo20185 that sounds pretty evil, I am guessing that whoever wrote it wasn't aware of the ability to referenence assemblies at compile time or something, doing it VBA macro-style CreateObject instead ... I have seen some code in .net written by mainly vb6 devs and the results aren't pretty, albeit nothing as bad as that

wow that sounds really bad :-( I dont like reflections. Yes, there are situations where you can't avoid them but mostly it gets very chaotic and many devs dont know how "expensive" they are. It often makes more problems than it solves :S