Pozdravljeni.
Delam diplomsko nalogo na temo uporabe programskih orodij pri izdelavi računalniške aplikacije in izbral sem si temo z uporabo Visual studia 2005 s programskim jezikom C#.
Pri mojem delu sicer uporabljam VS2005 vendar programiram v C++. Mogoče je prav to vzrok mojim težavam: v C# ne morem nastavit output direktorija - to je direktorija, kjer se zbuilda .exe file. Če nastavim pot tako, da jo "pobrowsam" gre. Tudi če mu dam absolutno pot gre. Vendar pri C++ projektu lahko uporabljam za to environment spremenljivko. In tu je težava.
Npr. environment spremenljivka nastavljena preden poženem VS je PROJ_OUT in kaže recimo na C:\PROJ\Out
V C++ projektu nastavim output direktorij na $(PROJ_OUT) in potem mi zbuilda .exe na ta (v tem primeru) C:\PROJ\Out direktorij.
To sem poizkušal naredit tudi v C# projektu vendar mi je v tem primeru VS2005 naredil poddirektorij $(PROJ_OUT) in notri klasično Bin\Debug oz. Bin\Release strukturo. Se pravi ne razume, da je $(PROJ_OUT) spremenljivka.
Torej, rad bi si nastavil Output direktorij in Object direktorij nekako dinamično - z environment spremenljivko. Gledano iz stališča programerskega team-a: vsaka delovna postaja ima pač svoj "root" direktorij za "C# solution". To bi se zelo elegantno rešilo na tak način.
A obstaja sploh taka možnost, da se to da tako nastavit tudi za C# projekt?
Za odgovor se vnaprej zahvaljujem.
LP
Andreo
Andreo19 - ponedeljek, 19. marec 2007
Miha hvala za odgovor.Se pravi finta je v tem, da je treba odpret .csproj file z editorjem in popraviti ročno. Se mi je zdelo prav čudno, če se to ne bi dalo naredit. Hvala in lep pozdrav Andrej
MihaM - ponedeljek, 19. marec 2007
Prvi primer: V te namene se uporablja branching v source safe aplikaciji.Drugi primer: Uporabi spremenljivke, kot si na začetku želel. Finta je ta, da moraš odpreti csproj datoteko v beležnici in potem ročno popraviti poti, npr $(Temp) bo uporabil spremenljivko TEMP.
Andreo19 - ponedeljek, 19. marec 2007
Bom navedel primer(a) v katerem bi se to rabilo:Prvi primer: projektni team (recimo da dela 5 inženirjev na tem) izdeluje projekt, ki je že v fazi releasa recimo verzije 2.0. Verzija 1.0 se še vedno podpira. Pride bug katerega je treba pofiksat za verzijo 1.2. Seveda ga mora pofiksat tisti programer, ki je delal na tem delu projekta: to stori tako, da si "checkout-a" source kodo verzije 1.2 (iz Source kontrole) na nek drug "root" direktorij, da lahko dela vzporedno na obeh delih projekta. Kako bi se to dalo nastavit: projekt je isti le starejše verzije?Drugi primer: en programer v teamu ima pač malo drugačno sestavo svoje delovne postaje in bi mu delo oz. prevajanje močno pohitrilo, če bi se mu .obj file-i delali na nekem drugem direktoriju - ne na poddirektoriju OBJ projekta. Kako se to nastavi?Oba primera sta vzeta iz prakse in se (vsaj pri nas v podjetju, kjer sem zaposlen) to redno dogaja. Mogoče za manjše team-e tu res ni potrebe vendar tudi manjši team-i imajo od tega lahko korist.Vse skupaj ima seveda poanto predvsem v tem, da se projektno okolje določi vnaprej z namenom, da se v primeru novega člana teama kot tudi v mojem prvem primeru le novo okolje starejše verzije projekta vzpostavi hitro in z malo nastavitvami na novo delovno okolje prilagojeno vsaki delovni postaji posebej. Solution in project file-i so sedaj (prej pod Visual studio 6.0 so bili binarni) ASCII datoteke in so zato zelo primerne za Source kontrolo kar pa v recimo mojem drugem primeru ne bi bilo v redu ker bi bile (glede na moj drugi primer) nastavitve napačne oz. bi ta član ekipe imel oteženo delo.V C++ projektih imamo na voljo environment spremenljivke, ki to lahko rešijo zelo elegantno in ubijejo vse muhe na en mah (kljub še svojim posebnim nastavitvam nekje pod dokuments). A se da to uporabit tudi v C# projektih?LP Andrej
MihaM - nedelja, 18. marec 2007
Po pravici povedano ne vidim potrebe po temu. Načeloma ima vsak uporabnik shranjen projekt v svoji mapi (nekje pod documents) in potem se pot nastavi relativno, pa je. Vse skupaj je pa pod nekim source safe-om.