You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. Foo depends on Bar as some classes that stay in Foo depend on the code 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 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)
Is it possible to say that Bar 1.1 conflicts with Foo 1.0 (similar e.g. to Conflicts property in dpkg)?
Or force in some other way that if Bar 1.1 is installed then Foo is either not present or it's version is at least 1.1.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi
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. Foo depends on Bar as some classes that stay in Foo depend on the code 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 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)
Similar problem happens with cousin dependencies
Is it possible to say that Bar 1.1 conflicts with Foo 1.0 (similar e.g. to Conflicts property in dpkg)?
Or force in some other way that if Bar 1.1 is installed then Foo is either not present or it's version is at least 1.1.
Beta Was this translation helpful? Give feedback.
All reactions