Тази статия има за цел да запознае читателите възможно най-леко с основните понятия, които се срещат в платформата dotNET. Както пиша и в другите си статии, нека погледнем от историческа гледна точка откъде се е тръгнало, за да стигнем до тук.

   В началото, когато компютрите са били огромни машини, с тях са работили ограничен кръг тесни специалисти. Входът и изходът се е осъществявал чрез перфокарти, а писането на прости програми е отнемало часове.

   С течение на времето се появили opcode инструкциите, асемблерните езици, а след тях и езиците от високо ниво. Всички тези методи за комуникация с хардуера се подчиняват на правила, заложени в самата архитектура на компютърните машини. Ако дадена програма работи ефективно и се наложи тя да работи върху различна хардуерна платформа или операционна система, било е необходимо тя да се пренапише специално за новата платформа или операционна система. А ако програмата трябва да работи на 20 различни платформи? Това означава ли, че една програма трябва да се пише двадесет пъти?

   Решение на този проблем дават т.нар. виртуални машини. Най-често виртуалните машини са софтуерни програми (може и да са хардуерни), които "прочитат" даден ресурс и го изпълняват на машината, на която е инсталирана виртуалната машина. Добри примери за виртуални машини са Flash и Adobe Acrobat Reader. Независимо на каква софтуерна или хардуерна платформа работите, стига да имате съответния "четец", винаги можете да визуализирате желаното съдържание.

   В програмирането нещата се случват по подобен сценарий. Вместо програмата Ви да се компилира до изпълним код, тя се компилира до предварително дефинирани инструкции, които в последствие могат да се прочетат от съответната виртуална машина и да се изпълнят. Този специален код се нарича байткод. Той НЕ МОЖЕ да се изпълнява директно, необходим е "посредник", който допълнително да прочете и изпълни инструкциите.

   Тъй като програма, компилирана до байткод не може да се изпълни директно, това влошава нейната производителност, но за сметка на това печелим мащабируемост на приложението.

   Описах предните три параграфа, защото целит dotNET Framework се крепи върху тази концепция - при него няма изпълними файлове, всичко се свежда до байткод, който в dotNET се нарича IL (Intermediate Language).

   Всъщност IL представлява обектно-ориентиран стеков асемблер, който има вградени инструкции за създаване на обекти, извикване на жиртуални методи и т.н. За да изпълните IL код е необходимо да имате инсталиран Microsoft .NET Framework. Това всъщност представлява витуалната машина, която разчита ILкода и го изпълнява.

   Сега нека разгледаме по-подробн процесът на изпълнение на IL базирано приложение:

   Поне засега, dotNET приложенията (официално) работят само върху Wiнdows платформи (от Windows 98 до съвременните версии). Когато се стартира едно такова приложение, системата "разбира', че то не е стандартен изпълним файл (въпреки че в повечето случаи разширението на файла е "exe"), а е файл, съдържащ IL инструкции. В началото на изпълнението си, приложението се опитва да инициализира средата, в която то ще работи и при успех то продължава работата си.

   Средата, в която се изпълнява всяко dotNET приложение се нарича CLR (Common Language Runtime). Тя осигурява обектите, върху която се гради платформата dotNET, и тя е отговорна за правилното изпълнение на IL кода. Когато CLR се зареди, тя създава AppDomain по подразбиране, в който се зареждат основните асемблита, необходими за правилното функциониране на средата.