Suggestion: Don't update AssemblyVersion for minor updates.

Feb 24, 2013 at 5:01 AM
In a project where multiple libraries depend on Rx, every package needs to be recompiled against a new release of Rx even if there are no breaking changes to the public API's.

This causes trouble if you don't have control about some of the libraries depending on Rx.

Please consider an approach as used by Json.NET and other libraries as explained here (http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers.aspx), which has also been in use by the Rx team, as far as I know, before version 2.1.

This means that the AssemblyVersion attribute is only updated for major and minor releases (assuming they contain breaking API changes) but not for the others. The AssemblyFileVersion will be updated normally to differentiate between versions.

For example, in the small release from 2.1.30204 to 2.1.30214, the files would have the same AssemblyVersion of 2.1.30204 and therefore the same strong names causing no issues with libraries depending on 2.1.30204.

If this practice will be used, this also removes the need for Assembly Binding Redirects in projects. Binding Redirects are not not supported for Windows Phone and Silverlight anyway.