е значення, CLR виявить і запобіжить передачу 8-байтного значення в якості значення цього параметра. Безпека типів також означає, що управління може передаватися тільки в певні точки (Точки входу методів). Неможливо вказати довільну адресу і змусити програму виконуватися, починаючи з цієї адреси. Сукупність усіх цих захисних заходів позбавляє від багатьох поширених програмних помилок (наприклад, від можливості використання переповнення буфера для В«зломуВ» програми). p> - Розвинена підтримка налагодження. Оскільки CLR використовується для багатьох мов, можна написати окремий фрагмент програми мовою, найбільш підходящому для конкретного завдання, - CLR повністю підтримує налагодження багатомовних додатків. p> - Єдиний принцип обробки збоїв. Один з найбільш неприємних моментів Windows-програмування - неузгоджений стиль повідомлень про збої. Одні функції повертають коди станів Win32, інші - HRESULT, треті генерують виключення. У CLR відгуки всіх збоях повідомляється через винятки, які дозволяють відокремити код, необхідний для відновлення після збою, від основного алгоритму. Такий поділ полегшує написання, читання і супровід програм. Крім того, виключення працюють в багатомодульних і багатомовних додатках. І на відміну від кодів станів і HRESULT винятку не можна проігнорувати. CLR також надає вбудовані засоби аналізу стека, помітно спрощують пошук фрагментів, що викликають збої. p> - Безпека. Традиційні системи безпеки забезпечують управління доступом на основі облікових записів користувачів. Це перевірена модель, але вона має на увазі, що будь-якому кодом можна довіряти в однаковій мірі. Таке припущення виправдано, коли весь код встановлюється з фізичних носіїв (наприклад, з компакт-диска) або з довірених корпоративних серверів. Але в міру збільшення обсягу мобільного коду, наприклад Web-сценаріїв, додатків, що завантажуються з Інтернету, і вкладень, містяться в електронній пошті, потрібен орієнтований на код спосіб контролю за поведінкою додатків. Такий підхід реалізовано в моделі безпеки доступу до коду. p> - Взаємодія з існуючим кодом. У Microsoft розуміють, що розробники накопичили величезний обсяг коду і компонентів. Переписування всього цього коду, так щоб він задіяв усі гідності NET Framework, значно сповільнило б перехід до цієї платформи. Тому в. NET Framework реалізована повна підтримка доступу до СОМ-компонентів і Win32-функцій в існуючих динамічних бібліотеках DLL [1].
3. Архітектура і принцип роботи платформи NET Framework
3.1 Компіляція вихідного коду
платформа net framework робота
При роботі з платформою. NETможно створювати файли з вихідним кодом на будь-якій мові, що підтримує CLR. Потім відповідний компілятор перевіряє і аналізує вихідний код. Незалежно від компілятора результатом його роботи є керований модуль (managedmodule) - стандартний стерпний виконуваний (portableexecutable, РЕ) файл 32-розрядної (РЕ32) або 64-розрядної Windows (PE32 +), який вимагає для свого виконання виконувану середу CLR. p> У минулому майже всі компілятори генерували код для конкретних процесорних архітектур, таких як x86, IA64, і створенні розширюваних і комбінованих додатків. MEF дозволяє вказувати точки, де додаток може бути розширене, надавати доступ до служб іншим розширюваним додаткам і створювати частини, призначені для використання розширюваними додатками. Вона також дозволяє легко виявляти доступні частини на основі метаданих без необхідності завантаження зборок з цими частинами.
- Можливості програмування для Office. Завдяки додаванню іменованих і додаткових аргументів, типу dynamic, індексованих властивостей і додаткових модифікаторів ref вдалося значно поліпшити доступ до COM-інтерфейсів, в тому числі до API-інтерфейсів автоматизації Office. p> - Підтримка еквівалентності типів. Тепер можна розгортати програми з впровадженими відомостями про типах, а не з відомостями, імпортованими з основної збірки взаємодії. Додаток, містить впроваджені відомості про типи, може використовувати типи в середовищі виконання, не посилаючись на збірку середовища виконання. Якщо опубліковано кілька версій збірки середовища виконання, додаток, що містить впроваджені відомості про типах, може працювати з різними версіями без перекомпіляції.
- Ковариация і контрваріація. Коваріація дозволяє використовувати більш похідний тип, ніж це зазначено в універсальному параметрі, тоді як контрваріація дозволяє використовувати менш похідний тип. Завдяки цьому можна здійснювати неявне перетворення класів, що реалізують варіантні інтерфейси, і забезпечувати більшу гнучкість при зіставленні сигнатур методів з типами варіантних делегатів.
- Платформа NET Framework тепер підтримує файли з відображенням в пам'яті. З їх допомогою можна вносити зміни в дуже великі файли і створювати спільно використовувану пам'ять для між процесами взаємодії [4]. b>
Висновок
