[VS2003/2005] File references managen

[DrDelete]

Ik vraag me af wat de beste werkwijze is om met file references om te gaan in Visual Studio 2005.

Er zijn verschillende mogelijkheden:

1) Met een virtual drive letter (R bijv, door het dos commando SUBST R: path) en vanaf R: de externe libraries te plaatsen. Zodoende kan elke ontwikkelaar zelf bepalen waar R naar gemapped wordt. Dit raadt MS aan. Je moet als ontwikkelaar wel een scriptje schrijven met de SUBST command en deze moet voor het open van de solution gestart zijn. Bijv. R:\OtherLib1.0.5000.0
2) Je kiest voor gestandaardiseerde paden, bijv. alle externe libaries plaatsen onder D:\Extern met naam en versie, zoals D:\Extern\OtherLib1.0.5000.0. Het nadeel is dat keihard een pad in de .csproj opgeslagen zit.
3) Je maakt registry entries aan onder HKEY_LOCALMACHINE\SOFTWARE\MICROSOFT\.NETFramework\AssemblyFolder en je maakt daar een key met daarbinnen een value die verwijst naar een specifieke folder, bijv. een key HKEY_LOCALMACHINE\SOFTWARE\MICROSOFT\.NETFramework\AssemblyFolder\OtherLib met als value "D:\Extern\OtherLib1.0.5000.0".

Een collega werkt op de 3e manier en het werkt inderdaad en was voor mij een nieuwe manier van werken.

Hoe werken jullie met file references ?

[tijn]

Assembly references doe ik altijd relatief. In de root van de solution maak ik een lib directory en vanuit de projecten refereer ik dan naar ..\lib\EenOfAndereAssembly.dll.

Simpel en nooit gezeik met kapotte references.

[DrDelete]

tijn schreef op vrijdag 02 maart 2007 @ 12:43:
Assembly references doe ik altijd relatief. In de root van de solution maak ik een lib directory en vanuit de projecten refereer ik dan naar ..\lib\EenOfAndereAssembly.dll.

Simpel en nooit gezeik met kapotte references.

Dus je neemt in je source control repository voor elke solution alle binaries mee van je externe libraries. Dat betekent bijv. voor 5 solutions die een file reference hebben naar NHibernate versie 1.0.4 dat je 5 x de libraries kopieert en in source control repository zet... loopt je repository snel vol en bevat deze tevens compiled code.

[tijn]

Ja inderdaad en ik heb er geen problemen mee. het kan nl. best wel eens voorkomen dat het ene project bijv. een eerdere versie van een bepaalde library nodig heeft. Je noemt nu net NHibernate. Als alle projecten naar dezelfde versie verwijzen en je besluit voor 1 project over te gaan stappen op 1.2.0 (vanwege generics support oid) heb je wel een probleem bij je andere projecten.

Verder is schijfruimte goedkoop en sinds het dumpen van SourceSafe zijn binaries ook geen issue meer .

Maar natuurlijk geldt uiteindelijk dat een ieder voor zich een methode moet vinden waar hij/zij zich prettig bij voelt en dat verschilt van persoon tot persoon. Ik krijg jeuk van subst hacks en vage registry instellingen...

[DrDelete]

tijn schreef op zaterdag 03 maart 2007 @ 00:47:
Ja inderdaad en ik heb er geen problemen mee. het kan nl. best wel eens voorkomen dat het ene project bijv. een eerdere versie van een bepaalde library nodig heeft. Je noemt nu net NHibernate. Als alle projecten naar dezelfde versie verwijzen en je besluit voor 1 project over te gaan stappen op 1.2.0 (vanwege generics support oid) heb je wel een probleem bij je andere projecten.

Verder is schijfruimte goedkoop en sinds het dumpen van SourceSafe zijn binaries ook geen issue meer .

Maar natuurlijk geldt uiteindelijk dat een ieder voor zich een methode moet vinden waar hij/zij zich prettig bij voelt en dat verschilt van persoon tot persoon. Ik krijg jeuk van subst hacks en vage registry instellingen...

Elke externe library moet natuurlijk inclusief versienummer te vinden zijn in zijn eigen submap.

dus bijv.

R:\NHibernate 1.0
R:\NHibernate 2.0