.NET
Colin Fahey
1. Definisjon av .NET
Begrepet ".NET" refererer til følgende samling av teknologier:
(1) Framework Class Library (FCL)
(2) Intermediate Language (IL)
(3) Common Language Runtime (CLR)
1.1 Framework Class Library (FCL)
Den Framework Class Library (FCL) er et omfattende sett av klasser for å støtte:
* Beholdere (Array, String, List, ...)
* Flertrådkjøring (tråder, thread pools)
* Nettverksbygging (sockets, protokoller, klienter, servere)
* Fil-operasjoner
* Datastrømmer
* Analyse (regulære uttrykk, XML håndtering)
* Matematiske operasjoner
* Unntak håndtering
* Språk funksjoner (refleksjon, stabel spor, dynamisk kode)
Den Framework Class Library (FCL) er implementert i mange forskjellige plattformer ( Windows, Linux, MacOS, ... ).
Et enkelt program som bruker Framework Class Library (FCL) kan bygges uten betydelige kunnskaper om forskjellene mellom Målplattformer.
Den Framework Class Library (FCL) inneholder nyttige modeller av grunnleggende begreper i datavitenskap (for eksempel "tråd, Socket, drift," osv.).
I en forstand, Framework Class Library (FCL) gir hver støttet operativsystem et moderne, høyt nivå, i samsvar Programming Interface.
Den Framework Class Library (FCL) er en av de mest avanserte, omfattende, jevnt-designet, godt dokumentert samlinger av funksjoner og data som er tilgjengelig for programmerere.
Dessverre følgende multimedia aspekter er ikke en del av Framework Class Library (FCL): audio opptak, audio-, video-opptak, videoavspilling, 3D-rendring, joystick inngang, enhet kontroll ( CD/DVD, ... ), etc.
Microsoft har en .NET versjon av DirectX bibliotekene for sine Windows operativsystemet.
Det er C# wrappers for OpenGL, OpenAL, GLUT, SDL, osv., men dette er ikke fullt så praktisk å ha slike multimedia funksjoner være inkludert i kjernen Framework Class Library (FCL) og inkluderes i sluttbrukeren "Run-time" biblioteker.
Et av problemene med å utvikle programmer som bruker spesielle biblioteker er at de er ment satt av sluttbrukere vil kreve støtte for den valgte biblioteker.
Hvis det ikke er praktisk å laste ned og installere nødvendige biblioteker, en sluttbruker kan velge å ikke bruke et program som krever disse bibliotekene.
En sluttbruker kan også være uvillige til å vente på et bibliotek for å laste ned fra ett sted.
Hvis et program utvikler krever en sluttbruker å finne, hente, og installere biblioteker, uten hjelp fra et bestemt program, og sluttbruker kan velge å ikke bruke programmet.
For eksempel, mange åpen kildekode-prosjekter krever slutt-brukere å finne, laste ned og installere mange ulike biblioteker fra andre open-source prosjekter (eksempler: openssl, zlib, libpng, libjpg, glut, ...), som er tid - forbruk, komplisert, frustrerende, og kan resultere i ende-brukere velge å søke etter alternative programmer eller produkter.
Den "Windows Update" tjenesten tilsynelatende bidrar til å distribuere versjon 1.1 av .NET Run-time biblioteker for å Windows brukere.
Disse kjøre-time biblioteker er inkludert med Windows XP operativsystemet.
Derfor oppretter Windows programmer som krever .NET 1.1 virker helt rimelig.
Also, the run-time biblioteker for Microsoft's implementeringer av .NET Framework Class Library (FCL) kan fritt distribueres, slik at utviklere kan levere disse bibliotekene til sluttbrukere som ikke allerede har bibliotekene.
Den Windows Vista operativsystemet leveres med .NET 3.0 Run-time biblioteker (en kombinasjon av .NET Framework Class Libraries og flere nye biblioteker som "Windows Presentation Foundation" (WPF)).
Derfor distribusjon .NET 2.0 og .NET 3.0 programmer for Windows Vista ikke krever at montører for .NET Run-time biblioteker.
1.2 Intermediate Language (IL)
Den Intermediate Language (IL) er et lite sett med enkle, prosessor-uavhengig, operativsystemspesifikke uavhengig instruksjoner som er tilstrekkelig for å uttrykke data strukturer og funksjoner av mange forskjellige høy-nivå programmeringsspråk ( C++, C#, F#, Visual Basic, Java, Ocaml, ... ).
Kildekoden er skrevet i et høy-nivå språk kan kompileres ned til en tilsvarende "Intermediate Language" form.
Kode i en "Intermediate Language" form kan lett bli kombinert med annen kode i en "Intermediate Language" form.
Et dataprogram (også kalt "programvare)" kan inkludere kildekoden er skrevet på flere forskjellige høy-nivå språk (for eksempel C#, C++, og Visual Basic).
Alle kildekoden kan være sammensatt (konverteres) til en "Intermediate Language" format for å gi enkel å kombinere med andre kompilert kode.
Programmer i en "Intermediate Language" er vanligvis konvertert til maskin-instruksjoner (f.eks CPU instruksjoner) svært kort tid før kjøring (f.eks "Just-In-Time" (JIT) konvertering av IL til CPU instruksjoner).
Men et program kan også være utført i sammenheng med en Virtual Machine (VM) utformet for å tolke Intermediate Language (IL) instruksjoner.
Koden er skrevet i forskjellige høy-nivå språk ( C#, F#, Ocaml, C++, Visual Basic, ... ), kan være sammensatt for Intermediate Language (IL) form ved hjelp av en passende kompilatoren på alle støttede plattformer ( Windows, Linux, MacOS X, ... ), og den resulterende filen, med innebygd Intermediate Language (IL) koden, er plattform-uavhengig og kan kjøres på alle plattformer å ha en gjennomføring av .NET Common Language Runtime (CLR).
Den Intermediate Language (IL) kode generert av kompilatoren er i hovedsak uavhengig av plattform som kompilatoren ble etterkommet.
1.3 Common Language Runtime (CLR)
Den Common Language Runtime (CLR) er mekanismen er ansvarlig for gjennomføring av kode sendt i Intermediate Language (IL) form.
Den Common Language Runtime (CLR) tilbyr ulike tjenester.
Den Common Language Runtime (CLR) mai konvertere Intermediate Language (IL) koden til instruksjonene som er innfødt til plattform (for eksempel CPU instruksjoner).
Konverteringen fra Intermediate Language (IL) til plattform-spesifikk (for eksempel CPU-spesifikke) instruksjonene kan skje i forkant av eventuell kjøring (dvs. en "Ahead-Of-Time" (AOT) konvertering), eller kan skje gradvis, som programmet utfører (dvs. "Just-In-Time" (JIT) konvertering) .
Den Just-In-Time (JIT) konvertering kan bruke utvikling statistikk om programmet kjøres for dynamisk optimalisere konvertert kode (eksempel: identifisering ofte brukte looper og grener, og optimalisere dem i henhold til observert atferd (som seg selv, avhenger av gjeldende data og hendelser)).
Den Common Language Runtime (CLR) styrer allokert minne på vegne av programmet.
Derfor er CLR sikrer at programmet ikke mislykkes i å få tilgang allokert minne mens referanser til slike minne vedvarer, og sikrer at minnet bevilgninger er kansellert, og at minnet er gjort tilgjengelig igjen for fremtidige tildelinger etter at programmet disposes av alle referanser til slike bevilgninger .
Den Common Language Runtime (CLR) oppdager når programmet ikke lenger har en referanse til en hukommelse tildeling og minne allokering er merket for deallocation.
Den Common Language Runtime (CLR) bruker noen av en rekke "søppelrydding" algoritmer (eksempel: "mark-and-sweep") for å identifisere og tørrlegge minne blokker ikke lenger tilgjengelig for et program.
Den Common Language Runtime (CLR) håndterer programmet unntak.
Den Common Language Runtime (CLR) håndhever sikkerhetspolitikk.
Den Common Language Runtime (CLR) bruker "P/Invoke" mekanisme for å laste plattform-spesifikk biblioteker og påkalle (ring) funksjoner innen disse bibliotekene.
2. .NET ( FCL, IL, CLR ) implementeringer av Microsoft
2.1 Innledning
Den .NET paradigmet ( FCL, IL, CLR ) har blitt gjennomført av Microsoft.
Den nyeste versjonen, "3.0", ble utgitt i 2006.10.
.NET 3.0 består av .NET 2.0 Framework Class Libraries og flere nye biblioteker, for eksempel "Windows Presentation Foundation" (WPF) tilknyttet "Silverlight" (tidligere WPF/E, tidligere Sparkle, ...) nettleser-plugin-modulen for Firefox og Internet Explorer.
Microsoft deler .NET 2.0 programvare i to forskjellige pakker:
(1) .NET Framework Version 2.0 Redistributable Package
Den Redistributable Package kreves av sluttbrukere til å kjøre programmer bygd for .NET paradigmet. Denne pakken må også være installert av utviklerne før du installerer og bruker .NET Software Development Kit (SDK) nevnt nedenfor.
(2) .NET Framework Version 2.0 Software Development Kit
Programvaren utviklingspakke (SDK) kreves av utviklerne til å kompilere C# kildekoden til Intermediate Language (IL) program filer.
Denne pakken inneholder ulike utviklingsverktøy og dokumentasjon.
2.2 .NET Framework Version 2.0 Redistributable Package
Den Redistributable Package kreves av sluttbrukere til å kjøre programmer bygd for .NET paradigmet.
Denne pakken må også være installert av utviklerne før du installerer og bruker .NET Software Development Kit (SDK) nevnt nedenfor.
Følgende Internett-siden er den viktigste .NET laste ned siden:
Den delen som heter ".NET Framework Version 2.0 Redistributable Package" har lenker til tre maskinvare plattformer: "Download x86 version", "Download x64 version", "Download IA64 version".
For eksempel følgende koblingen "Download x86 version", fører til en side som heter "Microsoft .NET Framework Version 2.0 Redistributable Package (x86)"
(Filnavn: dotnetfx.exe; Version: RC1; Utgivelsesdato: 3/22/2006; Språk: Norsk; Nedlastingsstørrelse: 22.4 MB)
Lokalt hurtigbufrede versjonen (kun for referanse; potensielt utdatert):
(Filnavnet er blitt endret her fra den opprinnelige filnavnet til "dotnetfx.exe" å unngå forvirrende den med versjonen 1.1 installasjonsprogrammet også kalt "dotnetfx.exe".)
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
Programvaren utviklingspakke (SDK) kreves av utviklerne til å kompilere C# kildekoden til Intermediate Language (IL) program filer.
Denne pakken inneholder ulike utviklingsverktøy og dokumentasjon.
Følgende Internett-siden er den viktigste .NET laste ned siden:
Den delen som heter ".NET Framework Version 2.0 Software Development Kit" har lenker til tre maskinvare plattformer: "Download x86 version", "Download x64 version", "Download IA64 version".
For eksempel følgende koblingen "Download x86 version", fører til en side som heter ".NET Framework 2.0 Software Development Kit (SDK) (x86)"
(Filnavn: setup.exe; Version: 2.0; Utgivelsesdato: 11/7/2005; Språk: Norsk; Nedlastingsstørrelse: 354.0 MB)
Lokalt hurtigbufrede versjonen (kun for referanse; potensielt utdatert):
(Filnavnet er blitt endret her fra den opprinnelige filnavnet til "setup.exe" å unngå forvirrende med alle andre installasjonsfilene navnet "setup.exe".)
3. Microsoft Visual C#: en Integrated Development Environment (IDE) programmet
3.1 Innledning
En Integrated Development Environment (IDE) programmet gjør det mulig for en utvikler å redigere kildekoden og utføre ulike verktøy (eksempler: compiler, debugger, ...) innen rammen av en enkelt, samlende programmet, fylt med nyttige visuelle indikasjoner og kontroller.
"Microsoft Visual C# 2005 Express Edition" er en ikke-pris (ingen betaling kreves) IDE tilgjengelig for nedlasting fra Microsoft.
For ikke-database utvikling, det er nesten umulig å skille dette gratis produkt fra detaljhandel motstykke, "Microsoft Visual C# 2005".
Jeg bruker ofte begge produktene, profesjonelt og recreationally, og jeg har ennå ikke merke noen praktisk forskjell mellom produktene.
3.2 Offisielle linker
Internett-området hovedsiden:
Siden om "Visual C# Express Edition":
Klikk "Download Now" knappen på høyre side av siden til å velge en nedlasting.
(En metode er å starte et installasjonsprogram program som laster ned filer fra Microsoft under hver installasjon.
En annen metode er å laste ned en full CD-ROM "ISO" bilde, som gjør at fremtiden offline installasjon.
Den ISO bilde, "VCS.iso" (451,837,952 bytes; CRC 55884F2C) for 32-bits x86 engelsk, kan være brent til en CD-ROM hjelp "Nero 7 Ultra", for eksempel. )
4. .NET ( FCL, IL, CLR ) gjennomføring av Mono Project
4.1 Innledning
Den .NET paradigmet ( FCL, IL, CLR ) har blitt gjennomført av deltakerne i en gruppe kjent som Mono Project.
4.2 Offisielle linker
Project site:
Software Download side:
4.3 Lokalt hurtigbufret versjon
Lokalt hurtigbufrede versjonen av installasjonsprogrammet (kun for referanse; potensielt utdatert):
4.4 .NET 2.0 utvikling med Mono
Den "mcs" kompilatoren, og dokumentasjonen, som i november 2006, hovedsakelig relatert til C# 1.0 og FCL 1.1.
Men det "mcs" kompilatoren er i stand til å kompilere C# 2.0 kode som ikke inneholder generisk eller generiske-baserte funksjoner, men begrenser API til 1.0.
For å gjøre full C# 2.0 utvikling, med FCL 2.0 bibliotekene, bruker "gmcs" kompilatoren.
Se følgende side på Mono nettstedet:
5. SharpDevelop: en åpen-kilde Integrated Development Environment (IDE) programmet
5.1 Innledning
En Integrated Development Environment (IDE) programmet kan en utvikler til å redigere kildekoden og utføre ulike verktøy (eksempler: compiler, debugger, ...) innen rammen av en enkelt, samlende programmet, fylt med nyttige visuelle indikasjoner og kontroller.
SharpDevelop er en utmerket, open-source IDE program for C# / .NET utvikling.
Dette IDE tett ligner Microsoft Visual C# IDE, og i noen henseender, SharpDevelop IDE har økt på Microsoft produktet.
Men Microsoft Visual C# har noen funksjoner (for eksempel feilretting) at SharpDevelop programmet ikke har (på tidspunktet for dette skriftlig).
5.2 Offisielle linker
Den enkle Internett-området hovedsiden:
Siden om "The Open Source Development Environment for .NET":
Nedlastingen side, som har mer informasjon om 1.1 og 2.0 versjoner av SharpDevelop:
5.3 Lokalt hurtigbufret versjon
Lokalt hurtigbufrede versjonen av installasjonsprogrammet (kun for referanse; potensielt utdatert):
6. Nyttige C# / .NET / IL verktøy
6.1 SciTech Software ".NET Memory Profiler"
Dette Profiler viser minne bevilgninger og andre ressurser bevilgninger, som en sammensatt .NET program eller montering gjør mens utføring.
The real-time diagrammet gjør en person til å se i detalj hvordan handlinger av programmet (for eksempel handlinger som utløses av brukerundersøkelser eller andre hendelser) påvirker hukommelse tildeling og søppelrydding.
The real-time tabellen oppføringen vise til at en person til å lære mer om minne bevilgninger.
Dette Profiler raskt og dramatisk, avdekket wasteful minne bruk i sanntid Direct3D programmet jeg hadde utviklet.
Et mønster av oppadgående ramper og plutselig synker (på grunn av "søppelrydding)" i minnebruken grafer passet perfekt med jevne mellomrom, very-kort pause i 3D-tegning av programmet.
Den Profiler aktivert meg å oppdage at hyppige tildeling av midlertidige gjenstander ble accumulating mye minne, utløser søppelrydding ofte, og tar nok tid for hver søppelrydding til å forårsake noen tegning perioder å være savnet.
Den Profilers sanntid tabellen av allokert objekt typer avdekket hvilke typer objekter som forbrukes mest minne, og hvilke bevilgninger som minnet på den høyeste satsen (byte per sekund), og hvilke bevilgninger hadde den høyeste satsen disposisjon.
Studere real-time grafer, og sanntids-tabeller, for meg å fokusere på å studere hvordan visse typer data ble brukt i koden.
Endre kode for å unngå hyppige tildelinger av midlertidige objekter kan i stor grad redusere den generelle satsen minne tildeling og disponering, og kan derfor redusere hyppigheten av søppelrydding utløser.
(Jeg tror "Bytes/sec" er en svært avslørende statistikken i sanntid minne bruk, i tillegg til "Live instances".
) Ser du alle disse blir oppdatert svært raskt i en tabell, og være i stand til å velge hvor radene er sortert, og endre sortering parameter når som helst, gjør opplevelsen av å studere en real-time-programmet meget engasjerende og informativ.
Minne tildeling svar på brukerens interaksjon med en kjører programmet kan studeres, og testing kan raskt tilpasse seg de tilbakemeldinger for å innskrenke den mest interessante aspekt.
(For eksempel, 2006 July versjonen hadde følgende attributter: versjon 2.6.89; 4.3 MB; USA $127.00; Last ned 14-dagers-grense versjon, og ikke pris, for evaluering.)
6.2 FxCop: .NET koden analysator / kritiker
FxCop analyserer en sammensatt .NET program (eller sammensatt forsamling) og genererer en rapport oppføringen mulige problemer med den opprinnelige kildekoden.
Mulige resultater problemer og sikkerhetsproblemer blir identifisert.
Mulige koding konvensjonen brudd er identifisert.
FxCop ikke krever tilgang til den originale kildekoden til å utføre analysen.
Bare de kompilerte .NET programmet (som inneholder IL) er påkrevd.
Likevel, FxCop rapporten gir hyperkoblinger til bestemte linje tallene i den opprinnelige kildekoden.
Hvis Microsoft Visual C# 2005 IDE er aktiv, kan du klikke på hyperkoblingen i FxCop rapporten vil føre til at IDE å deformere til relevante kilde filen og linjenummer.
FxCop har, etter min mening, en heller vanskelig måte å integrere med Microsoft Visual C# 2005 IDE.
Men når det er satt opp, FxCop produserer et svært interessant og potensielt verdifulle-rapporten.
Rapporten inneholder detaljerte råd om hvordan du kan forbedre den opprinnelige kildekoden.
Jeg tror det er verdt å analysere et program ved hjelp FxCop med jevne mellomrom.
Jeg ville ikke bli overrasket hvis noen programvareutvikling prosjekter eller virksomheter som kreves all kode skrevet av utviklere for å gi ingen advarsler eller kritikk av FxCop.
Regler kan legges til eller fjernes fra FxCop databasen, i henhold til behov.
FxCop er en åpen kilde, gratis program.
6.3 "Reflector for .NET": decompiler / analysator
Fra Lutz Roeder's Internet site:
"Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."
"Reflector" kan hjelpe en person studere hvordan tredjeparts biblioteker er skrevet.
Noen ganger vil det være svært nyttig å vite nøyaktig hvordan en metode i en forsamling er gjennomført.
Hvis en metode som oppfører seg på en uventet eller mystisk måte, deretter "Reflector" kan brukes til å se gjennomføringen.
Ved å se gjennomføringen, programmerer kan omgå problemene forårsaket av spesifikke implementeringer av biblioteket metoder.
En venn fortalte meg at "Reflector" hjulpet ham lære mer om atferden til dårlig dokumentert metoder i Microsoft gjennomføring av Framework Class Libraries (FCL).
"Reflector" kan være nyttig når dokumentasjon for et bibliotek-metoden består av bare noen få ord, for eksempel "setter verdien" eller "hendelseshåndterer."
Hvis et bibliotek funksjon anvendelsen er ikke av en ukjent årsak (når alle parametere synes gyldig), deretter bruke "Reflector" å se på gjennomføringen av biblioteket funksjon kan avdekke årsaken til svikten.
"Reflector" utfører noen "reverse engineering" av en .NET program eller montering.
Andre verktøy, muligens inkludert "Reflector" seg selv, kan gi kildekoden til programmer eller samlinger bygget basert på uklar kildekoden.
Dette er åpenbart en kilde til bekymring for noen utviklere og investorer.
(2006 July: Reflector.zip ble versjon 4.2.45.0)
7. Internett diskusjonsfora
Google søking er den beste måten å finne svar på konkrete spørsmål på et hvilket som helst emne, men nettstedene nedenfor gjentatte ganger vises i søkeresultatene for C# og .NET spørsmål.
Webområdene nedenfor er kjempeflott for å utforske de mange praktiske ting folk har gjort med C# og .NET.
"The Code Project" området har tusenvis av interessante og nyttige artikler, for C#, C++ og andre språk og programmering paradigmer.
Den "MSDN Code Gallery" området har mange interessante artikler og kodeeksempler relatert til Microsoft teknologier.
Andre nettsteder relatert til C# og .NET:
8. Generelle merknader
8.1 Plattform uavhengighet
Den Intermediate Language (IL), som Java "byte-koden," er plattform uavhengig.
Eventuelle .NET-kompatibel kompilatoren vil generere plattform uavhengig Intermediate Language (IL) koden for å danne programmer eller samlinger.
Programmer pakket som kjørbare filer ("*.exe" filer) må ha noen plattform-avhengig kode er spesifikke for et operativsystem, for det formål å være riktig tolket og lansert som kjørbar programvare i sammenheng med det aktuelle operativsystemet.
Men det innfødt kjørbare delen av programvaren filen bare tjener til å påkalle den .NET CLR motoren, melder IL koden inneholdt innen programvare for kjøring av CLR motor.
Microsoft tilbyr en gjennomføring av .NET utilities (kompilatoren, ...), og en gjennomføring av Framework Class Library (FCL), bare for Windows operativsystemet.
Den Mono Project tilbyr implementeringer av .NET utilities (kompilatoren, ...), og implementeringer av Framework Class Library (FCL), for følgende operativsystemer: Windows, Linux, MacOS X, og BSD.
8.2 Speed sammenlignet med non-CLR C / C++
Den Common Language Runtime (CLR) aspekt av .NET er den sammenheng der en C# programmet utfører.
Den CLR utfører "søppelrydding" og gjør det mulig for programmer å bruke funksjoner i "uovervåkede" bibliotekene (alle bibliotekene ikke implementert i Intermediate Language (IL)).
Enhver funksjon det ikke mer enn ren matematikk, ren streng manipulasjon, eller ren minne kopiering, vil påkalle funksjoner i "uovervåkede" biblioteker.
Alle fil-operasjoner, Socket operasjoner, tegning, inngang operasjoner (mus, tastatur), produksjon operasjoner (konsoll), plattform tråden operasjoner, presisjon og tidsstyring, vindussystem operasjoner, osv., vil påkalle funksjoner i "uovervåkede biblioteker."
Dessverre, mekanisme påkalle "uovervåkede" funksjoner fra CLR krever en betydelig mengde tid.
Derfor, den generelle hastigheten til et program kjøres i sammenheng med den CLR er noticably tregere enn et program som kan påkalle "uovervåkede" funksjonene direkte.
For enkelte typer programvare, hastighet kan være viktig.
For enkelte typer programvare, hastighet kan gjøre en viktig forskjell i den subjektive eller psykologisk opplevelse av en person ved hjelp av programvare.
For enkelte typer programvare, hastighet kan gjøre forskjellen mellom å oppnå et mål og fiasko.
Flertrådkjøring, økende CPU hastigheter, og forbedringer i CLR koden genererer anlegget, vil hjelpe programvare kjøres i sammenheng med den CLR kjøre raskere.
Men noen kode som kjører utenfor CLR, og påkaller plattform bibliotekene direkte, vil nødvendigvis kjøre betydelig raskere enn programvaren som utfører innen rammen av CLR.
Den forsikringer gjort av CLR til C# programvare, for eksempel trygt å bygge bro over gapet mellom forvaltet kode og uovervåkede koden, kommer til en kostnad som er lite sannsynlig vil bli redusert.
Derfor kan et hvilket som helst program som er veldig plattform intensiv (eksempler: 3D-simulering eller spillet, fil-prosessor, nettverks-server, etc) er sannsynligvis til å gjennomføre en bestilling av omfanget raskere utenfor CLR enn når etterkommet innen CLR.
Forskjellen er enorm.
Også et hvilket som helst program som utfører en betydelig mengde lavt nivå manipulasjon av data skal utføres betydelig raskere utenfor CLR enn innenfor CLR.
Programmer starter i sammenheng med den CLR utføres raskt nok til å være nyttig for mange praktiske formål.
Som CPU hastigheter øke, og som koden tar bedre nytte av flere CPUs, programmer kjøres i sammenheng med den CLR vil kunne bli brukt til flere oppgaver som krever en høy grad av beregningsprosessen.
Men i midten av 2008 den CLR er fortsatt ikke aktuelle for 3D-spill av noe raffinement, med mindre en svært aggressiv innsats er gjort for å redusere antall funksjon samtaler til 3D-biblioteket (OpenGL eller Direct3D), eventuelt ved hjelp av begreper som for eksempel "shader programmer" og "vise lister;" noe for å redusere antall funksjon samtaler.
