Fixed SD2-1023: SharpDevelop.exe.config bindingRedirect contains question marks
Update to new NSvn version (can now use Subversion 1.4 working copies)
Update StringResources.
git-svn-id: svn://svn.sharpdevelop.net/sharpdevelop/trunk@1719 1ccf3a8d-04fe-1044-b7c0-cef0b8235c61
runs as pre-compile target and always sets the number in GlobalAssemblyInfo.cs
to the subversion revision number. That number is displayed
in the splash screen, error dialog and about dialog.
It is also used as assembly version.
</P>
<p>
The revision number is retrieved by running a function in NSvn.Core.dll equivalent to "svn info"
in the "src" folder.
When this doesn't work (e.g. in an exported tree like the source code download on the build server), the
content of the file src/REVISION is used as revision number.
When even this fails, the revision '9999' is used.
</p>
<H2>Publisher Policy</H2>
<P>While the assembly versioning schema is not so important inside
SharpDevelop, it is important for 3rd party addins because the main
@ -81,17 +32,24 @@ assembly compiled against a strong-named assembly can only be used
@@ -81,17 +32,24 @@ assembly compiled against a strong-named assembly can only be used
with exactly the version of the library it was compiled with.
</P>
<P>This means if a 3rd-party addin was compiled against version
2.0.1.a, it cannot bind to version 2.0.1.b or 2.0.2.c; even if it
2.1.0.a, it cannot bind to version 2.0.0.b or 2.0.1.c; even if it
would run without problems. Therefore, SharpDevelop.exe.config
contains binding redirects for the strong-named libraries that addins
would want to reference.
</P>
<P>The binding redirects always redirect from version 2.x.0.1 to the
current version. That means 3rd-party addins must be compiled against
a debug version of SharpDevelop (after executing
"resetAssemblyInfo.bat") and they will bind to every
SharpDevelop version (and if the classes used by the addin stayed
binary compatible, it will even run with every SharpDevelop version).
<P>The binding redirects always redirect requests of a version in the range
from some past version containing large breaking changes to the current version.
We will not do such changes anymore after the first release candidate of a SharpDevelop version,
so after the release of SharpDevelop x.y RC1, all future SharpDevelop x.y.*.* versions will be
in large parts binary compatible.
<br>
For example, SharpDevevelop 2.1.0.1708 uses this redirection:</P>
Daniel Grunwald
19 years ago