I have a nuget package, let's call it Foo in version 1.0. Foo depends on some external library e.g. log4net.
Now I want to prepare a new version 1.1 and extract a few classes from Foo into a second nuget package that does not depend on the external library. Let's call it Bar. New Foo depends on Bar as some classes that stay in Foo use the code which is being moved. I'm also using TypeForwardedToAttribute not to break existing projects that already reference Foo.
This works fine until someone creates a nuget package AAA that references only Bar. Then an attempt to install AAA in a project that references older version of Foo ends with a cryptic compilation error that types moved to Bar exist in both Foo version 1.0 and Bar 1.1 (see diagram below)
Project --> Foo 1.0
--> AAA --> Bar 1.1 <-- Foo 1.1
Similar problem happens with cousin dependencies
Project --> AAA --> Foo 1.0
--> BBB --> Bar 1.1 <-- Foo 1.1
Is it possible to say that Bar 1.1 conflicts with Foo 1.0 (similar e.g. to Conflicts property in dpkg)? Or prevent in some other way simultaneous installation of Bar 1.1 and the old version of Foo.
This could probably be solved by shipping a custom MSBuild task in Bar to verify whether Foo is installed and return an error if it's in old version. But I'm wondering if there is any direct approach to this problem.