.Net’ten .Net Core’a geçtik, ne sıkıntılar yaşadık?
Merhabalar herkese,
Son dönemlerde .Net ekosisteminde devam eden çoğu firma .Net’ten .Net Core’a ya geçiyor ya da geçiş sürecinde, bizim de bu süreçte ne sıkıntılar çektiğimizden bahsedeceğim. Belki henüz .Net Core ya da yeni yazımıyla dotnet’e geçmeyenlerimiz vardır, bu yazı onlar için!
İlk olarak dotnet’e geçmemiz gerektiğinin farkına vardık, çünkü Docker gibi son teknolojilerden faydalanmak istiyorduk. Development hızımızı olabildiğince arttırmak ve teknoloji konusunda güncel kalmak istiyorduk. Tabii bu tek başına yeterli bir gerekçe değildi. Developer istekleriyle şirketin ihtiyaçlarının kesişmesi önemli bir durum. “Dotnet’e gerçekten geçmeli miyiz?” diye bir soru sorduk. Bu sorunun cevabı yüksek performans olarak geri döndü. Tabii bir çok faydası var ama en bariz olanı dünyadaki en hızlı framework’lerden biri olmasıydı. Yüksek performans daha az sunucu kaynağı ihtiyacı vb. bir çok mantıklı gerekçeyi beraberinde getirdi. Daha iyi loglama, exception handling vb. bir çok yenilik, çok güzel yeni library’ler ve CI yapıları! Bir de linux’ta kusursuz çalışması da bizi bu yola soktu.
Performansa bakınca aşağıdaki siteden 17. round sonucu olarak dünyanın en hızlı 7. framework’ü olması fazla iyi bir durum ki zaten 1. ile arasında çok bir fark yok. E tabi ilk sıradakilerle kodlama yapmak biraz zahmetli, bu kadar feature’ı destekleyen ve bu kadar hızlı tek framework şu an aspnetcore!
Csproj yapıları
Yeni csproj yapısı çok güzel olmuş gerçekten, ancak bir sıkıntı var. Aynı anda legacy yani .Net 4.7 vb. bir framework ile geliştirilen projeler ile aynı solution üzerinden yürüyecekseniz, size tavsiyem yapmayın. Çok saçma hatalar alacaksınız, bazen clean & rebuild anlamsızca sorunları çözecek, bazen çözemeyecek. Burada framework ve Msbuild 15 ile alakalı bir durum olduğundan bahsetmişler. Bizim bu biraz canımızı sıktı açıkcası. Biz bunu projeleri solution’lara bölerek çözdük. Hatta bazı solution’larımızı aynı repo içinde çoklu kullanarak rahatlattık. En uygun çözüm, tek solution altında dotnet projelerini toplamak, eskileri başka yerde toplamak.
Deployment
Windows’da çalışıp Linux’a publish yapma gibi bir hayal varsa bu sıkıntı olmuyor. Ama genelde sıkıntı olmuyor 🙂 Biz bu sorunu Docker’a geçerek aştık. Burada çok vakit kaybetmedik açıkcası. Eğer ki Docker kullanma gibi bir niyetinizi yoksa dotnet çok fazla bir şey katmayacaktır. Zaten en büyük olaylarından biri cross platform ve web server agnostic yapısı. Kısacası Docker’a geçmemek hata, geçmeyeceğiz derseniz Linux deployment için tek çareniz çok iyi CI yapınızın olması.
NetStandard
MS ekibi NetStandard diye bir yapı getirdi. Çok güzel bir iş başarmışlar ama legacy bazı yapılarak destek veriyo gibi görünüp bazı şeyleri patlatabiliyor. Mesela biz Cryptography library’lerinde öyle sıkıntılar çektik ki inanamazsınız. Çalışır, derlenir görünen şey tamamen farklı çalışıyordu. O açıdan bu uyumlu library’leri gözden geçirmenizde fayda var. Ayrıca SOAP ile entegre ettiğimiz bir çok yapı var. Bunlar da görünürde derlenir ve çalışır gibiydi ama iş publish ve test’lere gelince çok saçma hatalar aldık. Mesela System.Object’i bulamadım bile dedi. Biz de aynen “Nasıl yani?” dedik bunu multiple target framework yapısı ile çözdük. Bu bir avantaj ama sanırım çok fazla dökümante edilmediği için, burada gereksiz çok vakit kaybettik.
IIS artık yok!
Artık IIS olmaması beni aşırı derece mutlu etti. Zaten oldum olası sevmezdim, gereksiz yavaş gelirdi. IIS üzerinde çalışabilirsiniz, hobi olarak yine çalışın ama bana göre built-in şekilde gelen Kestrel tek mantıklı seçenek. Docker ile yaparsanız, direk Kestrel ile yola devam edip arkanıza bakmadan gidebilirsiniz. Eğer ön yüz projeniz public bir website ise (bizimki gibi) Nginx kullanarak reverse proxy’leyebilirsiniz. Bu arada Kestrel IIS’e göre 20 kat daha fazla request handle edebiliyor ki bence muazzam.
Değişen library ve namespace’ler
Değişen baya library ve namespace olmuş. System seviyesinde streamwriter gibi yapıların yeri değişmiş, file işlemi çok yapıyorsanız bunları tek tek namespace’lerini düzenlemeniz gerekecek ama korkulacak bir şey sadece namespace :)
Reflection üzerinden çok fazla iş yapıyorsanız bunlara da dikkat etmeniz hayrınıza olacak. Mesela GetType() dönüşü değiştirildi. Mantıklı bir performans açıklamaları var tabi ama kullanımlarınız bunun üzerinden çok varsa sıkıntı olabilir. Biz Proxy pattern ile bazı yapılarımızı bu şekilde ayağa kaldırıyorduk ve buralarda sıkıntı yaşadık ama neyse ki full detay veren GetTypeInfo() methodunu da koymuşlar. Bunları böyle kolay aştık.
Asıl dert System.Security’de oldu. RSA ve MD5 provider’ları gerçekten fail olmuş. Dotnet reposunda bununla alakalı açılmış tonla issue görebilirsiniz. Static bazı yapıları değiştirmiş veya silmişler. Hash üretim mekanizması da değişmiş. Eğer TC kimlik gibi şeyleri hash’liyorsanız bu yapıları en az 2 kere kontrol edin derim. Yoksa çok ciddi data kayıpları verebilirsiniz.
DataSet ve DataTable’ı komple kaldırmışlar. Aslında severdim bunları neden kaldırdılar bilmiyorum. Bazı library’ler içinden tekrar kullanım yapabiliyorsunuz ama official olarak desteklenmediği için biz bunları taşıdık. Yani bir şey official değilse biraz çekimser kalıyorum. Biraz garanticilik diyebiliriz 🙂
System.Drawing’i kaldırmışlar. Eğer image processing ya da pdf generation yapıyorsanız baya can sıkıcı olabiliyor. Bizim sistemde müşterilere ödeme sonrası fatura sistemlerini uyarlama esnasında ciddi sıkıntılar yaşadık. 3rd party library’ler ile çözdük, üzerine fazla düşünmedik ama yapıyı tamamen baştan yazmamız gereken yerler de oldu. iTextReader ve Drawing için Hanselman’ın blog’unda bir yazı ve ilgili bir nuget var, bunlar işinizi görecektir.
En acayip değişiklik Newtonsoft’tan geldi. Resmen güvendiğim dağlara kar yağdı diyebilirim. Nedense default naming resolver’larını Pascal Case’den camel case’e taşımışlar ne yaptıysa değişmedi biz de elimizle tek tek bütün her şeyi değiştirdik. Nedendir bilinmez ama aşırı derece de sinir bozucu bir durum. Eğer kullanıyorsanız emin olun bu saçma şeyi siz de yaşayacaksınız.
Webapi nerede?
Webapi’yi komple kaldırmışlar. Aman dikkat kafalar karışmasın! MVC ve Webapi projelerini tek bir çatı altında toplamışlar. Artık her şey bizim için controller. Bir controller açıp rest apinizi yazabilirsiniz. Bence eksik bir durum yok aksine güzel olmuş. İlk geçişte “Ee Webapi nerede?” gibi bir kafa karışıklığı oluyor genelde, hiç karışmasın, gerek yok zaten. Çok temiz olmuş diyebilirim.
HttpWebRequest
Arkadaşlar HttpWebRequest kullanıyorsanız tümünü değiştirin daha kolay emin olabilirsiniz. Muhtemelen uğraşacağıma tek tek değiştirseydim 15 gün daha fazla zaman kazanırdım. Bazı property’leri nedense kaldırmışlar, sebebi net değil ama yeni getirdikleri sistem ile affettirdiler. Yeni getirdikleri HttpClientFactory yapısı o kadar iyi ki yıllardır aradığım şeyi built-in şekilde koymaları inanılmaz iyi olmuş. Bu çok güzel ve önemli bir konu ayrı bir makale derin detaylarıyla ele alacağım 🙂
Git ile dertler
Eğer branching mekanizmasıyla çalışıyorsanız ve bazı branch’leriniz geride kaldı ise checkout’lar esnasında çok vakit kaybediceksiniz, hatta VS donacak bozulacak vb. Derleme ve bir ton saçma ve gerçeği yansıtmayan şey göreceksiniz. “/bin” ve “/obj” klasörlerini temizleyince bunlar da gidiyor ama bu tip şeylere kendinizi hazırlayın şimdiden.
EF6 ve EF Core
EF core’da default halde proxy’ler relation yapıları gelmiyor. Bunları elle açmanız lazım. Eğer FK üzerinden virtual property’ler ile tabloları birbirine bağladıysanız hele ki lazy load /eager load gibi şeyler kullanıyorsanız. Projeniz neredeyse çalışmayacak seviyede olacaktır. Paniğe gerek yok! Tek yapmanız gereken EF Core’un bu yan library’lerini yüklemek ve bu özellikleri enable etmek. Abstraction ve Proxies nuget package’ları işinizi görecektir.
Sonuç olarak biz geçtik ve aşırı derece de memnunuz. Bizi memnun eden noktaları da bir sonraki makalemizde ele alacağız. Özetle böyle dertler yaşadık. Bu geçiş ile ilgili ilk yazımız, konuyla alakalı Docker ve .Net, yeni aspnetcore ve api yapılarıyla alakalı yazılarımız yolda!
Saygılarımla.
