R#4 OpenAPI: Binary Compatibility Check

Plugin developers,

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
of R#.

________
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
versa.

________
How to check?

We encourage you to check if the binding redirections work for your plugin
as intended.

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"
R# version.

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.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


2 comments
Comment actions Permalink

Hi Serge,

my NHibernate plugin works in that way. It has only problems if you
change interfaces ;) (like the namespace change with build around 770
and the change in IProperty around 807).


Regards,
Stefan Lieser
--
http://www.lieser-online.de


Serge Baltic schrieb:

Plugin developers,

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 of R#.

________
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 versa.

________
How to check?

We encourage you to check if the binding redirections work for your
plugin as intended.

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" R# version.

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.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”

0
Comment actions Permalink

Hello,

my NHibernate plugin works in that way. It has only problems if you
change interfaces ;) (like the namespace change with build around 770
and the change in IProperty around 807).


Oops, sorry for that ;)

Soon enough we'll throw in a build-time API consistency check, so the API
will be frozen for the R#4 branch.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0

Please sign in to leave a comment.