Consider the following example project organization for your scenario:
Project A: Bootstrapper, in charge of running the application, configuring DI and setting up the UI (this could also go in a dedicated Bootstrapper project decoupled from the app and UI). Knows B, C, D, E, F
Project B: the UI (or as many projects as required to make it modular). Knows C
Project C: business logic (gets data from a third party service and does deserialization and some thread management work
). Knows D
Project D: interfaces, containing IB and IC (they could also have separate dedicated projects).
Project E: The API to get data from third party service
Knows D
Project F: The Thread Manager API
Knows D
Notice the decoupling from the UI and the implementation through the business logic layer. This way, you can switch the implementation details without having to change either the business logic or the UI. Also, if your business logic varies, the impact is minimized.
Regarding DI, the bootstrapper project is the only one that has the whole picture, the rest should just use interfaces that the container set up by the bootstrapper will resolve (i.e. inject) for them.