In my "day job," I supply libraries to other programmers, so I run into this problem a lot in both C# and C++. Usually I design (or refactor) the project one of two ways:
1) Least commonly, I'll remove the circularity by combining code or moving code between two libraries. In the current case, for example, I might move the parts of the main project which are dependent on the Xml library into the Xml library. I would continue to move sub-dependencies until I found some logical breaking point that both separated the dependencies and minimized coupling. In very rare instances, two libraries might actually get combined into one. But like I said, that is what I least commonly do.
2) Most commonly, I'll factor out the dependency into a third library. For example, I might factor out the runtime version of the data along lines that left it separate from the both the main code and the Xml code. Then, the Xml could depend on this data library, and the main could depend on both the Xml and the data libraries. About half the time this process goes really smoothly, and about half the time it results in a re-thinking of the entire design. And when it happens, that re-think is almost always a better solution. This is the approach I take about 95 percent of the time.
The main thing, I think, is to do what makes sense. Separate the dependencies in a way that would be most understandable to some third person using the libraries for the first time. Most of the time, that will also result in good design with the least obnoxious coupling.
-Neil
