.Net i kraftig vækst i virksomheder

#49
Har du prøvet at undersøge om dette er korrekt ?

Det er ikke utænkeligt de bare har skrevet det i bogen.

MySQL er f.eks. meget hurtig til at hente data fra DB'en, men mangler så mere avancerede features (endnu).

I et C#.net projekt jeg arbejder med valgte jeg JET databasen (den der er bag ved access) da jeg ikke ville forlange folk skulle downloade hele MSDE'en (fri udgave af mssql) når de ville bruge mit program.

#35 #39 #44 hmm vil det sige at MSSQL idag kun understøtter T-SQL eller?
Jeg mener at erindre at det er ret længe siden at postgresql byggede java C og perl ind i deres database som procedural sprog.
Postgresql er vist et helt okey produkt også til komplicerede database-opgaver, og de har vist også lavet en optimeret provider til .Net.

Generelt er MS vel godt igang med at sementere windows server som en samlet løsning, altså enten fuld MS-pakke eller slet ingen MS software

Angående platforms uafængihed ned .net så er jeg meget tvilende på om mono eller andet virkeligt vil kunne gøre det fuldt ud.
Jeg kan ikke se hvor MS skulle "gvie" andre platforme den fordel at kunne køre windows programmer. Det er simpelhen for godt til at være sandt. MS må have et es i ærmet. Hvis det i fremtiden bliver sådan, at "alle" programmer skrevet til Windows kan køre på Linux så har MS da virkelig skudt sig selv i foden.
Er der nogen der kender MS es'et ?

#53

Nu er det selvfølgelig ikke uden problemer at få et program oprindelig udviklet til Microsofts .Net Framework til at køre under Mono. F.eks. er System.Windows.Forms ikke fuldt understøttet plus andre windows-specifikke ting. Det kan der dog rådes bod på, men det kræver at man fra starten har gjort sig klart om ens program også skal kunne køre under Mono. F.eks. vil man så vælge at bruge GTK# istedet for System.Windows.Forms plus at man skal holde sig fra bestemte namespaces og klasser i .Net. En anden typisk fejl er at folk hardcoder tegnet \ som seperator i paths fremfor at bruge System.IO.Path.DirectorySeparatorChar som så vil returnere det tegn der er gældende på den platform programmet kører under.

http://wiki.sharpdev.dk/index.php/Udvikling_af_pla...

Som med Java er det generelt hurtigere at kode, og dermed kan man spare tid. Så når man nu alligevel skal opgradere, så kan man jo ligesågodt gøre det til .NET.

Det vil nu ikke være min holdning, men jeg er også udpræget C++ fanboy....(og hvis nogen kalder managed C++ for C++ skal jeg komme efter dem!!).

#50 Jeg siger ikke, at MSSQL er hurtigere end MySQL, Oracle eller noget andet. Det jeg siger, er, at MSSQL formentlig er hurtigere i .net (grundet den optimerede provider) end MSSQL er i SML, COBOL eller hvad ved jeg (da de ikke har samme provider).

#51 Jeg har ikke afprøvet MSSQL i .net og MSSQL i eksempelvis Delphi og så sammenlignet hastigheder, hvilket ville teste min udtalelse. Iøvrigt se hvad jeg har skrevet til #50.

Iøvrigt; med hensyn til MSDE, så er jeg enig. Det virker ikke til at være ligeså let at meddistribuere som eksempelvis BDE i Delphi.

"Det er dog ikke kun lyserøde skyer. Jeg har læst store dele af .Net Frameworkets sourcecode igennem, og her er det tydeligt at se at MS har måtte gå på kompromis for at få et så flot API som de har. Utrolig mange klasser og wrappere omkring Win32-kald er lavet internal og ser ikke altid lige pæne ud. Der er også mange klasser som man kunne ønske sig ikke var sealed, men hvis man kigger nærmere på dem er de internt et virvar, og så forstår man pludselig hvorfor man helst ikke skal prøve på at udvide dem."

Det er gjort for at optimere performance, så et rent virvar er det nu ikke, og også derfor .net har en fordel i forhold til java hvad det angår

Hvad er forskellen på en stigning i procent og en stigning i procentpoints?

#58 thure:
Hvis du har 20 %, og det så stiger 10 procentpoint, så giver det 30 %.
Hvis du derimod har 20 %, og det så stiger 10 %, så giver det 22 %.

En procentuel ændring er altså relativ, hvor procentpoint er den absolutte tilvækst.

#43 (regner med du mente 38)

Nej, .Net API'et er ikke en wrapper omkring MFC, men omkring Win32.

Vi kan da godt blive pedantisk, men en stor del af MFC er jo netop en wrapper omkring win32. (der er oxo dele af MFC som er convenience klasser som intet med win32 har at gøre)

Og hvorfor det skal få høvl for det kan jeg ikke forstå. Hvordan i alverden vil folk ellers have at det skal laves?

Fordi man har en bunke lort (ja, win32 er virkeligt et ringe api, hvis man har prøvet BeOS eller Cocoa) er det jo ikke ensbetydende med at man ikke kan lave det om! Det var jo netop en oplagt chance for at rydte op. Sun kunne jo godt gøre det, 3 (!) gange med Java ... (først shared codebase i 1.4 mener jeg).

så de ting der ikke kan implementeres direkte i .Net eller CLR'en må gå igennem Win32.

Korrekt, problemet er netop bare at en del af API'et bare er en wrapper, i stedet for en *ren* implementation i .NET.
Microsoft har gerne ville nå hurtigt til mål, derfor har de wrappet deres eksisterende api's i .net objekter - al ære og respekt for at de har gjort det, og sparet en masse resourcer. Men set fra min vinkel virker det ret selvmodsigende.

Hvis de ville have lavet .NET *ordenligt* havde de jo defineret et HAL og så implementeret .NET oven på den HAL. Men det ville nok gøre det for let for folk der gerne vil implementere CLR/IL (.NET) ;) Så kunne mono folkene jo være færdig på 6 måndeder!

Det var jo det der var relativt fedt med Swing (om man kan lide det api eller ej ønsker jeg ikke at blande ind i diskussionen), det virkede på day one på alle VM's der havde en eksisterende AWT implementation.

.NET's afhængighed af win32 holder ikke i længden - det giver for mange problemer med at holde hele korthuset sammen (IMO) (bare bemærk inkompatibilitets problemer mellem 1.0, 1.1 og 2.0).