New Post: Provide MSBuild resolution instead of direct file references for transitive dependencies

@BenPhegan:

Somehow I believe that it would still be worth it to restrict the assembly search path to only the folders containing the correct versions, because:

• Using the fully qualified assembly name means that the information from the packages.config file is duplicated, which is a bit unfortunate.
• While in simple cases, the correct version is chosen, I'm afraid of non-deterministic results in more complex cases. Note that binding redirects aren't always necessary for a different version of a dll to be picked up (I think they might be only required for strongly named assemblies, I'm not exactly sure though).
  

example :

• A depends on C >= 1.0.0, B depends on C >= 1.0.0,
• the project references A and B directly, and packages.config contains C 1.0.2.
• A was built with C 1.0.0,
• B was built with C 1.0.1.
• for some reason, the repository contains C 1.0.0, 1.0.1 and 1.0.2
  

The chosen the version will be indeterministic (it will depend on the order of link resolution), and it will be either 1.0.0 or 1.0.1, while the expected result would be 1.0.2.

If we could restrict the search path to only the 1.0.2 folder, we would get the expected result in a deterministic way, and if for some reason, C 1.0.2 was missing (maybe because the repository has been corrupted or any unexpected reason), the link would fail explicitily (instead of silently fallbacking to another available version, which I'd rather avoid - again for avoiding indeterministic results down the road).

I guess if I'm so convinced of those issues I should come up with a nice test case / POC as you did :)
But I've yet to find out how hard would it be to use the information from the packages.config in a msbuild script...