Портування великого проекту .NET Core

Дано: система з 10-річною історією, розроблена на C#, з досить великою кодовою базою. Серверною частиною системи є веб-сервіс (хоститься в IIS, протокол SOAP), який активно працює з базою даних, з кешуванням в Redis, з різними перевірками безпеки, пошук у Elasticsearch.

Завдання: забезпечити роботу системи на Linux без втрати в продуктивності з мінімальними рухами.

Напрошуються 3 варіанти рішення завдання:

  1. Використовувати Mono
  2. Використовувати .NET Core
  3. Переписати все на Java\Go\Python
3-й варіант відкидається відразу ж, на переписування піде кілька людино-років розробки. Залишаються Mono і .NET Core.

Що не так з Mono
Хоч і технологія з'явилася давно і успішно використовується (наприклад, в Xamarin) є кілька сумнівів щодо подальшого розвитку Mono:

  • Придбання Xamarin microsoft'ом. Microsoft публічно робить ставку на .NET Core і вкладає в нього гроші. Процес розробки .NET Core відкритий, доступні дати релізів, roadmap і т. д. Що буде з Mono поза Xamarin питання. Чи буде Microsoft одночасно розвивати 2 конкуруючі реалізації .NET?

  • Відсутність фідбек. З якою продуктивністю працює Mono? Чи можна застосовувати в enterprise? Про Mono майже не говорять на конференціях, таке відчуття, що технологію ніхто не використовує
У підсумку вибір припав на .NET Core. Завдання ускладнюється, що потрібно одночасно підтримувати .NET 4.6.1 реалізацію, і .NET Core в одній кодовій базі, так як не всіх клієнтів можна оновити і потрібна зворотна сумісність.

Міграція проектних файлів
Для початку потрібно встановити Update 3 для Visual Studio 2015 і свіжий .NET Core SDK (свіжі білди публікуються на сторінці проекту). Потім для кожного csproj-файла потрібно створити його аналог — project.json. Заходимо в папку з кожним проектом, в командному рядку вводимо
dotnet new
.

З'явиться project.json, з неї потрібно видалити рядок про emitEntryPoint, якщо збірка не містить методу Main. Далі, створюємо порожній sln-файл, додаємо в нього project.json файли, як проекти. У кожен project.json слід прописати залежності проекти (розділ dependencies), пробуємо скомпілювати. Якщо помилок компіляції немає — вітаю. Єдина проблема, що старий солюшен з csproj-проектами перестане працювати, щоб обидва проекти працювали side by side є рішення. Виглядає досить дивно, але працює.

Що не буде працювати
У нашому додатку зіткнулися з такими проблемами:

  • app.config — Розробники corefx відмовилися від застарілого API роботи з конфігураційними файлами. Тепер конфігурації рекомендується зберігати в json файлі.
  • PerformanceCounter — Windows специфіка, для використання на платформі Windows слід шукати якусь альтернативу.
  • DataSet, DataTable — вважається застарілими API.
  • LCID у CultureInfo — у культури тепер немає властивості LCID, CultureInfo тепер можна створити тільки по імені.
  • Властивість Assembly в примірника Type — щоб отримати опис збірки у типу необхідно використовувати метод-розширення GetTypeInfo(). Ламає сумісність з поточним кодом, особливо в ресурсних файлах.
  • MachineKey — Windows специфіка, немає можливості отримати унікальний ідентифікатор поточної машини.
  • Thread.SetData, Thread.GetData — додадуть у другій версії стандарту.
Це все, що стосується API стандартної бібліотеки. Очевидно, слід переробляти код використовує нативні виклики (у нашому випадку, код перевірки прав доступу і робота з дескрипторами безпеки). Файли з таким legacy-кодом виключали з компіляції (розділ exclude project.json) або відключали директиви умовної компіляції (NETCOREAPP1_0).

SOAP
У поточній реалізації .NET Core немає способу коробки створити Web-сервіс працює за SOAP. пример з MSDN, де показують як можна при особливому бажанні підтримати протокол SOAP. Ми для себе вирішили відмовитися від SOAP і перекласти веб-сервіс на REST. Ніяких проблем немає, ASP.NET Core не відрізняється від ASP.NET Web API. Є DI з яким можна жити. Контролери, роуты, навіть swagger працює — все на місці.

Залишилися ще більші проблеми: аутентифікація користувачів (раніше це робив IIS) і яку бібліотеку використовувати для управління правами доступу, інтеграції з LDAP.

Першу проблему можна вирішити поставивши перед нашим додатком Apache з необхідним розширенням і включивши reverse proxy. Бібліотеку для управління ACL ще не знайшли.

Висновки
Visual Studio 2015 Update 3 і Resharper на проектах .NET Core працюють ідеально, з налагодженням і швидкістю компіляції проблем немає. Нарешті-то для доставки програму можна використовувати Docker. Unit-тести працюють.

До повної впевненості потрібно проводити навантажувальні тести. Але в цілому технологія має право на життя, хоч і є проблеми з тулингом: наприклад, не підтримується msbuild. Рекомендую .NET розробників придивитися і почати використовувати .NET Core в своїх проектах. Для нас поки тільки позитивний досвід.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.