2. ASP.NET Core 1.0
• Попередня назва ASP.NET 5
• Кросс-платформний фреймворк з відкритим вихідним кодом.
• Оптимальний для хмарних веб-додатків
3. • Новий легка та модульна магістраль HTTP запитів
• Можливість хоститингу на IIS або само-хостинг і вашому власному процесі
• Будується на .NET Core, яке підтримує справжню side-by-side версійність програм
• Повністю постачається як NuGet пакет
• Інтегрована підтримка для створення і використання NuGet пакетів
• Одно-вирівняний веб стек для Web UI та Web APIs
• Базова конфігурація середовища готова для хмарних рішень
• Вбудована підтримка інєкції залежностей
• Нові засоби що спрощують сучасну веб розробку
• Компіляція та виконання крос-платворменних ASP.NET додатків на Windows, Mac and Linux
• Відкритий вихідний код
5. • ASP.NET 5 додатки білдяться й виконуються за допомогою нового .NET Execution
Environment (DNX).
• Кожен ASP.NET 5 проект є проектом DNX.
• ASP.NET 5 інтегрується з DNX через ASP.NET Application Hosting пакет
NET Execution Environment (DNX).
6. • .NET Execution Environment (DNX) являє собою комплект розробки програмного забезпечення
(SDK) і рантайм середовище, яке має все необхідне для створення і запуску додатків .NET на
Windows, Mac і Linux.
• Забезпечує хост-процес, CLR хостинг логіку і знаходження керованих точок входу.
• DNX був побудований для запуску крос-платформних веб-додатків ASP.NET, але він може
запускати інші типи додатків .NET теж, такі як крос-платформні консольні додатки.
NET Execution Environment (DNX).
7. • DNX проект є папкою з файлом project.json.
• Назва проекту є ім'ям папки.
• Ви можете використовувати проекти DnX для побудови пакетів NuGet.
• Файл project.json визначає метадані пакета, залежності вашого проекту і який фреймворк ви
хочете білдити
• Всі файли в папці за замовчуванням є частиною проекту, якщо явно не виключені в
project.json.
• Ви вказуєте для яких фреймворків ви хочете білдити, під властивістю “frameworks”.
DNX
9. • Залежності в DNX складаються з імені та номера версії.
• Номери версій повинні слідувати Semantic Versioning.
• Як правило залежності відносяться до встановленого пакета NuGet або до іншого проекту
DNX.
• Посилання проекту резолвляться за допомогою тимчасових папок для поточного проекту або
шляху проекту визначених за допомогою global.json файлу на рівні рішення
Dependencies
10. • Файл global.json також визначає мінімальну версію DNX (“SDK" версії), необхідних для
створення проекту.
• Залежноcті транзитивні в тому, що вам потрібно вказати тільки залежності верхнього рівня.
• DNX буде обробляти резолвлення всіх залежностей графа для Вас, використовуючи
встановлені пакети NuGet.
• Проект резолвиться під час виконання шляхом білдження проекту в памяті. Це означає, що у
вас є повна гнучкість для розгортання програми DNX як пакет бінарних файлів або в якості
вихідного коду.
Dependencies
11. • Для вирішення залежностей пекеджа, вони повинні бути встановлені.
• Ви можете використовувати DNU, щоб встановити новий пакет в існуючий проект або
відновити всі залежності пакетів для існуючого проекту. Наступна команда і завантажує і
встановлює всі пакети, які перераховані у файлі project.json:
dnu restore
Packages and feeds
12. • Команда є іменованим виконанням точки входу .NET з конкретними аргументами.
• Ви можете визначити команди у файлі project.json:
• Потім ви можете використовувати DNX для виконання команд, визначених вашим проектом
dnx web
• Команди можуть бути побудовані і поширюватися у вигляді пакетів NuGet.
dnu commands install MyCommand
Commands
13. • Хост додатоків DNX, як правило, є першою керованою точкою входу викликаною DNX і
відповідає за обробку залежності, парсингу project.json, надання додаткових сервісів і виклику
точки входу додатка.
• В якості альтернативи, ви можете мати прямі виклики DNX ваших точок. Це вимагає, щоб ваш
додаток буде повністю побудований і всі залежності, розташовані в одному каталозі.
Використання DNX без використання DNX Application Host не є поширеним явищем.
• Хост додатоків DNX надає набір послуг з додатками через ін'єкції залежностей (наприклад,
IServiceProvider, IApplicationEnvironment і ILoggerFactory).
Application Host
14. • Модулі компіляції є точкою розширюваності, які дозволяють брати участь в процесі компіляції
DNX.
• Ви реалізовуєте модуль компіляції шляхом реалізації інтерфейсу ICompileModule і ставлення
його в компілятор / препроцессор або компілятор / постпроцессор в вашому проекті.
Compile Modules
15. • ASP.NET 5 додатки визначаються використовуючи публічний клас Startup :
• Метод ConfigureServices визначає сервіси, які використовуються вашим додатком
• Метод Configure використовується щоб визначити яке пз проміжного шару (middleware)
складає вашу магістраль запитів
Startup.cs
16. • Сервіс є компонентом, який призначений для загального використання в додатку.
• Сервіси доступні через ін'єкції залежностей.
• ASP.NET 5 включає в себе простий вбудований контейнер інверсії управління (IoC), який
підтримує впровадження конструктора за замовчуванням, але може бути легко замінений на
IoC контейнер вибору.
• Сервіси в ASP.NET 5 бувають трьох видів: сінглтон, з областю дії і перехідні (singleton, scoped
and transient).
Сервіси
17. • Перехідні сервіси створюються кожен раз, коли на них є запит з контейнера. Сервіси доступні
через ін'єкції залежностей.
• Сервіси із заданою областю створюється, тільки якщо вони ще не існують в поточній області.
• Для веб-додатків, область застосування контейнера створюється для кожного запиту, так що
ви можете думати про Scoped сервіси як створювані на кожен запит.
• Singleton сервіси створюються тільки один раз.
Сервіси
18. • У ASP.NET 5 ви будуєте власну магістраль запитів з використанням проміжного програмного
забезпечення.
• ASP.NET 5 проміжне програмне забезпечення виконує асинхронну логіку на HttpContext, а
потім при необхідності викликає наступне проміжне програмне забезпечення в послідовності
або безпосередньо припиняє запит.
• Як правило, ви «використовуєте" проміжне програмне забезпечення шляхом виклику
відповідного методу розширення на IApplicationBuilder в вашому Configure методі.
Middleware
19. • ASP.NET 5 поставляється з багатим набором попередньо вбудованому проміжного
програмного забезпечення:
• Робота з статичними файлами
• Маршрутизація
• Діагностика
• Автентифікація
• Ви можете використовувати будь-який OWIN-based (Open Web Interface for .NET) middleware з
ASP.NET 5.
Middleware
20. • ASP.NET Application Hosting модель не слухає безпосередньо запити але замість цього
спирається на реалізацію HTTP-сервера на поверхневий запит до додатка, як набору майбутніх
інтерфейсів, які можуть складатися в HttpContext.
• ASP.NET 5 включає в себе підтримку сервера для запуску на IIS або самостійно в своєму
власному процесі.
• В операційній системі Windows ви можете розмістити свій додаток за межами IIS за допомогою
сервера WebListener, який заснований на HTTP.sys. Ви також можете хостити додаток на не –
Windows середовищі з використанням крос-платформного веб-сервера Kestrel.
Servers
21. • Web root вашого додатку є кореневий каталог у вашому проекті, з якого HTTP-
запити обробляються (напр., Обробка статичних файлових запитів).
• Web root на ASP.NET 5 додатку конфигурується за допомогою властивості
"Webroot" у вашому файлі project.json.
Web root
22. • ASP.NET 5 використовує нову модель конфігурації для обробки простих пар ім'я-значення, яке
не грунтується на System.Configuration або web.config. Ця нова модель конфігурації тягне дані з
упорядкованого множини постачальників конфігурації. Вбудовані постачальники конфігурації
підтримують різні формати файлів (XML, JSON, INI), а також змінні оточення, щоб включити
середовище-орієнтовну конфігурації середовища. Ви також можете написати свої власні
користувацькі конфігурації постачальників. Середовища, такі як Development і Production, є
першим класом поняття в ASP.NET 5, а також можна налаштувати за допомогою змінних
оточення:
Configuration
24. • ASP.NET 5 призначений для повної інтеграції з різними клієнтської сторонніми фреймворками,
в тому числі AngularJS, KnockoutJS і Bootstrap.
Client-side development
25. 1. Встановіть Visual Studio 2015 з Microsoft Web Developer Tools.
2. Встановіть оновлення ASP.NET 5
3. Відкрийте командний рядок і виконайте: dnvm upgrade
4. У випадку нерозпізнавання даної команди встановіть Powershell 4.0
5. Виконайте команду @powershell -NoProfile -ExecutionPolicy unrestricted -Command
"&{$Branch='dev';$wc=New-Object
System.Net.WebClient;$wc.Proxy=[System.Net.WebRequest]::DefaultWebProxy;$wc.Proxy.Credential
s=[System.Net.CredentialCache]::DefaultNetworkCredentials;Invoke-Expression
($wc.DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}"
• Виконайте команду dnvm list і на етапі підтвердження виберіть Y (Yes)
Інсталяція ASP.NET 5
dnvm upgrade -r coreclr
27. • Нова структура рішення включає в себе рішення елементи папки з файлом global.json, а сам
веб-проект знаходиться в корені папки src.
• Нова структура також включає в себе спеціальну папку Wwwroot і розділ Dependencies на
додаток до секції References , яка була присутня в попередніх версіях
• У кореневому каталозі проекту, є також кілька нових файлів, таких як bower.json,
appsettings.json, gulpfile.js, package.json, project.json і Startup.cs.
• Ви можете помітити, що файли global.asax, packages.config і web.config зникли.
Структура проекту ASP.NET 5
dnvm upgrade -r coreclr
28. • ASP.NET 5 може орієнтуватись на кілька сфреймворків, що дозволяє додатку бути
розгорнутим в різних хостинг середовищах.
• Ви можете побачити, які фреймворки задані в властивостях веб-додатку, клацнувши правою
кнопкою миші на веб-проекту в Solution Explorer і вибравши пункт Properties :
Framework Target
29. • Використовується для визначення на стороні сервера залежностей, а також іншу інформацію
щодо конкретних проектів.
• Властивість UserSecretsId містить значення, яке виступає в якості унікального ідентифікатора
вашого веб-додатка
• Властивість version визначає поточну версію проекту. Можна також вказати інші метадані про
проект, такі як автори і опис.
• Ви можете використовувати параметр compilationOptions, щоб встановити налаштування
програми, такі як languageVersion і useOssSigning.
project.json
30. • Зазвичай значення, які знаходиться в розділі залежностей відносяться до встановленого
пакета NuGet або до іншого проекту.
• Секція commands дозволяє налаштувати команди, які можуть бути запущені з командного
рядка (наприклад, запустити веб-сайт або запустити тести).
• Розділ frameworks позначає, які цільові фреймворки будуть білдитись, і які залежності повинні
бути включені.
project.json
31. • Розділ exclude використовується для ідентифікації файлів і папок, які повинні бути виключені
з збірки. Точно так як і publishExclude використовується для ідентифікації частин контенту
проекту, які повинні бути виключені при публікації сайту
• Розділ scripts використовується для вказівки, коли скрипти автоматизації збірки повинні
виконуватись. Visual Studio тепер вбудовану підтримку для виконання таких сценаріїв до і
після зазначених подій.
• ASP.NET шаблон проекту за замовчуванням має сценарії в місці для запуску під час
postrestore і prepare, що встановлють залежноств на стороні клієнта.
project.json
32. • Файл global.json використовується для настройки рішення в цілому. За замовчуванням він
включає в себе тільки дві секції, projects і JDK.
• Властивість projects визначає, які папки містять вихідний код для рішення.
• Властивість sdk визначає версії DNX (.NET Execution Environment), що Visual Studio буде
використовувати при відкритті рішення.
global.json
33. • Папка Wwwroot представляє фактичний корінь (root) веб-додатка при запуску на веб-сервері.
Статичні файли, такі як appsettings.json, які не перебувають в Wwwroot ніколи не будуть
доступні, і немає необхідності створювати спеціальні правила для блокування доступу до
конфіденційних файлів. Замість чорних списків доступу до конфіденційних файлів, більш
безпечний підхід – білий список, при цьому тільки ті файли що в папці Wwwroot доступні через
веб-запити. Крім того, в той час як папка є веб рутом по замовчуванню, конкретну кореневу
папку можна налаштувати в project.json.
Папка wwwroot
34. • Папка Dependencies містить дві папки: Bower і NPM. Ці папки відповідають двом менеджерам
пакетів з відповідними іменами і вони використовуються, щоб підтягувати залежності та
інструменти на стороні клієнта. Розширення папки показує, які залежності наразі
управляються кожним інструментом, і яка їх поточна версія використовується в проекті.
• Bower dependencies контролюються bower.json файлами, розташованими в кожній з підпапок
Wwwroot / Lib. Кожна залежність потім додатково налаштовується у відповідній секції,
використовуючи свій власний файл bower.json, вказавши, як він повинен бути розгорнутий в
папку Wwwroot.
Client Side Dependency Management
35. • ASP.NET 5 додатки визначаються використовуючи публічний клас Startup :
• Метод ConfigureServices визначає сервіси, які використовуються вашим додатком
• Метод Configure використовується щоб визначити яке пз проміжного шару (middleware)
складає вашу магістраль запитів
Startup.cs
36. • Встановіть HTTP Platform Handler версії 1.2 або вище
• В Solution Explorer в контекстному меню проекту виберіть Publish.
• В діалозі Publish Web на вкладці Profile виберіть File System.
• Введіть імя профілю. У вкладці Connection ви можете змінити шлях публікації У вкладці
Settings ви можете задати налаштування публікації
• Перейдіть до папки куди паблішили проект
• Скопіюйте каталоги approot і Wwwroot на цільовий сервері IIS.
• У диспетчері IIS створіть новий веб-сайт і встановіть фізичний шлях до Wwwroot.
Publishing to IIS
38. • Web API являє собою інтерфейс прикладного програмування (API) для будь-якого
веб-сервера або веб-браузер. Це концепція веб-розробки, як правило,
обмежується до клієнт-серверної взаємодії і, зазвичай, не включає веб сервер або
деталей імплементації браузера, таких як SAPIs або АРІ браузера, крім тих що
публічно доступні по віддалених веб-додатків.
Web API
39. • На стороні сервера Web API представляє собою програмний інтерфейс, що
складається з одного або більше відкритих кінцевих точок (endpoints) для певної
системи передачі повідомлень типу запиту-відповідь, як правило, виражене в JSON
або XML, який піддається впливу через веб - найчастіше за допомогою основаного
на HTTP веб-сервера.
Web API server-side
40. • Mashups це веб-додатки, які поєднують в собі використання декількох клієн-серверних Web
API .
• Webhooks це Web API , на стороні сервера, які приймають в якості вхідних даних універсальний
ідентифікатор ресурсу Uniform Resource Identifier (URI), який призначений для використання як
віддалений іменований канал або тип зворотного виклику, таким чином що сервер діє як
клієнт щоб обробити надані URI і викликати подію на іншому сервері, який обробляє цю подію,
таким чином забезпечуючи тип з'єднання рівноправних вузлів peer-to-peer IPC.
Web API server-side
43. • Основний контроллер, який реалізує фукціонал Web API
• Обробка HTTP матодів
• REST
ValuesController
44. • Всі визначення маршрутів для Web API знаходяться в файлі WebApiConfig.cs (в
папці App_Start)
Маршрутизація в Web API
45. • В даному випадку визначено один маршрут, де в якості другого параметра
виступає контролер, а третій необов'язковий параметр представляє певний
ідентифікатор. Таким чином, на відміну від маршрутів звичайних контролерів у нас
тут немає дії, тільки контролер і додатковий необов'язковий параметр
• В результаті звернення api / values буде відповідати зверненню до контролера
ValuesCotroller, причому майже до всіх дій відразу (крім Get (int id) - так як в даному
випадку необхідний ще ідентифікатор, наприклад api / values / 2)
Маршрутизація в Web API
46. • Але, як вже зазначалося, в залежності від використаного методу HTTP фреймворк
буде розрізняти до якї саме дії відноситься поточний запит
Маршрутизація в Web API
47. • При створенні методів контролера Web API діють деякі умовності. Так, імена
методів за замовчуванням повинні починатися з імені призначеного для них
методу HTTP. У випадку з контролером за замовчуванням все просто: всі методи
дій носять назви методів HTTP.
• Однак ми можемо використовувати і будь-які інші імена без префіксів, але в цьому
випадку нам треба буде явно вказати метод HTTP у вигляді атрибуту, наприклад:
Умовності при найменуванні методів
48. • Схема URI, що синтаксично ідентична http: схемі, яка зазвичай використовується для доступу
до ресурсів Інтернет.
• Використання https: URL вказує, що протокол HTTP має використовуватися, але з іншим портом
за замовчуванням (443) і додатковим шаром шифрування/автентифікації між HTTP і TCP.
• HTTPS це не окремий протокол, а HTTP через SSL або TLS
• Щоб підготувати веб-сервер для прийняття https транзакцій адміністратор повинен створити сертифікат з
відкритим ключем для веб-сервера. Цей сертифікат повинен бути підписаний уповноваженим на видачу
сертифікатів (certificate authority), який засвідчує, що отримувач сертифікату — саме той, про кого йдеться у
сертифікаті. Браузери розповсюджуються з сертифікатами уповноважених на видачу сертифікатів верхнього
рівня організацій, таким чином браузери можуть перевірити сертифікати підписані ними.
HTTPS
49. • Криптографічний протокол, який забезпечує встановлення безпечного з'єднання між клієнтом
і сервером.
• Протокол SSL складається з двох підпротоколів: протокол SSL запису і рукостискання.
• Для роботи SSL потрібно, щоб на сервері був SSL- сертифікат.
• SSL надає канал, що має три основні властивості:
• Аутентифікація - Сервер завжди автентифікований, в той час як клієнт автентифікований в залежності від
алгоритму.
• Цілісність - Обмін повідомленнями включає в себе перевірку цілісності.
• Конфіденційність каналу - Шифрування використовується після встановлення з'єднання і використовується
для всіх наступних повідомлень.
SSL (Secure Sockets Layer)
50. • Криптографічний протокол, що надає можливості безпечної передачі даних в Інтернет для
навігації, отримання пошти, спілкування та передачі інших даних.
• Використовує асиметричне шифрування і сертифікати X.509.
• Існують незначні відмінності між TLS та SSL, але, в основі, протокол той самий.
• В даній поточній версії протоколу доступні такі алгоритми:
• Для обміну ключами і перевірки їх справжності використовують комбінації алгоритмів: RSA (асиметричний
шифр), Diffie-Hellman (безпечний обмін ключами), DSA (алгоритм цифрового підпису) і алгоритми технології
Fortezza.
• Для симетричного шифрування: RC2, RC4, IDEA, DES, Triple DES або AES;
• Для хеш-функцій: MD5 або SHA.
TLS (Transport Layer Security)
51. • Створення або отримати сертифікат. Для тестування ви можете створити самостійно
підписаний сертифікат.
• Додати HTTPS binding.
Enabling SSL on the Server
52. • Якщо у вас є одночасно HTTPS і HTTP прив'язки, клієнти як і раніше можуть використовувати HTTP для доступу
до сайту. Ви можете дозволити доступ до деяких ресурсів через HTTP, в той час як інші ресурси
вимагаютимуть SSL. В цьому випадку рекомендується використовувати фільтр дій і вимагати SSL для
захищених ресурсів.
Enforcing SSL in a Web API Controller
53. • Потім ви можете додати цей фільтр до будь яких Web API дій
Enforcing SSL in a Web API Controller
