radisson Skrevet 19. september 2006 Del Skrevet 19. september 2006 Halloen, jeg opplever en litt frustrerende problemstilling i forbindelse med prosjekter hvor flere skal involveres. Problemet oppstår når csproj / vbproj filene inneholder referanser til bibiotek (DLL-filer). Første utvikler utviklet et prosjekt på d:\myproject og så sjekkes det inn i sourcesafe. hvis en annen utvikler skal overta og la os si at han ikke har noen d:\myproject, men bestemmer seg for å istedet sjekke ut filene til c:\mybestproject, da vil vel csproj filene inneholde bane til referansene som de vil forsøke og lete etter men ikke finne pga at filene dengang lå et annet sted. Videre kan kanskje en annen utvikler sette opp working folder et helt annet sted. og plutselig har vi tre utviklere som alle har prosjektet lokalt på helt ulike steder. og dette vil vel om jeg ikke tar feil alltid medføre at csproj/vbproj filene for 2 av 3 utviklere peker på feil sted? Er det noen måte å løse dette problemet på. En annen ting jeg også lurer litt på er at en solution inneholder en til mange prosjekter. Dersom alle disse prosjektene er i seperate mapper vil de kompilerte filene havne debug/release kataloger under de ulike prosjektene. Men hva skjer hvis de ulike prosjektene forsøker å referere til hverandre? må man manuelt kopiere ut dll filer fra et prosjekt til et annet? Lenke til kommentar
wolf5 Skrevet 22. september 2006 Del Skrevet 22. september 2006 1. Sleng felles DLL'er dere bruker i GAC'en og referer til disse. Ellers om dere bruker DLL'er som følger prosjektet, sleng DLLene inn i en underkatalog i prosjektet og referer til disse. Dette blir da en relativ referanse og dermed blir det ikke problemer med hvor selve prosjekt root-katalogen er. Om det er c:\mittprosjekt eller d:\testprosjekt. Referansen peker likevel til f.eks ".\MineDller\mindll.dll". Dersom dere bruker byggemaskin og DLLene ikke skal i GAC så funker denne metoden utmerket. 2. Nei. Inni prosjektet bruker man Add Reference og peker til prosjektet man skal referere til og ikke til DLL. Da holder .Net rede til enhver tid hvor den rette debug\*.dll'en ligger. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå