mboost-dp1
Hvilken .NET Framework version og hvorfor?
Hej nørder.
Hvis jeg lave et nyt .NET projekt, hvilken version af .NET Frameworket bør jeg så vælge og hvorfor? Her tænker jeg især på 3.0, 3.5 og 4.0.
På den ene side er 3.0 jo inkluderet i Vista og op, og 3.5 i 7 og op. Men på den anden side har de nyere nogle nye features, som det jo kunne tænkes jeg kunne få brug for. F.eks. hænder det at jeg bruger extension methods fra System.Linq som kræver 3.5.
Hvad synes I man overordnet set bør vælge?
Jeg ved der ikke er et enkelt svar på dette, men er blot interesseret i at høre jeres meninger og saglige begrundelser for dem.
Mvh. Spiderboy
Hvis jeg lave et nyt .NET projekt, hvilken version af .NET Frameworket bør jeg så vælge og hvorfor? Her tænker jeg især på 3.0, 3.5 og 4.0.
På den ene side er 3.0 jo inkluderet i Vista og op, og 3.5 i 7 og op. Men på den anden side har de nyere nogle nye features, som det jo kunne tænkes jeg kunne få brug for. F.eks. hænder det at jeg bruger extension methods fra System.Linq som kræver 3.5.
Hvad synes I man overordnet set bør vælge?
Jeg ved der ikke er et enkelt svar på dette, men er blot interesseret i at høre jeres meninger og saglige begrundelser for dem.
Mvh. Spiderboy
My 2 cents:
Hvis det er et internt projekt, så brug det du synes bedst om. Interne projekter bør ikke begrænse dig og dine teknologi valg.
Hvis det er til eksterne kunder på en klient platform, så er en ekstra download (evt som bootstrap i installer) intet problem. Vælg det du synes bedst om.
Hvis det er til eksterne kunder på en server platform, så ville jeg vælge den version, som du ved findes på dit produkts 'recommended OS'. Understøtter produktet eksempelvis både Win2k3 Server og Win2k8 Server, så vælg det framework, der er garanteret tilstede på Win2k3 Server. Ekstra downloads kan være nærmest umulige i nogle situationer og under alle omstændigheder vil kundens sys-admins sætte pris på så få systemændringer som muligt.
Edit: Begrundelser uddybet en lille smule.
Hvis det er et internt projekt, så brug det du synes bedst om. Interne projekter bør ikke begrænse dig og dine teknologi valg.
Hvis det er til eksterne kunder på en klient platform, så er en ekstra download (evt som bootstrap i installer) intet problem. Vælg det du synes bedst om.
Hvis det er til eksterne kunder på en server platform, så ville jeg vælge den version, som du ved findes på dit produkts 'recommended OS'. Understøtter produktet eksempelvis både Win2k3 Server og Win2k8 Server, så vælg det framework, der er garanteret tilstede på Win2k3 Server. Ekstra downloads kan være nærmest umulige i nogle situationer og under alle omstændigheder vil kundens sys-admins sætte pris på så få systemændringer som muligt.
Edit: Begrundelser uddybet en lille smule.
Med hensyn til SDK'et skal du selvfølgelige bruge det nyeste.
Når du så skal distributere dine apps, kan du jo forsøge at sørge for at de kan kører på .NET 4.0 Client Profile, eller 3.5 Client Profile.
.NET 4.0 Client Profile sikre så at brugeren kun skal hente 28.8mb, hvis de ikke allerede har .NET 4.0 installeret.
Læs: http://www.hanselman.com/blog/TowardsASmallerNET4D...
Du bør ikke bekymre dig om versioner under .NET 3.5.
Når du så skal distributere dine apps, kan du jo forsøge at sørge for at de kan kører på .NET 4.0 Client Profile, eller 3.5 Client Profile.
.NET 4.0 Client Profile sikre så at brugeren kun skal hente 28.8mb, hvis de ikke allerede har .NET 4.0 installeret.
Læs: http://www.hanselman.com/blog/TowardsASmallerNET4D...
Du bør ikke bekymre dig om versioner under .NET 3.5.
Windcape (4) skrev:
.NET 4.0 Client Profile sikre så at brugeren kun skal hente 28.8mb, hvis de ikke allerede har .NET 4.0 installeret.
Det var også en del at skulle hente...
Windcape (4) skrev:Med hensyn til SDK'et skal du selvfølgelige bruge det nyeste.
Windcape (4) skrev:Du bør ikke bekymre dig om versioner under .NET 3.5.
Den tankegang holder ikke en meter ude i den virkelige verden.
Pally (2) skrev:Hvis det er til eksterne kunder på en server platform, så ville jeg vælge den version, som du ved findes på dit produkts 'recommended OS'. Understøtter produktet eksempelvis både Win2k3 Server og Win2k8 Server, så vælg det framework, der er garanteret tilstede på Win2k3 Server. Ekstra downloads kan være nærmest umulige i nogle situationer og under alle omstændigheder vil kundens sys-admins sætte pris på så få systemændringer som muligt.
Jep.
Og det kan være endnu "værre": Win2k!
Pally (2) skrev:Hvis det er til eksterne kunder på en klient platform, så er en ekstra download (evt som bootstrap i installer) intet problem. Vælg det du synes bedst om.
Der er faktisk også en del firmaer hvor client PC'ere er låst på noget givet software.
Spiderboy (3) skrev:Mine projekter er ikke-kommercielle hobbyprojekter, som bruges af mig selv og potentielt også kunne blive brugt af andre privatpersoner.
Hvis de "andre privatpersoner" er studerende primært på naturvidenskabelige studier, så er der næppe noget problem i at forvente at de har .NET 4.0 installeret.
Man skal bare gøre sig klart at det ikke er en typisk målgruppe.
Jo, det gør det faktisk.arne_v (8) skrev:Den tankegang holder ikke en meter ude i den virkelige verden.
Og grunden til at man bare skal bruge det nyeste SDK, er fordi at .NET faktisk kan finde ud af at compilere til ændre versioner. (Igen, modsat Java)
Derudover vil du finde at .NET, ihvertfald i Danmark, primært bruges til service løsninger (ie. ASP.NET), hvor at man typisk har 100% frihed til at opgradere.
Specielt når .NET faktisk ikke breaker ved opgradering (og igen igen, modsat Java).
Hvis PC'erne er låst, hvordan vil de så installere det produkt du skal udvikle?arne_v (8) skrev:Der er faktisk også en del firmaer hvor client PC'ere er låst på noget givet software.
Når .NET faktisk er bagud-kompatibelt, så er det grundløst ikke at opgradere .NET versionen hvis det software man skal installere, kræver det.
Windcape (10) skrev:Hvis PC'erne er låst, hvordan vil de så installere det produkt du skal udvikle?
Selvom brugeren ikke har rettigheder til at opdatere .NET kan vedkommende godt have lov til at køre en egen EXE.
Det er vist endda en ret normal situation på arbejds PC'ere i større firmaer.
Windcape (10) skrev:Når .NET faktisk er bagud-kompatibelt, så er det grundløst ikke at opgradere .NET versionen hvis det software man skal installere, kræver det.
1) Selvom .NET var 100% bagud-kompatibelt, så ville man stadig skulle lave en dyr test for at verificer det.
2) .NET er ikke 100% bagud-kompatibelt. Kun 99.9% eller deromkring.
For potentielle 3.5-4.0 problemer se:
http://msdn.microsoft.com/en-us/library/ee941656.a...
Windcape (9) skrev:Og grunden til at man bare skal bruge det nyeste SDK, er fordi at .NET faktisk kan finde ud af at compilere til ændre versioner. (Igen, modsat Java)
Det lyder jo meget overbevisende.
Men det er imidlertid fri fantasi.
compiler, angiv version af sprog:
Java - ja via -source
C# - ja via /langversion
compiler, angiv version af libraries:
Java - ja via -bootclasspath
C# - ja (det er lidt bøvlet command line men det kan lade sig gøre)
compiler, angiv version af byte code:
Java - ja via -target
C# - nej (behovet er dog mindre da 2.0, 3.0 og 4.0 bruger samme version)
IDE, valg af version af tool set:
Eclipse, NetBeans, IntelliJ IDEA - ja
Visual Studio - ja
mulighed multiple major versioner:
Java - ja (xcopy software)
.NET - ja (1.1, 2.0, 3.0, 3.5 og 4.0 kan sameksistere)
mulighed multiple update versioner:
Java - ja (xcopy software)
.NET - nej
#1 jeg er enig med vindkappen, mht. at vælge nyeste version.
Samtlige gange jeg har været med til at vælge en ikke nyeste version af .net er der på et eller andet tidspunkt senere opstået et behov for nyeste version. Typisk pga. feature X. Der er så to veje: opgrader og kig ikke tilbage; lav en suboptimal hjemmekodet løsning der kun giver dig pain indtil du opgraderer.
Det eneste argument mod at bruge nyeste version er hvis du skal > 1000 klienter, der ikke har mulighed for automagisk udrulning af .net X. Eller kan de fleste mindre virksomheder godt fatte argumentet: 100 timer udvikling med nyeste .net, plus en times arbejde af jeres admin; 200 timer med version X .net, plus en halv times arbejde af jeres admin (han skal jo stadig rulle den nye app ud)
I min bog er valget nemt. Optimer ikke mod imaginære brugere.
Samtlige gange jeg har været med til at vælge en ikke nyeste version af .net er der på et eller andet tidspunkt senere opstået et behov for nyeste version. Typisk pga. feature X. Der er så to veje: opgrader og kig ikke tilbage; lav en suboptimal hjemmekodet løsning der kun giver dig pain indtil du opgraderer.
Det eneste argument mod at bruge nyeste version er hvis du skal > 1000 klienter, der ikke har mulighed for automagisk udrulning af .net X. Eller kan de fleste mindre virksomheder godt fatte argumentet: 100 timer udvikling med nyeste .net, plus en times arbejde af jeres admin; 200 timer med version X .net, plus en halv times arbejde af jeres admin (han skal jo stadig rulle den nye app ud)
I min bog er valget nemt. Optimer ikke mod imaginære brugere.
#15
En mere fornuftig tilgang er at skrive ens applikation, og så se om den kan kompilere på en ældre version af .NET -- og hvis det så virker, så bruge den version, indtil det bliver nødvendigt at bruge 4.0 til et eller andet.
Der er ingen grund til at begrænse sig selv unødvendigt.
En mere fornuftig tilgang er at skrive ens applikation, og så se om den kan kompilere på en ældre version af .NET -- og hvis det så virker, så bruge den version, indtil det bliver nødvendigt at bruge 4.0 til et eller andet.
Der er ingen grund til at begrænse sig selv unødvendigt.
Risikoen for at skrive kode der allerede i udgangspunktet er legacy kode er, alt andet lige, større ved at vælge en ældre platform.
Omvendt kan jeg ikke komme i tanke om kæmpe forskelle på 3.5 og 4.0. Jo der er forskelle, men hvor tit bruger man eksempelvis optional parameters?
Et helt andet argument er at hvilken vej du gerne vil holde kompatibilitet? Bagudrettet er antallet af klienter faldende eller konstant, hvorimod antallet fremadrettet er uendeligt. I det mindste teoretisk ;)
Omvendt kan jeg ikke komme i tanke om kæmpe forskelle på 3.5 og 4.0. Jo der er forskelle, men hvor tit bruger man eksempelvis optional parameters?
Et helt andet argument er at hvilken vej du gerne vil holde kompatibilitet? Bagudrettet er antallet af klienter faldende eller konstant, hvorimod antallet fremadrettet er uendeligt. I det mindste teoretisk ;)
#18 oh du har ret.
Prøvede bare at komme i tanke om en feature introduceret i .net 4.0 ;)
Der er vel også afhænigheder til specifikke komponenter i frameworket.
Prøvede bare at komme i tanke om en feature introduceret i .net 4.0 ;)
Der er vel også afhænigheder til specifikke komponenter i frameworket.
Benjamin Krogh (14) skrev:
Det eneste argument mod at bruge nyeste version er hvis du skal > 1000 klienter, der ikke har mulighed for automagisk udrulning af .net X. Eller kan de fleste mindre virksomheder godt fatte argumentet: 100 timer udvikling med nyeste .net, plus en times arbejde af jeres admin; 200 timer med version X .net, plus en halv times arbejde af jeres admin (han skal jo stadig rulle den nye app ud)
Nu er der faktisk virksomheder hvor man tester tingene inden man ruller nyt software ud.
Windcape (22) skrev:Og?
Det reducerer sandsynligheden for at en .NET 4.0 vil køre på 3.5, hvilket var emnet.
Windcape (22) skrev:Hvis man har brug for de nye klasser, så har man jo brug for dem.
Nej - man har brug for noget funktionalitet.
Hvis man bruger 3.5 laver man det på en 3.5 måde - hvis man bruger 4.0 laver man det på en 4.0 måde.
#23
Og hvis 3.5 måden var at du skulle implementere den manglede funktionalitet selv, hvor at 4.0 har det lavet for dig, hvad så?
Det er jo dybt fjollet at genopfindet den dybe tallerken bare fordi at man ikke vil opgradere sin .NET udgave.
Det er samme idioti som førte til 10 år med IE6
Og hvis 3.5 måden var at du skulle implementere den manglede funktionalitet selv, hvor at 4.0 har det lavet for dig, hvad så?
Det er jo dybt fjollet at genopfindet den dybe tallerken bare fordi at man ikke vil opgradere sin .NET udgave.
Det er samme idioti som førte til 10 år med IE6
Windcape (24) skrev:Og hvis 3.5 måden var at du skulle implementere den manglede funktionalitet selv, hvor at 4.0 har det lavet for dig, hvad så?
Så har man en rimelig busines case for 4.0.
Men jeg tror ikke at der er ret meget i 4.0 som ikke har noget tilsvarende i 3.5 (specielt ikke hvis man tager muligheden for 3. parts biblioteker med i billedet).
Windcape (24) skrev:Det er jo dybt fjollet at genopfindet den dybe tallerken bare fordi at man ikke vil opgradere sin .NET udgave.
Det er ikke fjollet.
Det er simpelthen et spørgsmål om penge.
Nej, ikke udover de ting som benytter sig af dynamics.arne_v (25) skrev:Men jeg tror ikke at der er ret meget i 4.0 som ikke har noget tilsvarende i 3.5
Men igen, .NET er nu engang mest benyttet som en service platform, hvor at man problemfrit kan opgradere, da man kan have alle versioner af .NET installeret side-by-side.
Det er et stok-konservativt argument ikke at opgradere ens software, som ikke ender med andet end endnu større opgraderingsproblemer, når man så endeligt opgraderer.
Java er endnu værre, da det så også påvirker brugerne igennem deres browsere, og dermed skaber en sikkerhedsrisiko for at surfe på nettet.
Den nemmeste måde at installere stuxnet på vise virksomheders IT-systemer, ville jo nok være at lave en Java Applet installer til formålet :p
Så derfor giver jeg ikke særlig meget for argumentet om at det er for dyrt, eller giver for mange problemer, at opgraderer.
arne_v (21) skrev:Nu er der faktisk virksomheder hvor man tester tingene inden man ruller nyt software ud.
Cool story bro.
Jeg synes bare ikke jeg er rendt over noget i .NET 4.0 som var et must-have og som ville retfærdiggøre at komplicere installationsprocessen for en masse brugere.
Til intern udvikling ville jeg self. vælge .NET 4.0, men jeg synes der skal et konkret behov på banen for at vælge 4.0 til programmer der skal distribueres til slutbrugere.
Til intern udvikling ville jeg self. vælge .NET 4.0, men jeg synes der skal et konkret behov på banen for at vælge 4.0 til programmer der skal distribueres til slutbrugere.
.net 4 fordi det forekommer mig lidt fjollet at skrive i noget, der er outdated når man alligevel starter på noget helt nyt.
Nej.Spiderboy (29) skrev:Er der en konsensus om filnavngivning for partielle klasser i C#? Og i så fald hvilken?
Men typisk bruger man:
Name.cs
Name.Foobar.cs
eller for markup:
MainPage.xaml
MainPage.xaml.cs
Du kan så gruperer filerne, så at "under" partielle klasser, expander ud fra din hovedklasse, ved at sætte det op i .csproj filen (kræver du kan finde ud af MS Build's XML markup)
Overordnet frarådes det at benytte partielle klasser, medmindre du skal seperer autogeneret indhold, fra alm. indhold.
Windcape (31) skrev:Overordnet frarådes det at benytte partielle klasser, medmindre du skal seperer autogeneret indhold, fra alm. indhold.
Hvorfor? Pga. at det går ud over overskueligheden?
Hvad hvis jeg skal lave nogle gigastore klasser med underklasser og alt muligt?
Et (ikke lige så godt) alternativ er at bruge extension methods.
#32:
Så bryder du formentlig adskillige design patterns. Klasser og metoder skal holdes små og koncise og du bør så vidt muligt sørge for at der er en 1:1 relation imellem klasser og filer - det andet er bare dovenskab.
Extension methods bør i praksis kun anvendes til at extende klasser, hvor du ikke har adgang til kildekoden, f.eks. .NET Framework klasser.
Hvad hvis jeg skal lave nogle gigastore klasser med underklasser og alt muligt?
Så bryder du formentlig adskillige design patterns. Klasser og metoder skal holdes små og koncise og du bør så vidt muligt sørge for at der er en 1:1 relation imellem klasser og filer - det andet er bare dovenskab.
Et (ikke lige så godt) alternativ er at bruge extension methods.
Extension methods bør i praksis kun anvendes til at extende klasser, hvor du ikke har adgang til kildekoden, f.eks. .NET Framework klasser.
mstify (33) skrev:Så bryder du formentlig adskillige design patterns. Klasser og metoder skal holdes små og koncise og du bør så vidt muligt sørge for at der er en 1:1 relation imellem klasser og filer - det andet er bare dovenskab.
Hvis nu den funktionalitet som en klasse skal tilbyde er meget kompleks, så er det ret svært at holde den "lille og koncis". Hvad skulle man så gøre? Forsøge at dele det mere op eller hvad?
Windcape (6) skrev:#5
Python er 13mb. Og forestil dig så at du skal have GTK+, eller wxwidgets med samtidigt.
Så er .NET lige pludselig mindre at hente.
(Og Java er endnu værre :p)
Prøv at gå ind på java.com, tryk på den store knap midt i det hele. Til mig foreslår den en fil på "~11 MB". Det er da vist en del under 28 MB.
Windcape (9) skrev:Og grunden til at man bare skal bruge det nyeste SDK, er fordi at .NET faktisk kan finde ud af at compilere til ændre versioner. (Igen, modsat Java)
Holy crap, endnu en umulig ting jeg gør til dagligt! Fuck, jeg er sej.
http://docs.elasticpath.com/download/attachments/1...
Mon ikke du skulle lade være med at blande Java ind i det? ;-)
Spiderboy (34) skrev:Hvis nu den funktionalitet som en klasse skal tilbyde er meget kompleks, så er det ret svært at holde den "lille og koncis". Hvad skulle man så gøre? Forsøge at dele det mere op eller hvad?
Nemlig. "Divide and conquer." Et komplekst problem deles op i mindre dele, til det ikke længere er komplekst.
Det betyder ikke at man skal kalde 1.000 klasser i stedet for én klasse, det betyder at den ene klasse skal delegere ansvaret videre.
myplacedk (37) skrev:Nemlig. "Divide and conquer." Et komplekst problem deles op i mindre dele, til det ikke længere er komplekst.
Det betyder ikke at man skal kalde 1.000 klasser i stedet for én klasse, det betyder at den ene klasse skal delegere ansvaret videre.
Jeg er stor tilhænger af divide and conquer. :-)
Det er bl.a. det jeg ville gøre med underklasser - delegere ansvaret videre. Disse underklasser ville ikke give voldsomt meget meningen uden for klassen.
Re(z) + i*Im(z)? (:myplacedk (37) skrev:Nemlig. "Divide and conquer." Et komplekst problem deles op i mindre dele, til det ikke længere er komplekst.
#38: Det gør det hurtigt uoverskueligt at have flere klasser i samme fil, jeg siger ikke at der ikke er plads til undtagelser og det gælder for såvidt også partial classes, men som udgangspunkt giver det normalt bedre struktureret kode principielt at holde 1 fil lig 1 klasse.
Benyt istedet mappestrukturering, eller evt. skil det ud som et seperat projekt såfremt det er generelt anvendeligt, hvis det er du har en case hvor du ved det vil afføde mange subklasser.
Min erfaring er at klasser over ca. 300 linier og metoder over ca. 15 liniers konkret kode indikerer dårlig opdelt kode - det er self. en tommerfingerregel og igen er der self. undtagelser, men hvis undtagelserne udgør mere end 1% af ens kodebase, så bør man nok overveje om den kode man skriver er ordentlig struktureret og øve sig lidt mere i diciplinen.
Edit: Jeg glemte iøvrigt at svare på dit spørgsmål fra #34, men det skyldes at myplacedk gjorde det så glimrende i #37 :)
Benyt istedet mappestrukturering, eller evt. skil det ud som et seperat projekt såfremt det er generelt anvendeligt, hvis det er du har en case hvor du ved det vil afføde mange subklasser.
Min erfaring er at klasser over ca. 300 linier og metoder over ca. 15 liniers konkret kode indikerer dårlig opdelt kode - det er self. en tommerfingerregel og igen er der self. undtagelser, men hvis undtagelserne udgør mere end 1% af ens kodebase, så bør man nok overveje om den kode man skriver er ordentlig struktureret og øve sig lidt mere i diciplinen.
Edit: Jeg glemte iøvrigt at svare på dit spørgsmål fra #34, men det skyldes at myplacedk gjorde det så glimrende i #37 :)
Windcape (26) skrev:Men igen, .NET er nu engang mest benyttet som en service platform,
Ja. Men der er nu også en del desktop apps.
Hvilket vel også var grunden til at du oprindeligt anbefalede client profile.
Windcape (26) skrev:hvor at man problemfrit kan opgradere, da man kan have alle versioner af .NET installeret side-by-side.
For en ny selvstændig app: ja.
Windcape (26) skrev:Java er endnu værre, da det så også påvirker brugerne igennem deres browsere, og dermed skaber en sikkerhedsrisiko for at surfe på nettet.
.NET er det samme via SL.
Windcape (26) skrev:Den nemmeste måde at installere stuxnet på vise virksomheders IT-systemer, ville jo nok være at lave en Java Applet installer til formålet :p
Godt at du har indset at Java applets er nemmere end C# SL.
:-)
#typer-filer relation
Det er ret almindeligt med 1:1 relation.
Kriteriet for en god relation er at det skal være nemt at arbejde med.
Hvis typen Foobar er i Foobar.cs er det nemt at finde den.
Men jeg vil postulere at det er nemmere at scrolle i den fil man står i end at åbne en ny fil.
Deraf følger at hvis man kan komme op med en model for at fordele mange klasser på færre filer som gør det lige så naturligt at finde klasser som 1:1 modellen så er det en udmærket løsning.
Så jeg er ikke ubetinget tilhænger af 1:1.
Det er ret almindeligt med 1:1 relation.
Kriteriet for en god relation er at det skal være nemt at arbejde med.
Hvis typen Foobar er i Foobar.cs er det nemt at finde den.
Men jeg vil postulere at det er nemmere at scrolle i den fil man står i end at åbne en ny fil.
Deraf følger at hvis man kan komme op med en model for at fordele mange klasser på færre filer som gør det lige så naturligt at finde klasser som 1:1 modellen så er det en udmærket løsning.
Så jeg er ikke ubetinget tilhænger af 1:1.
Overhovedet ikke. En af de typiske .NET 4 ting man bruger til COM er optional-parameters, som har været i .NET siden 1.0 (pga. VB.NET), men kun i C# siden version 4.arne_v (42) skrev:En af de typiske anvendelser for dynamic er COM og det kunne man også lave i tidligere .NET versioner.
Dynamics er stort set ikke brugt, udover til integration med JavaScript, og andre DSL'er.
Nej. Silverlight er et seperat subset af .NET, med egne APIs (som tit er forskellige, eller begrænsede fra .NET)arne_v (44) skrev:.NET er det samme via SL
Java Applets er ikke et seperat subset af Java. Det er ret stor forskel!
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund