We all know there are three types of binding policies: App config, publisher policy, and admin config. I’ll ignore admin config for this discussion.

App config affects one application on multiple assemblies.
Publisher policy affects one assembly for all the applications.

Because publisher policy affects all the applications, you want to be very careful about what it applies to. For example, you don’t really want to redirect an assembly to a newer version with breaking changes, since doing so will likely break applications.

In .Net framework an assembly version consists of four parts: Major, minor, build, and revision. The guideline says assemblies should be compatible within the same major/minor version. And it is expected to have breaking changes cross major/minor version.

This guideline leads to the following recommendation:

You should only use publisher policy to redirect assembly within the same major/minor version.

In fact, this is how fusion probe for publisher policy assemblies. Given an assembly foo, version=major.minor.build.revision, fusion will only look for assemblies with name policy.major.minor.foo.

The problem is, fusion does not enforce what kind of redirection can be put in the publisher policy. You can put a redirection from version 1.0.0.0 to version 2.0.0.0, and fusion will happy accept it and apply it.

Doing so obviously violates the recommendation above. But there is nothing stopping you from doing that.

Personally, I consider this as a bug. We should only allow publisher policy to redirect within the same major/minor version.

But we have shipped it this way. We can’t take it back. We will just have to live with it forever.

People have taken advantage of this to re-use publisher policy for the purpose of always-load-the-latest-version. Of course they have to ship publisher policy for every major/minor version combination they ever have shipped. For example, if they have shipped v1.0.0.0, v2.0.0.0, and v3.0.0.0, and they want everyone to use v3.0.0.0, they will have to ship publisher policies for v1.0 and v2.0 to redirect both v1.0 and v2.0 to v3.0.

Apparently this is not something we recommend. But you can do it nevertheless.

If you have read Jeffrey Richter’s article on the future of assembly version, you will know that those people belong to the category of machine platform. To be a machine platform assembly the AppCompat bar is extremely high. It is unlikely that many people want to be in that position.

You can ignore all of these concerns and just do it anyway.

Or you can ship the newer version of assembly without publisher policy, and selectively forward the assembly to the newer version for specific applications by issuing binding redirects in app.config for those applications. In this way you do not impact the whole system.