@ -6,73 +6,24 @@
< META NAME = "GENERATOR" CONTENT = "OpenOffice.org 2.0 (Win32)" > < META NAME = "GENERATOR" CONTENT = "OpenOffice.org 2.0 (Win32)" >
< META NAME = "AUTHOR" CONTENT = "Daniel Grunwald" > < META NAME = "AUTHOR" CONTENT = "Daniel Grunwald" >
< META NAME = "CREATED" CONTENT = "20051129;18411803" > < META NAME = "CREATED" CONTENT = "20051129;18411803" >
< META NAME = "CHANGED" CONTENT = "20051129;18415575" >
< / HEAD > < / HEAD >
< BODY LANG = "en-US" DIR = "LTR" > < BODY LANG = "en-US" DIR = "LTR" >
< H1 > Assembly Versioning in SharpDevelop< / H1 > < H1 > Assembly Versioning in SharpDevelop< / H1 >
< H2 > How the versions are set< / H2 > < H2 > How the versions are set< / H2 >
< P > The assemblyInfo.cs files are updated by the tool< P > The assemblyInfo.cs files are updated by the tool
" UpdateAssemblyInfo" . " UpdateAssemblyInfo Startup" " UpdateAssemblyInfo" . UpdateAssemblyInfo
runs as pre-compile target and always set's SharpDevelop.exe'sruns as pre-compile target and always sets the number in GlobalAssemblyInfo.cs
revision to the subversion revision number. That number is displayedto the subversion revision number. That number is displayed
in the splash screen, error dialog and about dialog. in the splash screen, error dialog and about dialog.
< / P > It is also used as assembly version.
< P > The libraries (Core, SharpDevelop, TextEditor, NRefactoring,< / P >
Addins) however are a little different. Their assemblyinfos are not< p >
" templated" like the one in Startup, but directly includedThe revision number is retrieved by running a function in NSvn.Core.dll equivalent to "svn info"
in the repository. However, we don't want to re-commit them on everyin the "src" folder.
commit. Therefore, the versioning is different. When this doesn't work (e.g. in an exported tree like the source code download on the build server), the
< / P > content of the file src/REVISION is used as revision number.
< P > " ReleaseBuild.bat" updates their AssemblyInfo, too; butWhen even this fails, the revision '9999' is used.
the normal " build.bat" doesn't. In the repository, they are< / p >
always included with the version number " 2.0.0.1" . When
doing a releasebuild, this version is replaced by the major version
from Startup + the subversion revision number. (That means if you
want to change from " 2.0.0.x" to " 2.0.1.x" , you
only have to change Startup\AssemblyInfo.< B > template< / B > )
< / P >
< P > If you now want to commit local repository changes, you have to
revert the assembly infos back to " 2.0.0.1" first. This is
done by the file " resetAssemblyInfo.bat" .
< / P >
< P STYLE = "margin-bottom: 0cm" > So in conclusion, the assemblies are
versioned like this:
< / P >
< TABLE CELLPADDING = 2 CELLSPACING = 2 >
< TR >
< TH >
< P > < / P >
< / TH >
< TH >
< P > Debug< / P >
< / TH >
< TH >
< P > Release< / P >
< / TH >
< / TR >
< TR >
< TH >
< P > SharpDevelop.exe< / P >
< / TH >
< TD >
< P > 2.x.y.r< / P >
< / TD >
< TD >
< P > 2.x.y.r< / P >
< / TD >
< / TR >
< TR >
< TH >
< P > Libraries< / P >
< / TH >
< TD >
< P > 2.x.0.1< / P >
< / TD >
< TD >
< P > 2.x.y.r< / P >
< / TD >
< / TR >
< / TABLE >
< H2 > Publisher Policy< / H2 > < H2 > Publisher Policy< / H2 >
< P > While the assembly versioning schema is not so important inside< P > While the assembly versioning schema is not so important inside
SharpDevelop, it is important for 3rd party addins because the mainSharpDevelop, 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
with exactly the version of the library it was compiled with. with exactly the version of the library it was compiled with.
< / P > < / P >
< P > This means if a 3rd-party addin was compiled against version< 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 it2.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.configwould run without problems. Therefore, SharpDevelop.exe.config
contains binding redirects for the strong-named libraries that addinscontains binding redirects for the strong-named libraries that addins
would want to reference. would want to reference.
< / P > < / P >
< P > The binding redirects always redirect from version 2.x.0.1 to the< P > The binding redirects always redirect requests of a version in the range
current version. That means 3rd-party addins must be compiled againstfrom some past version containing large breaking changes to the current version.
a debug version of SharpDevelop (after executingWe will not do such changes anymore after the first release candidate of a SharpDevelop version,
" resetAssemblyInfo.bat" ) and they will bind to everyso after the release of SharpDevelop x.y RC1, all future SharpDevelop x.y.*.* versions will be
SharpDevelop version (and if the classes used by the addin stayedin large parts binary compatible.
binary compatible, it will even run with every SharpDevelop version).< br >
For example, SharpDevevelop 2.1.0.1708 uses this redirection:< / P >
< pre > < bindingRedirect oldVersion="2.1.0.1661-2.1.0.1708" newVersion="2.1.0.1708"/> < / pre >
< P >
That means if you want to release a 3rd-party AddIn (AddIn that is not shipped with SharpDevelop),
compile it against the oldest SharpDevelop version you want your AddIn to run with.< br >
An AddIn compiled against 2.1.0.1800 will run with 2.1.0.1801 (and hopefully even with 2.1.23.45678),
but an AddIn compiled against 2.1.0.1801 will fail to load in SharpDevelop 2.1.0.1800.
< / P > < / P >
< / BODY > < / BODY >
< / HTML > < / HTML >
Daniel Grunwald
20 years ago