It's time to check if binary compatibility policies really work for R#4 builds,
as all the required stuff like binding redirections has been implemented.
On the other hand, we still have time to fix something before the release.
Binary compatibility means that R# is able to run plugins built against binaries
of an older version, within one major version number (like, 4.0). Obviously,
you would not like to release a new version of a plugin for each new build
What is the expected behavior, if things are working as intended?
If you build a plugin against R# binaries of, say, version 4.0.804.16, its
DLL references explicitly specify the version number as a part of the assembly
identity. Normally, if an assembly of a higher version is found instead,
it would not fit. Without special measures, a plugin will fail to load in
R# 4.0.808.22, as the assemblies it references have another identity. Binding
redirections shipped with R# indicate that a DLL version 4.0.808.22 could
be used in place of a referenced DLL version 4.0.804.16, or any other version
below the target one.
So, a plugin built against 4.0.804.16 will load in 4.0.808.22, but not vice
How to check?
We encourage you to check if the binding redirections work for your plugin
To do that, you could build the plugin against an older build, for example,
R#4 beta v4.0.804.16, and then upgrade R# to some newer version, built on
2008-05-24 or later. The plugin should be working as good as under its "native"
Unit test runner plugins are in the risk zone, as they're run in three environments
instead of just one (Visual Studio, TaskRunner.exe primary domain, TaskRunner.exe
isolated domain with user config), and in each case the versions need to
be properly redirected.
Please report any versioning problems you encouter so that we could get them
fixed by the release.
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”