Architecture and references pain

im just taking over a project and this is really extremely difficult to understand and explain.

This project has dependencies to one another in some way. I am trying to seperate it out in different layers.
There is alot of serialization/deserialization going on as its calling a java webservice and the app starts up by reflecting all referenced assemblies and then by going through them and adding DBTypes to a cache of some kind.

when time comes to serialize/deserialize it gets the serializer from the cache if it exists. Great. They have a global static variable that keeps this..somewhere.

however, because I need to seperate out the out going calls into a service layer, there is no way to reference that cache.
I cannot even pass in the cache as it means for every call, I would need to do so (WCF service calls).
the DBTypes have custom xml attributes in terms of the namespaces/class types etc... as this is how they are passed back.


now, when time comes to deserialize a type - say DBBaseType, in the constructor it looks at the cache to get the type of itself, initialises some stuff and be done with it.
Problem is, when it tries to get its own type from a dictionary, it cannot because... the list is not populated.

the way the list is populated in the "original code" is done through the main app entry point on a background worker. But because I am now trying to route the service calls away from the UI to a service layer (WCF) - it will not have the collection populated thus throwing an exception.

difficult to explain and follow but just wondering what the best thing maybe here. ive been banging my head for 10 hours today.. one small progress then... 4 steps backwards!

Is there any hope of running this monstrosity through a debugger?

lol yes. i am trying but so many loops and hoops to jump through, you get confused yourself very easily!

I hear ya. Do you have a test environment or is this confined to production only?
If you have a test, I suppose logging the output of all these calls is one way of finding out what it is doing. I realize that debugging a multi-threaded application is a slighltly different ball game, but in the test environment, you should be able to perform logging so you can chalk out the execution path of the different programs in that project.

trying all that but so difficult :)
this is in test environment but the actual code is so lengthy and confusing. it just makes no sense and so many calls just to do something small at times. othertimes... no idea what its doing and why its doing it. :)