VB2008从入门到精通(PDF格式英文版)-第96部分

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！



　　　　　　　　　　　Understanding　the　convention　makes　it　easier　to　select　open　source　packages。　And　more　　

　　　　　　　　　　　important；　applying　this　versioning　strategy　makes　it　simpler　to　understand　your　assemblies。　



　　　　　　　　　　　Understanding　Version　Numbers　



　　　　　　　　　　　Let’s　say　you　want　to　download　the　open　source　program　Capivara　（a　Java　file　manager　and　　

　　　　　　　　　　　synchronization　program）。　You　see　the　version　number　0。8。3。　The　version　number　contains　　

　　　　　　　　　　　three　parts：　



　　　　　　　　　　　　　　　　Major　number：　The　major　number　is　0　in　the　example。　If　the　software　has　not　reached　the　　

　　　　　　　　　　　　　　　　number　1；　the　version　is　considered　a　beta。　But　often；　a　beta　identifier　does　not　mean　　

　　　　　　　　　　　　　　　　the　version　is　unusable。　Changing　the　major　version　number　indicates　a　major　change　　

　　　　　　　　　　　　　　　　of　functionality。　This　means　what　worked　in　version　1　may　not　work　with　version　2。　An　　

　　　　　　　　　　　　　　　　example　is　the　Apache　HTTPD　server　project；　where　the　1。x　and　2。x　series　are　two　different　　

　　　　　　　　　　　　　　　　implementations。　



　　　　　　　　　　　　　　　　Minor　number：　The　minor　number　is　8　in　the　example。　It　is　used　to　define　minor　function

　　　　　　　　　　　　　　　　ality　changes　in　a　piece　of　software。　Changing　the　minor　number　（such　as　7　to　8）　indicates　　

　　　　　　　　　　　　　　　　new　features；　but　old　functionality　is　supported。　A　change　may　include　bug　fixes　or　patches。　



　　　　　　　　　　　　　　　　Patch　number：　The　path　number　is　3　in　the　example。　It　is　used　to　define　a　patched　version　　

　　　　　　　　　　　　　　　　of　the　software　that　has　bug　fixes　or　other　changes。　The　changes　do　not　include　features；　　

　　　　　　　　　　　　　　　　and　the　functionality　does　not　change。　



　　　　　　　　　　　　　　　　When　you　attempt　to　download　an　open　source　package；　you　are　typically　confronted　with　　

　　　　　　　　　　　multiple　versions。　For　example；　you　might　see　the　version　numbers　4。23　and　4。29　（beta）。　Because　　

　　　　　　　　　　　most　people　want　the　latest　and　greatest；　they　might　be　tempted　to　download　4。29。　But　remember　　

　　　　　　　　　　　that　open　source　projects　make　multiple　versions　available。　In　the　example；　you　should　down

　　　　　　　　　　　load　version　4。23；　because　4。29　is　a　beta　that　may　or　may　not　work。　Version　4。23　is　considered　　

　　　　　　　　　　　stable　and　therefore　usable。　

　　　　　　　　　　　　　　　　The　open　source　munity　will　often　use　the　following　terminology　when　releasing　　

　　　　　　　　　　　software。　



　　　　　　　　　　　　　　　o　　Stable：　A　version　that　can　be　used　in　a　production　environment　and　should　not　crash。　



　　　　　　　　　　　　　　　o　　　Unstable：　A　version　that　should　not　be　used　in　production。　It　will　probably　work；　but　　

　　　　　　　　　　　　　　　　　　have　some　crashes。　



　　　　　　　　　　　　　　　o　　Nightly：　A　version　with　all　bets　off；　meaning　that　the　version　may　or　may　not　work。　The　　

　　　　　　　　　　　　　　　　　　reason　for　using　a　nightly　build　is　to　monitor　progress　and　check　specific　issues。　Such　a　　

　　　　　　　　　　　　　　　　　　version　is　not　intended　for　consumer　consumption；　it　is　intended　solely　for　developers。　



　　　　　　　　　　　　　　　o　　Alpha　：　A　version　that　demonstrates　the　concepts　that　will　make　up　a　future　version　of　the　　

　　　　　　　　　　　　　　　　　　software。　However；　in　alpha　versions；　what　was　available　one　day　might　be　gone　the　　

　　　　　　　　　　　　　　　　　　next　day。　


…………………………………………………………Page　357……………………………………………………………

　　　　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　AP　P　L　I　CAT　I　ON　　　CO　N　F　IG　U　R　AT　IO　N　　　A　N　D　　　D　Y　N　A　M　IC　　　L　O　AD　IN　G　335　



Versioning　Assemblies　



　assembly　version　numbers　are　different　from　those　used　for　open　source　packages。　The　　

following　is　an　example　of　versioning　an　assembly。　



　

　



　　　　　The　attributes　AssemblyVersion　and　AssemblyFileVersion　can　be　added　anywhere　in　the　　

assembly　or　application。　In　Visual　Basic　Express；　most　likely　the　attributes　are　added　to　the　file　　

AssemblyInfo。vb。　

　　　　　The　versions　of　the　file　have　four　significant　parts。　From　left　to　right；　these　are　major　　

version；　minor　version；　build　number；　and　revision。　The　build　number　can　represent　a　daily　　

build　number；　but　this　is　not　required。　The　revision　identifier　can　represent　a　random　number；　　

but　this　is　not　required　either。　For　my　assemblies；　I　use　a　revision　number　of　0；　and　consider　the　　

build　number　as　a　patch　number。　

　　　　　Visual　Basic　Express　has　a　built…in　mechanism　that　automatically　updates　the　build　and　　

revision　numbers。　Here；　the　asterisk　represents　the　auto…increment：　



　



　　　　　Alternatively；　you　can　use　a　versioning　tool；　or　you　can　increment　the　numbers　manually。　　

The　gacutil　tool　can　be　executed　multiple　times　with　multiple　versions；　as　shown　in　Figure　12…4。　



■Note　　For　more　information　about　using　versioning　tools；　see　this　blog　entry　about　auto…incrementing　　

assembly　versions：　http：//weblogs。asp/bradleyb/archive/2005/12/02/432150。aspx。　



Figure　12…4。　An　assembly　added　three　times　to　the　GAC　with　three　different　versions　



　　　　　In　Figure　12…4；　the　assembly　VersioningAssembly　has　been　added　three　times　to　the　GAC　　

with　three　different　versions　（1。0。0。0；　1。1。0。0；　an　d　1。2。0。0）。　With　the　GAC　in　this　state；　an　appli

cation　or　another　assembly　has　the　option　to　reference　three　different　versions　of　the　same　　

assembly。　


…………………………………………………………Page　358……………………………………………………………

336　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　A　R　N　I　N　G　　　A　B　OU　T　　　A　PP　L　I　CA　TI　O　N　　　CO　N　F　I　G　U　R　AT　IO　N　　　AN　D　　　D　Y　N　A　M　I　C　　L　O　AD　I　N　G　



　　　　　　　　　　　　　　　　For　an　application　or　assembly　to　use　another　assembly；　you　create　a　reference。　When　the　　

　　　　　　　　　　application　or　assembly　is　piled；　a　specific　version　number　of　the　assembly　is　referenced。　　

　　　　　　　　　　For　example；　if　a　reference　to　the　version　1。1。0。0　of　VersioningAssembly　is　defined；　then　version　　

　　　　　　　　　　　1。1。0。0　of　the　assembly　is　loaded。　



　　　　　　　　　　Adding　an　Assembly　Redirection　to　a　Configuration　File　



　　　　　　　　　　Let’s　say　an　application　or　assembly　needs　to　use　a　new　version　of　the　VersioningAssembly　　

　　　　　　　　　　assembly。　To　make　the　application　or　assembly　aware　of　the　new　assembly；　you　update　the　　

　　　　　　　　　　application　or　assembly　configuration　file　that　references　the　old　assembly。　The　configuration　　

　　　　　　　　　　file　update　includes　an　assembly　redirection。　Essentially；　what　the　redirection　says　is　that　if　a　　

　　　　　　　　　　certain　version　of　an　assembly　is　requested；　the　new　version　should　be　loaded。　The　following　is　　

　　　　　　　　　　an　example　of　an　assembly　redirection。　



　　　　　　　　　　　

　　　　　　　　　　　

　　　　　　　　　　　　　

　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　

　　　　　　　　　　　　　

　　　　　　　　　　　



　　　　　　　　　　　　　　　　This　configuration　file　includes　an　assemblyBinding　XML　element　that　defines　a　collection　　

　　　　　　　　　　of　assemblies　that　will　be　affected。　The　collection　of　assemblies　is　embedded　within　the　　

　　　　　　　　　　dependentAssembly　element。　Within　the　dependentAssembly　element　are　two　child　elements：　　

　　　　　　　　　　assemblyIdentity　and　　bindingRedirect。　The　assemblyIdentity　element　is　used　to　identity　the　　

　　　　　　　　　　assembly　for　which　a　reference　will　be　redirected。　　

　　　　　　　　　　　　　　　　The　bindingRedirect　element　contains　two　attributes：　oldVersion　and　　newVersion。　The　　

　　　　　　　　　　oldVersion　attribute　identifies　the　version　of　the　old　assembly　in　the　calling　assembly　or　appli

　　　　　　　　　　cation。　If　the　specified　version　of　the　old　assembly　is　found；　the　newVersion　attribute　is　used　to　　

　　　　　　　　　　identify　which　assembly　version　should　be　used　instead。　In　the　example；　the　old　version　is　1。1。0。0；　　

　　　　　　　　　　and　the　new　version　is　1。2。0。0。　The　new　version　has　an　incremented　minor　number；　indicating　　

　　　　　　　　　　a　new　version　of　an　assembly。　However；　the　binding　redirection　does　not　care　whether　the　　

　　　　　　　　　　　newVersion　attribute　references　a　newer　version　or　an　older　version。　The　version　identifiers　　

　　　　　　　　　　identified　by　the　attributes　newVersion　and　oldVersion　are　just　that：　identifiers。　


…………………………………………………………Page　359……………………………………………………………

　　　　　　　　　　CH　AP　T　E　R　　　1　2　　　■　　　　L　E　AR　N　IN　G　　　AB　O　U　T　　　AP　P　L　I　CAT　I　ON　　　CO　N　F　IG　U　R　AT　IO　N　　　A　N　D　　　D　Y　N　A　M　IC　　　L　O　AD　IN　G　337　



Implementing　a　Shared　Typed　Convention…Based　　

Architecture　



There　has　been　quite　a　bit　of　talk　in　the　software　munity　about　convention　over　configu

ration。　Most　of　this　talk　began　in　earnest　with　the　development　of　Ruby　on　Rails　（http：//　

rubyonrails。org/）。　Ruby　on　Rails　（Rails　for　short）　is　a　tool　that　allows　people　to　very　　

quickly　create　web　sites　that　provide　useful　functionality。　　

　　　　　Many　attribute　the　success　of　Rails　to　its　use　of　convention　over　configuration。　Some　say　　

it　is　the　Ruby　language。　Others　say　it　is　because　Rails　is　a　professional　product。　I　believe　it’s　a　　

bination　of　factors；　but　the　convention　over　configuration　angle　does　play　an　important　role。　

　　　　　Let’s　go　back　to　the　problem　of　loading　code　dynamically；　or　for　that　matter；　executing　　

code　dynamically。　How　much　do　you　expect　the　programmer　to　know；　and　how　much　do　you　　

expect　the　programmer　to　guess？　Consider　this　code：　



Interface　IDefinition　

End　Interface　　



Sub　DoIt（ByVal　def　As　IDefinition）　

　　　'　Do　Something　with　def　

End　Sub　



　　　　　In　the　code；　you　can　see　an　interface　IDefinition　and　a　method　DoIt（）；　with　a　parameter　　

of　type　IDefinition。　This　creates　a　contract　where　to　call　DoIt（）；　you　need　to　pass　an　instance　　

of　type　IDefinition。　

　　　　　Is　it　correct　to　assume　that　the　dynamic　loading　of　a　type　can　fulfill　the　contract