Чи потрібен мені файл Global.asax.cs, якщо я використовую клас OWIN Startup.cs і переміщую туди всю конфігурацію?

Скажімо, наприклад, у абсолютно новому додатку ASP.NET MVC 5, зробленому з MVC з шаблоном індивідуальних облікових записів, якщо я видаляю Global.asax.csклас і переміщую його конфігураційний код у такий Startup.cs Configuration()спосіб, які недоліки?

public partial class Startup
{
     public void Configuration(IAppBuilder app)
     {
        AreaRegistration.RegisterAllAreas();
        FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);

        ConfigureAuth(app);
    }
}

Найбільше для мене полягає в тому, що під час оновлення програм ASP.NET 4 до ASP.NET 5 та використання фрагментів, які тепер мають бути налаштовані в класі Startup.cs, я не роблю введення залежності та іншу конфігурацію у двох різних класах, які здаються пов'язаними до запуску та конфігурації.

Startup.Configuration викликається трохи пізніше, ніж Application_Start, але я не думаю, що різниця матиме велике значення в більшості випадків.

Я вважаю, що основними причинами збереження іншого коду в Global.asax є:

1. Узгодженість з попередніми версіями MVC. (Ось де зараз усі очікують знайти цей код.)
2. Можливість додавати інші обробники подій. У Global.asax ви можете керувати іншими методами, такими як Session_Start та Application_Error.
3. Правильність у різних сценаріях аутентифікації. Метод Startup.Configuration викликається лише в тому випадку, якщо у вашому бін-каталозі є Microsoft.Owin.Host.SystemWeb.dll. Якщо ви видалите цю DLL, вона мовчки припинить виклик Startup.Configuration, що може бути важко зрозуміти.

Я думаю, що третя причина є найважливішою з тих, що ми не застосовували цей підхід за замовчуванням, оскільки деякі сценарії не включають цю DLL, і приємно мати можливість змінювати підходи аутентифікації, не змінюючи місце розташування, де не пов'язаний код (наприклад, реєстрація маршруту) розміщується.

Але якщо жодна з цих причин не застосовується у вашому сценарії, я думаю, вам було б добре використовувати цей підхід.

Для тих, хто шукає повних кроків. Якщо ви хочете створити веб-API, розміщений на базі OWIN, IIS, ці кроки повинні вас дістати:

1. File -> New -> Project
2. У діалозі Installed -> templates -> Other Project types -> Visual Studio Solutions -> Blank Solution targeting .NET 4.6

3. У рішенні клацніть правою кнопкою миші та додайте Project -> Web -> ASP.NET Web Application(орієнтація .NET 4.6)

   3.1 Тепер у шаблонах ASP.NET 4.5 виберіть Порожній як шаблон

   3.2 При цьому створюється пусте рішення з двома нульовими пакетами:

   Microsoft.CodeDom.Providers.DotNetCompilerPlatform v 1.0.0
   Microsoft.Net.Compilers v 1.0.0
   

4. Встановіть наступні пакети:

   Install-Package Microsoft.AspNet.WebApi.WebHost -Version 5.2.3
   Install-Package Microsoft.AspNet.WebApi -Version 5.2.3
   Install-Package WebApiContrib.Formatting.Razor 2.3.0.0
   

Для OWIN:

Install-Package Microsoft.Owin.Host.SystemWeb 
Install-Package Microsoft.AspNet.WebApi.OwinSelfHost    

Потім додайте Startup.cs методом конфігурації:

[assembly:OwinStartup(typeof(namespace.Startup))]
public class Startup
    {
        /// <summary> Configurations the specified application. </summary>
        /// <param name="app">The application.</param>
        public static void Configuration(IAppBuilder app)
        {
            var httpConfiguration = CreateHttpConfiguration();

            app
                .UseWebApi(httpConfiguration);
        }

        /// <summary> Creates the HTTP configuration. </summary>
        /// <returns> An <see cref="HttpConfiguration"/> to bootstrap the hosted API </returns>
        public static HttpConfiguration CreateHttpConfiguration()
        {
            var httpConfiguration = new HttpConfiguration();
            httpConfiguration.MapHttpAttributeRoutes();

            return httpConfiguration;
        }
}

Тепер додайте клас, який успадковує ApiController, анотуйте його за допомогою RoutePrefixатрибута та методу дії за допомогою Route + HttpGet/PutPost(що представляє дієслово Http, яке ви хочете), і вам слід добре пройти

Це моє розуміння того, як розвивалася запуск / розміщення веб-додатків, оскільки все це досить заплутано. Невеликий підсумок:

1. Класичний ASP.NET: Напишіть лише код програми для запуску на останньому кроці обов'язкового трубопроводу IIS

2. ASP.NET за допомогою OWIN: Настройте веб-сервер .NET і напишіть код програми. Більше не пов'язане безпосередньо з IIS, тому ви більше не змушені ним користуватися.

3. ASP.NET Core: Налаштуйте як хост, так і веб-сервер для використання та запису коду програми. Більше не потрібно використовувати веб-сервер .NET, якщо ви орієнтуєтесь на .NET Core замість повної .NET Framework.

Зараз я трохи детальніше розповім, як це працює та які класи використовуються для запуску програми:

Класичний ASP.NET

Класичні програми ASP.NET мають Global.asaxфайл в якості точки входу. Ці програми можна запускати лише в IIS, і ваш код виконується в кінці трубопроводу IIS (тому IIS відповідає за CORS, автентифікацію ... до того, як ваш код навіть запуститься). З IIS 7 ви можете запускати свою програму в інтегрованому режимі, який інтегрує час виконання ASP.NET в IIS. Це дозволяє вашому коду налаштувати функціональні можливості, які раніше були неможливі (або лише в самому IIS), такі як перезапис URL-адреси у Application_Startвипадку вашого Global.asaxфайлу або використання нового <system.webserver>розділу у вашому web.configфайлі.

ASP.NET з OWIN

Перш за все, OWIN - це не бібліотека, а конкретизація взаємодії .NET-серверів (наприклад, IIS) з веб-додатками. Самі Microsoft мають реалізацію проекту OWIN під назвою Katana (поширюється через декілька різних пакетів NuGet). Ця реалізація надає IAppBuilderінтерфейс, з яким ви стикаєтесь у Startupкласі, та деякі компоненти проміжного програмного забезпечення OWIN (OMC), що надаються Microsoft. ВикористанняIAppBuilderви в основному створюєте проміжне програмне забезпечення підключення до режиму «підключення і відтворення», щоб створити конвеєр для веб-сервера (окрім лише трубопроводу ASP.NET в IIS7 +, як у пункті вище), замість того, щоб прив’язуватися до трубопроводу IIS (але тепер ви використовуєте компонент середнього програмного забезпечення для CORS, компонент середнього програмного забезпечення для аутентифікації ...). Через це ваша програма більше не приєднана до IIS, і ви можете запустити її на будь-якому веб-сервері .NET, наприклад:

• Пакет OwinHost можна використовувати для самостійного розміщення вашої програми за допомогою веб-сервера Katana.
• Пакет Microsoft.Owin.Host.SystemWeb використовується для розміщення вашої програми OWIN в IIS7 + в інтегрованому режимі, підписавши внутрішнє програмне забезпечення на правильні події протягом життя.

Те, що робить все настільки заплутаним, це те, що Global.asaxвін все ще підтримується разом із Startupкласом OWIN , хоча вони можуть робити подібні речі. Наприклад , ви могли б реалізувати CORS в Global.asaxі аутентифікації з використанням Owin проміжного рівня, який стає дуже заплутаним.

Моє правило - видалити Global.asaxфайл взагалі на користь використання, Startupколи мені потрібно додати OWIN.

ASP.NET Core

Наступна еволюція ASP.NET Core - тепер ви можете орієнтуватися на .NET Core або повний .NET Framework. Коли ви орієнтуєтесь на .NET Core, ви можете запустити свою програму на будь-якому хості, який підтримує .NET Standard. Це означає, що ви більше не обмежені веб-сервером .NET (як у попередньому пункті), але можете розмістити вашу програму в контейнерах Docker, веб-сервері linux, IIS ...

Точкою входу для веб-програми ASP.NET Core є Program.csфайл. Там ви налаштовуєте свого хоста і знову вказуєте свій Startupклас, де ви налаштовуєте конвеєр. Використання OWIN (за допомогою IAppBuilder.UseOwinметоду розширення) необов'язково, але повністю підтримується .