Circular references/dependencies and WCF Services

This is a beast.

The solution I am working on is very tightly coupled. The WPF app uses a "Framework" (its own framework) project which includes its DAL (which is calling an external webservices, non .NET).
So I am trying to seperate it out where we have a middle tier/business logic/Service layer and this one will call the DAL instead which then returns the data back to the WPF.
Thats fine except the tightly coupled references in the classes which are being serialized/deserialized to and from.

I seperated out some of the basic entities into its own assembly/project known as "contracts". Thats a step in the right direction.
Except when handing off the data back to the caller (WPF) as one of the classes is a "Parameters" class which holds a Name (string) and a value (System.Object!!!)

This causes a problem as the known types are within the Framework project. The Framework Project needs to reference the Contracts project as it will be using some of its contracts that I moved out from the Framework project.

I cannot add the type it is complaining about in the knowntype attribute in the Parameters class because the type it cannot deserialize is in the Framework project (circular reference)

I cannot move the type in question into the Contracts project because of the fact that the base class has a tight coupling to a few classes in the Framework project, which is needing it.
Confused? This is nothing compared to what im seeing!

how can I return back to the caller from the WCF Service, the "Value" property of the Parameters class, which is of type System.Object, when this project cannot have a reference to the Framework project which contains the class/object in question as the "knowntype"

You could define a DTO (Data Transfer Object) in Contracts that is just a dumb data holder for all data you need to serialise over the wire - one DTO for each Entity you need to send. The Frameworks project can use that type to populate the Entity/create instances from the Entities.

You can simplify the wiring with something like AutoMapper, or just write the wiring code by hand, which is tedious but straight forward.

yeh. The problem with that though, is that the java webservice is being used to send and receive data from, which gets mapped to the objects in question which is causing this headache, and that object is then relayed back to the caller (the UI in this case) which then does stuff with it like binding it on the screen, having notification property changes etc....

DTO I wish could help here but... they cannot because when data comes in, it needs to be deserialized and then handed back :-/