Opdeling af program, i filer/Dll

Ups, glemte lige at sige, at jeg har added et class projekt til min solutiuon, og den opretter så en Dll fil, når det bliver compilet, er det den rigtige måde, eller er der andre smarte måder???

Og hvis man lige har Rebuilded sin Dll, hvordan opdatere man så info i sit main projekt, så den kender det nye der er blevet skrevet/compilet???

Du skal skelne mellem:
a)  opdelingen i pakker (namespaces i C#) og klasser [UML class digram]
b)  opdelingen i source code filer
c)  opdelingen i DLL og EXE filer [UML deployment diagram]

De opdelinger er næsten men ikke helt uafhængige.

#a får du ud af dit objektorienterede design.

#b bestemmer du udfra mere praktiske betragtninger om projekt process
(hvad skal altid buildes sammen, hvad skal kun en person arbejde
på samtidigt, hvad giver mening kun at have en version på i source control).

#c bstemmer du primært udfra en analyse af, hvad der kan/skal opdateres sammen.
Underlagt visse restriktioner fra #a og #b.

[og hvis du snakker sådan lidt mere nede på jorden brug af Visual Studio, så
har jeg ingen anelse]

1#
Jeg forstår desværre ikke helt dit spørgsmål

2#
Flere filer (xxx.cs) i samme assembly er for mig meget forvirrende, ydermere ville du kunne opdatere dine applikationer meget lettere hvis du sørger for at dele dem op i nogle assemblys(DLL´er) som du forudser skal opdateres på et tidspunkt. Derved kan du bare kompilere og opdatere en DLL der varetager XML-parsing fremfor at skulle kompilere hele applikatione igen. Jeg synes også at det er rart, når jeg udvikler, at lave applikationer i etaper (hvilket jo i stor grad også afhænger af hvilke udviklingsmetode(r) man anvender). Således kan jeg, hver gang jeg har nået en etape, fjerne den enkelte assembly fra mit projekt, så det ikke ligger og forvirrer.

Generelt sørger jeg for at dele mine applikationer op i enkelte DLL´er der har en konkret logik som jeg forudser at jeg kan gøre brug af i andre applikationer. Jeg deler også ofte op således at mine applikationer er lette at vedligeholde.

3#
Som eksempel kan man have en applikation der anvender en database til at holde styr på et firmas kunder. Selve database delen ville jeg adskille i en DLL. På den måde er det let at skifte den database/persistenstype som applikationen skal anvende.

Når du udvikler meget, kan du også efterhånden selv mærke hvis der er noget kode du altid skriver igen og igen på tværs af projekter og i projekter. Disse kodestumper ville heller ikke være dumme at flytte ud i en DLL for sig selv...

4#
Ved det ikke endu selv :)

5#
Hvis du benytter Visual Studio (som jeg formoder) kan du i samme solution have både EXE assembly samt DLL assembly åben samtidig. I din EXE assembly er der oprettet en reference til din DLL assembly. I dine egenskaber for projektet kan du således angive hvilke assemblies der er afhængige af hinanden, således at du altid får kompileret i den rigtige rækkefølge. Hvis du gør det på ovenstående måde vil du altid have den sidst opdaterede DLL sammen med din EXE.

Håber at du kan bruge det til noget... :)
Mvh Casualty

går ud fra at det du ikke ved også er det med obj og bin mapperne.....

Men ellers meget godt forklaret på hvad jeg sprugte om, kunne næsten ikke være meget klart.

obj-mappen er præcompilerede filer visual studio bruger, primært til sin intellisense. bin-mappen er hvor dine compilerede dll'er/exe-filer ryger hen (med mindre du har valgt et andet sted under egenskaber for din projekt.

Et svar, hvis det skulle være... :)

vil fessor og arne oxo have lidt point?

jo tak

svar :)