Reputation: 74280
I have lots of components, and many times one component depends on another. In .Net, if you make change to any assembly, you should change its assembly version to reflect this change. However, this provokes a ripple effect down the dependency chain.
One way of dealing with this is by using binding redirection, mostly if you know that no breaking changes were introduced.
My question is - how frowned upon is the use of binding redirection? Should I always make sure to have none of it when a product is released to production?
EDIT - applications are various services based on a common framework. We are the sole developers and supporters of these services. There is no hotfixing, just pushing new MSI's when necessary.
Upvotes: 0
Views: 142
Reputation: 6378
If you put more flexible version check on your components, they wouldn't break on minor version change. (http://semver.org/)
The examples are
<!-- Accepts any version 6.1 and above -->
<dependency id="ExamplePackage" version="6.1" />
<!-- Accepts any version above, but not include 4.1.3. This might be
used to guarantee a dependency with a specific bug fix. -->
<dependency id="ExamplePackage" version="(4.1.3,)" />
<!-- Accepts any version up below 5.x, which might be used to prevent
pulling in a later version of a dependency that changed its interface.
However, this form is not recommended because it can be difficult to
determine the lowest version. -->
<dependency id="ExamplePackage" version="(,5.0)" />
<!-- Accepts any 1.x or 2.x version, but no 0.x or 3.x and higher versions -->
<dependency id="ExamplePackage" version="[1,3)" />
<!-- Accepts 1.3.2 up to 1.4.x, but not 1.5 and higher. -
<dependency id="ExamplePackage" version="[1.3.2,1.5)" />
from https://learn.microsoft.com/en-us/nuget/create-packages/dependency-versions
So, if your package can accepts any version x.x and above, a minor version change wouldn't affect your solution.
Upvotes: 1