.NET
Colin Fahey
1. Definition av .NET
Termen ”.NET” hänvisar till följande samling av teknik:
(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) är en omfattande uppsättning klasser till stöd:
* Containrar (Array, String, List, ...)
* Multitrådning (trådar, tråd pooler)
* Nätverk (sockets, protokoll, klienter, servrar)
* Fil operationer
* Dataströmmar
* Parsning (reguljära uttryck, XML hantering)
* Math operationer
* Undantagshantering
* Språkfunktioner (eftertanke, stack trace, dynamisk kod)
Den Framework Class Library (FCL) genomförs för många olika plattformar ( Windows, Linux, MacOS, ... ).
Alltså, ett enda program som använder Framework Class Library (FCL) kan utvecklas utan större kunskaper om skillnader mellan Målplattformar.
Den Framework Class Library (FCL) innehåller användbara modeller av grundläggande begrepp inom datalogi (t.ex. ”tråd, socket, ström,” etc).
På sätt och vis är Framework Class Library (FCL) ger varje operativsystem som stöds en modern, hög nivå, konsekvent programmeringsgränssnitt.
Den Framework Class Library (FCL) är en av de mest avancerade, övergripande, enhetligt utformade, väldokumenterade samlingar av funktioner och datatyper tillgängliga för programmerare.
Tyvärr följande multimedia aspekter är inte en del av Framework Class Library (FCL): ljudinspelning, ljuduppspelning, videoinspelning, videouppspelning, 3D-rendering, joystick, ingång enheten kontroll ( CD/DVD, ... ), etc.
Microsoft har en .NET version av DirectX bibliotek för deras Windows operativsystemet.
Det finns C# omslag för OpenGL, OpenAL, GLUT, SDL, osv, men det är inte riktigt lika bekvämt som att ha sådana multimedia funktioner skall ingå i den centrala Framework Class Library (FCL) och ingår i slutanvändarnas ”run-time” bibliotek.
Ett av problemen med att utveckla program som utnyttjar särskilt bibliotek är att de är avsedda som slutanvändare kommer att kräva stöd för det valda bibliotek.
Om det inte är praktiskt att ladda ner och installera nödvändiga bibliotek, en slutanvändare kan välja att inte använda ett program som kräver dessa bibliotek.
En slutanvändare kan också vara ovilliga att vänta på ett bibliotek att hämta från en online-läge.
Om ett program utvecklare kräver en slutanvändare att hitta, köpa och installera bibliotek, alla utan stöd från ett visst program, så att slutanvändaren kan välja att inte använda programmet.
Exempelvis många open-source-projekt kräver slutanvändare att hitta, ladda ner och installera, många olika bibliotek från andra öppen-källkods-projekt (exempel: openssl, zlib, libpng, libjpg, glut, ...), vilket är dags i anspråk, komplicerade, frustrerande och kan leda till slutanvändare välja att söka efter alternativa program eller produkter.
Den ”Windows Update” tjänst uppenbarligen hjälper distribuera version 1.1 av .NET runtime-bibliotek för att Windows användare.
Dessa run time-biblioteken ingår i Windows XP operativsystemet.
Därför skapar Windows program som kräver .NET 1.1 verkar helt rimligt.
Also, the run-time bibliotek för Microsoft's implementeringar av .NET Framework Class Library (FCL) får fritt omfördelas, så att utvecklarna kan leverera dessa bibliotek till slutanvändare som inte redan har biblioteken.
Den Windows Vista operativsystem fartyg med .NET 3.0 run-time bibliotek (en kombination av de .NET Framework Class Libraries och flera nya bibliotek såsom ”Windows Presentation Foundation” (WPF)).
Därför driftsättning .NET 2.0 och .NET 3.0 program för Windows Vista inte kräver installatörer för .NET run-time bibliotek.
1.2 Intermediate Language (IL)
Den Intermediate Language (IL) är en liten samling enkla, processor-oberoende, operativ-system, oberoende instruktioner som är tillräckliga för att helt uttrycka datastrukturer och funktioner av flera olika hög nivå programspråk ( C++, C#, F#, Visual Basic, Java, Ocaml, ... ).
Källkod skriven i ett högnivåspråk som kan sammanställas till en motsvarande ”Intermediate Language” form.
Kod i en ”Intermediate Language” form lätt kan kombineras med annan kod på ett ”Intermediate Language” form.
Ett datorprogram (även kallat ”software)” kan innehålla källkod skriven i flera olika hög nivå språk (eg, C#, C++ och Visual Basic).
All källkod kan kompileras (konverteras) till en ”Intermediate Language” format för att tillåta lätt att kombinera med andra sammanställas kod.
Program i ett ”Intermediate Language” form brukar omvandlas till maskin-specifika instruktioner (t.ex. CPU instruktioner) mycket kort före avrättningen (t.ex. ”Just-In-Time” (JIT) omställning av IL att CPU instruktioner).
Men ett program får också genomföras i samband med en Virtual Machine (VM) att tolka Intermediate Language (IL) instruktioner.
Kod skriven i olika hög nivå språk ( C#, F#, Ocaml, C++, Visual Basic, ... ), kan sammanställas till Intermediate Language (IL) form med lämplig kompilator på någon stöds plattform ( Windows, Linux, MacOS X, ... ), och den resulterande filen med inbäddade Intermediate Language (IL) kod, är plattforms-oberoende och kan köras på alla plattformar med en genomförandet av .NET Common Language Runtime (CLR).
Den Intermediate Language (IL) kod som genereras av kompilatorn är i grunden oberoende av den plattform på vilken kompilator avrättades.
1.3 Common Language Runtime (CLR)
Den Common Language Runtime (CLR) är den mekanism som ansvarar för verkställande kod som lämnats i Intermediate Language (IL) form.
Den Common Language Runtime (CLR) erbjuder olika tjänster.
Den Common Language Runtime (CLR) maj konvertera Intermediate Language (IL) kod till instruktioner som är inhemska på plattformen (t.ex. CPU instruktioner).
Omvandlingen från Intermediate Language (IL) till plattformsspecifik (t.ex. CPU-specifika) instruktioner som kan hända i förväg om genomförandet (dvs. en ”Ahead-Of-Time” (AOT) omvandling), eller kan ske gradvis, eftersom programmet utför (dvs ”Just-In-Time” (JIT) omvandling) .
Den Just-In-Time (JIT) konvertering kan använda utvecklas statistik om programmet genomförs dynamiskt optimera konverteras koden (exempel: fastställa ofta används loopar och filialer, och optimerar dem enligt observerade beteende (som i sin tur beror på aktuella uppgifter och evenemang)).
Den Common Language Runtime (CLR) förvaltar tilldelade minne för programmet.
Därför är CLR ser till att programmet inte undgå att tillgången fördelas minne medan hänvisningar till sådana minnet kvarstår, och ser till att minnet anslag annullerats och att minnet återigen görs tillgängliga för framtida tilldelningar efter programmet omhändertar alla hänvisningar till en sådan fördelning .
Den Common Language Runtime (CLR) upptäcker när programmet inte längre har en hänvisning till en minnesallokering, och minnesallokering är märkt för deallocation.
Den Common Language Runtime (CLR) använder något av en mängd olika ”garbage collection” algoritmer (exempel: ”mark-and-sweep”) att identifiera och återvinna minne block inte längre är tillgänglig genom ett program.
Den Common Language Runtime (CLR) hanterar programmet undantag.
Den Common Language Runtime (CLR) verkställer säkerhetspolitik.
Den Common Language Runtime (CLR) använder ”P/Invoke” mekanism för att lastplanet-specifika bibliotek och åberopa (call) funktioner inom dessa bibliotek.
2. .NET ( FCL, IL, CLR ) implementationer av Microsoft
2.1 Inledning
Den .NET paradigm ( FCL, IL, CLR ) har genomförts genom Microsoft.
Den senaste versionen, ”3.0”, släpptes i 2006.10.
.NET 3.0 består av .NET 2.0 Framework Class Libraries och flera nya bibliotek, såsom ”Windows Presentation Foundation” (WPF) samband med ”Silverlight” (tidigare WPF/E, tidigare Sparkle, ...) webbläsare plugg för Firefox och Internet Explorer.
Microsoft delas .NET 2.0 programvara i två olika förpackningar:
(1) .NET Framework Version 2.0 Redistributable Package
Den Redistributable Package krävs av slutanvändarna att exekvera program byggt för .NET paradigm. Detta paket måste även installeras som utvecklare innan du installerar och använder .NET Software Development Kit (SDK) nämns nedan.
(2) .NET Framework Version 2.0 Software Development Kit
Den Software Development Kit (SDK) krävs av utvecklare att sammanställa C# källkoden till Intermediate Language (IL) programfiler.
Detta paket innehåller olika utvecklingsverktyg och dokumentation.
2.2 .NET Framework Version 2.0 Redistributable Package
Den Redistributable Package krävs av slutanvändarna att exekvera program byggt för .NET paradigm.
Detta paket måste även installeras som utvecklare innan du installerar och använder .NET Software Development Kit (SDK) nämns nedan.
Följande Internet sida är den viktigaste .NET hämta sida:
Det avsnitt som heter ”.NET Framework Version 2.0 Redistributable Package” har länkar till tre hårdvara plattformar: ”Download x86 version”, ”Download x64 version”, ”Download IA64 version”.
Till exempel att följa länken ”Download x86 version”, leder till en sida med rubriken ”Microsoft .NET Framework Version 2.0 Redistributable Package (x86)”
(Filnamn: dotnetfx.exe; Version: RC1; Publicerad: 3/22/2006; Språk: engelska, Hämtningsstorlek: 22.4 MB)
Lokalt cachade versionen (endast för referens, eventuellt föråldrade):
(Filnamnet har ändrats hit från det ursprungliga filnamnet på ”dotnetfx.exe” att undvika förväxling med den version 1.1 installeraren heter ”dotnetfx.exe”.)
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
Den Software Development Kit (SDK) krävs av utvecklare att sammanställa C# källkoden till Intermediate Language (IL) programfiler.
Detta paket innehåller olika utvecklingsverktyg och dokumentation.
Följande Internet sida är den viktigaste .NET hämta sida:
Det avsnitt som heter ”.NET Framework Version 2.0 Software Development Kit” har länkar till tre hårdvara plattformar: ”Download x86 version”, ”Download x64 version”, ”Download IA64 version”.
Till exempel att följa länken ”Download x86 version”, leder till en sida med rubriken ”.NET Framework 2.0 Software Development Kit (SDK) (x86)”
(Filnamn: setup.exe; Version: 2.0; Publicerad: 11/7/2005; Språk: engelska, Hämtningsstorlek: 354.0 MB)
Lokalt cachade versionen (endast för referens, eventuellt föråldrade):
(Filnamnet har ändrats hit från det ursprungliga filnamnet på ”setup.exe” att undvika förvirrande det med alla andra installationsfiler som heter ”setup.exe”.)
3. Microsoft Visual C#: en Integrated Development Environment (IDE) program
3.1 Inledning
En Integrated Development Environment (IDE) program möjliggör en utvecklare att redigera källkoden och verkställa olika verktyg (exempel: kompilator, debugger, ...) inom ramen för en enda samlande program, fylld med nyttiga visuella tecken och kontroller.
”Microsoft Visual C# 2005 Express Edition” är en no-kostnad (ingen betalning krävs) IDE tillgänglig för nedladdning från Microsoft.
För icke-databas utveckling är det nästan omöjligt att skilja detta ingen kostnad produkt från detaljhandeln motsvarigheten, ”Microsoft Visual C# 2005”.
Jag som ofta använder både produkter, professionellt och recreationally, och jag har ännu inte märkt någon praktisk skillnad mellan produkterna.
3.2 Officiella länkar
Internet webbplatsens startsida:
Sidan om ”Visual C# Express Edition”:
Klicka på ”Download Now” knappen till höger på sidan att välja en nedladdning alternativet.
(En metod är att starta ett installationsprogram som laddar ner filer från Microsoft under varje anläggning.
En annan metod är att hämta en fullständig CD-ROM ”ISO” bild, vilket möjliggör framtida offline-installation.
Den ISO bild, ”VCS.iso” (451,837,952 bytes; CRC 55884F2C) för 32-bitars x86 engelska, kan brännas till CD-ROM använder ”Nero 7 Ultra”, till exempel. )
4. .NET ( FCL, IL, CLR ) genomförandet av Mono Project
4.1 Inledning
Den .NET paradigm ( FCL, IL, CLR ) har genomförts av deltagarna i en grupp som kallas Mono Project.
4.2 Officiella länkar
Project site:
Ladda ner program sida:
4.3 Lokalt cachad version
Lokalt cachade versionen av installeraren (endast för referens, eventuellt föråldrade):
4.4 .NET 2.0 utveckling med Mono
Den ”mcs” kompilatorn och dokumentation, i november 2006, främst gäller C# 1.0 och FCL 1.1.
Men den ”mcs” kompilator kan kompilera C# 2.0 kod som inte innehåller generika eller generiska-baserade funktioner, men begränsar API att 1.0.
För att göra full C# 2.0 utveckling, med FCL 2.0 bibliotek använder ”gmcs” kompilator.
Se följande sida om Mono site:
5. SharpDevelop: an open-source Integrated Development Environment (IDE) program
5.1 Inledning
En Integrated Development Environment (IDE) program tillåter en utvecklare att redigera källkoden och verkställa olika verktyg (exempel: kompilator, debugger, ...) inom ramen för en enda samlande program, fylld med nyttiga visuella tecken och kontroller.
SharpDevelop är en utmärkt, open-source IDE program för C# / .NET utveckling.
Detta IDE liknar den Microsoft Visual C# IDE, och i vissa avseenden, SharpDevelop IDE har förbättrats på Microsoft produkt.
Men Microsoft Visual C# har vissa funktioner (exempel: debugging) att SharpDevelop programmet inte har (vid tiden för denna skrift).
5.2 Officiella länkar
Den enkla webbplats huvudsidan:
Sidan om ”The Open Source Development Environment for .NET”:
Hämtningen sida, som har detaljer om den 1.1 och 2.0 versioner av SharpDevelop:
5.3 Lokalt cachad version
Lokalt cachade versionen av installeraren (endast för referens, eventuellt föråldrade):
6. Nyttiga C# / .NET / IL verktyg
6.1 SciTech Software ”.NET Memory Profiler”
Detta profiler visar minne anslag och andra resurser anslag för att sammanställas .NET program eller montering gör medan verkställande.
Den realtid diagrammet kan en person att se i detalj hur åtgärderna i programmet (t.ex. insatser som utlöstes av användarens input eller andra evenemang) påverkar minne tilldelningen och garbage collection.
Den realtid tabell med tanke möjliggör en person att lära sig detaljer om minnet anslag.
Detta profiler direkt, och dramatiskt, avslöjade slösaktiga minne användas i realtid Direct3D program jag hade utvecklats.
Ett mönster av uppåtgående ramper och plötsligt droppar (på grund av ”garbage collection)” i minnesanvändning grafer matchas perfekt med regelbundna, mycket-korta pauser i 3D-ritning av mitt program.
De profiler gjort det möjligt för mig att upptäcka att täta tilldelning av tillfälliga objekt var ackumulera en massa minne, utlösande garbage collection ofta, och med tillräckligt med tid för varje garbage collection att orsaka några ritning perioder får missa.
De profiler s realtid tabellen över fördelade objekttyperna avslöjat vilka typer av objekt som konsumeras mest minne, och som anslagen förbrukas minne på högsta ränta (bytes per sekund), vilket anslagen hade den högsta förfogande.
Studera i realtid grafer, och realtid tabeller, gjort det möjligt för mig att fokusera på att studera hur vissa uppgifter typer har använts i min kod.
Ändra kod för att undvika återkommande tilldelningar av tillfälliga objekt kan kraftigt minska den totala graden av minnesallokering och bortskaffande, och kan därmed minska frekvensen av garbage collection utlösande.
(Jag tror ”Bytes/sec” är ett mycket avslöjande statistik för realtids-minne används, förutom ”Live instances”.
) Att se alla dessa uppdateras mycket snabbt i en tabell form, och att kunna välja hur rader sorteras, och ändra sortering parameter när som helst, gör erfarenheter av att studera realtids-programmet mycket engagerande och informativ.
Minnesallokering svar på användarens interaktion med ett körande program kan studeras och provtagningen kan snabbt anpassa sig till den feedback för att minska antalet mest intressanta aspekten.
(Till exempel har 2006 July version hade följande attribut: version 2.6.89; 4.3 MB; USA $127.00; Ladda ner 14-dagars gräns version, utan kostnad, för utvärdering.)
6.2 FxCop: .NET kod analyzer / kritiker
FxCop analyserar ett sammanställas .NET program (eller sammanställts församling) och genererar en rapport notering eventuella problem med den ursprungliga källkoden.
Möjliga prestanda problem och säkerhetsproblem har identifierats.
Möjliga kodning konvention kränkningar är identifierade.
FxCop inte kräver tillgång till den ursprungliga källkoden för att utföra analysen.
Endast sammanställas .NET program (som innehåller IL).
Men det FxCop rapport erbjuder hyperlänkar till specifika radnummer i den ursprungliga källkoden.
Om Microsoft Visual C# 2005 IDE är aktiva, klicka på hyperlänken i FxCop rapport att orsaka att IDE att varpen till relevanta källfilen och radnumret.
FxCop har, enligt min mening, en litet märklig sätt att integrera med Microsoft Visual C# 2005 IDE.
Men när det väl är inrättat, FxCop producerar en mycket intressant och potentiellt-värdefullt betänkande.
Rapporten innehåller detaljerade råd om hur man kan förbättra den ursprungliga källkoden.
Jag tycker det är värt att analysera ett program som använder FxCop på en regelbunden basis.
Jag skulle inte bli förvånad om några mjukvaruutveckling projekt eller verksamheter krävs all kod skriven av utvecklarna att inte ge varningar eller kritik av FxCop.
Regler kan läggas till eller avlägsnas från FxCop databas, enligt behov.
FxCop är ett open-source, gratis program.
6.3 ”Reflector for .NET”: dekompilering / analyzer
Från Lutz Roeder's webbplats:
"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 hjälpa en person som studerar hur tredje part bibliotek är skrivet.
Ibland skulle det vara mycket värdefullt att veta exakt hur en metod i en församling genomförs.
Om en metod som uppträder på ett oväntat eller mystiska sätt, sedan ”Reflector” kan användas för att se genomförandet.
Genom att se genomförandet, programmerare kan lösa problem som orsakas av särskilda implementeringar av biblioteket metoder.
En vän berättade för mig att ”Reflector” hjälpte honom lära sig mer om beteendet hos dåligt dokumenterade metoder i Microsoft genomförandet av Framework Class Libraries (FCL).
”Reflector” kan vara till hjälp när dokumentation för ett bibliotek metoden består av endast ett fåtal ord, såsom ”anges värdet” eller ”händelsehanterare.”
Om ett bibliotek funktion åkallan är ett misslyckande för en okänd anledning (när alla parametrar verkar giltiga), sedan med hjälp ”Reflector” att titta på genomförandet av bibliotekets funktion kan avslöja om orsaken till felet.
”Reflector” utför vissa ”reverse engineering” av en .NET program eller montering.
Andra verktyg, eventuellt inklusive ”Reflector” själv, kan ge källkoden för program eller aggregat byggt baseras på förvrängd källkod.
Detta är naturligtvis en källa till bekymmer för vissa utvecklare och investerare.
(2006 July: Reflector.zip var version 4.2.45.0)
7. Internet diskussionsforum
Google söker är det bästa sättet att hitta svar på konkreta frågor om något ämne, men webbplatserna nedan upprepade gånger visas i sökresultaten för C# och .NET frågor.
Webbplatserna nedan är awesome för att utforska de många coola saker som folk har gjort med C# och .NET.
”The Code Project” webbplats har tusentals intressanta och användbara artiklar, för C#, C++ och andra språk och paradigmer.
Den ”MSDN Code Gallery” webbplats har många intressanta artiklar och kodexempel rör Microsoft teknik.
Andra webbplatser med anknytning till C# och .NET:
8. Allmänna anmärkningar
8.1 Plattform oberoende
Den Intermediate Language (IL), precis Java ”byte koden” är oberoende av plattform.
Varje .NET-kompatibel kompilator kommer att generera plattform oberoende Intermediate Language (IL) kod för att bilda program eller aggregat.
Program förpackat som körbara (”*.exe” filer) måste ha någon plattform är beroende kod är specifika för ett operativsystem, med syftet att tolkas och genomföras så körbara programvaran i samband med särskilt operativsystem.
Men de infödda körbara delen av programvaran filen bara att åberopa .NET CLR motorn, lämna in IL kod som finns inom programvara fil för verkställighet av CLR motorn.
Microsoft erbjuder ett genomförande av .NET utilities (kompilatorn ...), och ett genomförande av Framework Class Library (FCL), bara för Windows operativsystemet.
Den Mono Project erbjuder implementeringar av .NET utilities (kompilatorn ...), och implementationer av Framework Class Library (FCL), för följande operativsystem: Windows, Linux, MacOS X och BSD.
8.2 Speed jämfört med non-CLR C / C++
Den Common Language Runtime (CLR) aspekt av .NET är det sammanhang i vilket ett C# programmet utför.
Den CLR utför ”garbage collection” och gör det möjligt för program att anropa funktioner i ”opåverkad” bibliotek (alla bibliotek inte genomföras i Intermediate Language (IL)).
Varje funktion den har mer än ren matematik, ren string manipulation, eller rent minne kopiering, kommer att anropa funktioner i ”opåverkad” bibliotek.
Alla fil operationer, Socket operationer, ritning operationer, input (mus, tangentbord), output (konsol), plattform thread operationer, precision timer operationer, fönstersystem operationer, etc, kommer att anropa funktioner i ”opåverkad bibliotek.”
Tyvärr kan systemet med åberopande ”opåverkad” funktioner från CLR kräver avsevärd tid.
Det sammantagna hastighet av ett program verkställande inom ramen för CLR är noticably långsammare än ett program som kan åberopa ”opåverkad” funktioner direkt.
För vissa typer av programvara, snabbhet kan vara viktiga.
För vissa typer av programvara, snabbhet kan göra en viktig skillnad i det subjektiva eller psykologiska upplevelse för en person som använder programvaran.
För vissa typer av programvara, snabbhet kan betyda skillnaden mellan att uppnå ett mål och misslyckande.
Multitrådning, öka CPU hastigheter, samt förbättringar av CLR kod produktionsanläggning på, kommer att hjälpa programvara verkställande inom ramen för CLR köra snabbare.
Men någon kod som kör utanför CLR och åberopar plattform bibliotek direkt, kommer oundvikligen att köra betydligt snabbare än den mjukvara som utför inom ramen för den CLR.
De försäkringar som CLR att C# programvara, till exempel säkert att överbrygga klyftan mellan förvaltas kod och opåverkad kod, kommer vid en kostnad som sannolikt inte att sänkas.
Därför kan program som är mycket plattform intensiva (exempel: 3D-simulering och spel, fil-processor, nätverksserver, etc) kommer sannolikt att utföra en order storleksordning snabbare utanför CLR än när avrättas inom CLR.
Skillnaden är enorm.
Dessutom kan program som utför en betydande mängd av lågaktivt manipulation av data kommer att köras betydligt snabbare utanför CLR än inom CLR.
Program verkställande inom ramen för CLR köra snabbt för att vara användbart för många praktiska ändamål.
Som CPU hastigheterna ökar, och som nummer bättre tar fördel av flera CPUs, program verkställande inom ramen för CLR kommer att kunna användas för fler uppgifter som kräver en hög beräkning.
Men i mitten av 2008 den CLR fortfarande inte är lämpliga för 3D-spel av något sofistikerat, om inte en mycket aggressiv görs för att minska antalet funktion samtal till 3D bibliotek (OpenGL eller Direct3D), eventuellt med hjälp av begrepp som ”Shader-program” och ”visa listor,” något för att minska antalet funktion samtal.
