Bir .Net Framework Projesini .Net Core’a Geçirirken Dikkat Edilecek Hususlar

PEAKUP’da kendi ürünlerimizin ihtiyacı olan bazı veriyi uygulama bazlı tutmak yerine tek bir merkezden sağlamak üzere uzun zaman önce geliştirdiğimiz bir “Data” projesi bulunuyor. Öncelikle biraz uygulamanın ne yaptığından ve neleri barındırdığından bahsetmek istiyorum. Projeyi henüz .NET Core ilk çıktığında geliştirmeye başlayıp, .NET Core’un biraz daha stabil hala gelmesini beklemek için .Net Framework ile geliştirdik.  Veri tabanı tamamen EntityFramework Code First ile tasarlandı. Veri tabanı olarak Azure SQL Server kullanıyoruz. Bu servis içerisinde hemen hemen her uygulamada ihtiyaç duyulan; kıta, ülke, şehir gibi coğrafi bilgilerin yanında 2020, 2021 yılı resmî tatil günleri, anlık hava durumu bilgisi ve döviz kuru ve benzeri gibi bilgiler yer almaktadır. Servis içerisinde verilerin sunumu için kullandığımız web uygulamasının yanında, hava durumu ve döviz için birden fazla kaynağa bağlanıp veri çeken ve bunları hem veri tabanına hem de Redis ile daha hızlı çıktılar vermek için Cache’e yazan iki Azure Job projesi daha bulunmaktadır.

Neden .Net Core’a Geçiş Yapıyoruz?

Öncelikle Microsoft’un .Net Core için uzun süredir yaptığı geliştirme eforuna ve olup bitene baktığımızda .Net Framework için uzun vadede geliştirmelerin bir süre sonra duracağını ya da kısıtlı bir hale geleceğini ön görebilmek hiç zor değil.  Anlatacağım birtakım şeyler .Net Framework ile de mümkün olsa da çıktılarının .NET Core kadar iyi olmadığı ya da süreç içerisinde ekstra zaman kaybına sebep olan bazı sorunlar yaşandığı aşikâr!

Projeye yakın zamanda eklemek istediğimiz; Image Compression, Video Compression gibi özellikler için arayıp bulduğumuz kütüphanelerin yalnızca .Net Core tarafında geliştirildiğini görmek, daha uzun vadede yapılacak geliştirmeler için bu eforu neredeyse yarı yarıya düşürmek anlamında çok önemli durumdadır.

Uygulamaya istek gönderen diğer PEAKUP ürünlerindeki kullanıcı sayısı giderek artarken dolaylı olarak tuttuğumuz hava durumu ve döviz verisinde de büyük bir artış gözlemleniyor. Uygulaya gelen istek sayısı ve verinin büyüklüğü arttıkça Response sürelerindeki artış ve hem web uygulamasının hemde kullandığımız SQL veri tabanının artık maliyet ve performans olarak bir probleme dönüşmesinin önünü almak en önemli sebepler arasında yer almaktadır.

Şu anda projeyi standart bir şekilde iki ayrı Git Branch’inde tutuyoruz. Geliştirmeleri Dev’de yapıp, her şeyin tamam olduğunu gördükten sonra master’a Merge edip bütün süreçteki Deployment faaliyetini manuel olarak yürütüyoruz. Sık sık açıp üzerinde geliştirme yaptığımız bir proje olmasa da bu sürecin Azure DevOps ile tamamen manuel ve elle Deploy edilir bir halden çıkartılıp. Otomatik olarak Deploy eden, veri tabanında Migration’ları kendisi çalışan bir hale doğru ilerlemesi arzu ettiğimiz bir geliştirme süreci, bunu .NET Core ile daha verimli ve daha hızlı bir şekilde yapmanın önü .NET Framework’e göre oldukça daha esnek zira proje içerisinde paket yönetimi daha kolay bir şekilde tasarlanmış.

PEAKUP tarafından tamamen SaaS olarak geliştirilen uygulamalara geçiş yapan müşterilerin, bütün süreci bir kerede tamamlayıp kullanıcılarına ürünleri duyurduklarına gelen sıra dışı yükü Scale etmek için uygulama tarafında sürekli Azure Servis Planları arasında geçiş yapmaktaydık. Bu hem maliyet olarak hem de uygulamayı Scale etmek konusunda Azure Web Application tarafında birtakım kısıtlamalara neden oluyordu. Azure DevOps ile uygulamanın tamamen Container’lara taşınarak hem kendini Scale Down yapıp hem de ihtiyaç durumunda sınırsız sayıda Container ayağa kaldırarak bütün taleplere, aynı ve hatta daha yüksek hızda cevap vermesi de olmasını istediğimiz özelliklerden birisiydi! Projeyi geçirdikten sonra yaptığım testler ile aslında Docker ve Kubernetes ile ilgili atılacak adımlar için çok erken olduğunu gördükten sonra web uygulamasıyla devam etmeye karar verdim.

Karşılaştığım Problemler ve Çözümleri

  • Routing’de Değişiklik

Üzerinde neredeyse yarım günlük efor harcadığım bu problemle karşılaştığımda geçişin ne kadar sancılı olacağını tahmin etmeye başladım. Proje içerisinde kullandığımız Interface tasarımında iki adet GET metodu bulunuyordu ve bunlardan bir tanesi tüm kayıtları ötekiyse aldığı Id parametresine göre verileri döndürüyordu. Net Core tarafındaki Routing ile ilgili hatalı tasarımların önüne geçilmek için bu daha izin verilmediğini araştırarak öğrendim. Bu nedenle metot içerisindeki Id parametresini Nullable yaparak duruma göre farklı davranan tek bir metot ile devam etmeye karar verdim.

  • Entity Framework Core’daki Değişen İsimlendirmeler

Projeyi geliştirirken kullandığımız modellerin tamamını .NET Core’a geçerken birebir kullandım. Auto Migration sayesinde veri tabanında çıkacak Schema’nın birebir olmasından emindim ancak .NET Framework tarafında ilişkilerin kurulduğu alan isimleri herhangi bir karakter değişimine uğramazken .NET Core’da ilişki için kullanılan alanlar arasında alt çizgi eklendiğini gördüm. Bu nedenle Schema’yı birebir kurmak ve direkt olarak Production’daki verileri taşıyabilmek için haliyle [ForeignKey(“X_Id”)] Attribute’undan faydalanarak kolonlardaki verinin eski standartlara uymasını sağladım.

  • Veri Tabanın Taşınması

Veri tabanında hiçbir veri kaybetmeden yaklaşık 12GB civarındaki verinin kopyasını Azure üzerindeki bir sunucuya çektim. Oradan kendi bilgisayarıma zipleyerek indirdiğim için 12GB civarındaki veriyi 900MB text olarak kendi makineme aldım ve verinin geçişi ile ilgili senaryoları denemeye başladım. Weather (eski hava durumu verisi), Forecast (yeni yayına aldığımız hava durumu verisi) ve Currency tabloları bu veri tabanındaki büyüklüğün başlıca sebeplerindendi. Bu nedenle bu üç tabloyu tek tek geçirerek ilerlemeye karar verdim. Denediğim senaryolar arasında SQL içerisinde adeta benchmarking yaptığımı söyleyebilirim.

Çektiğim dosyayı komple bir veri tabanı üzerinde ayağa kaldırıp ardından verilerin girişini sağlasam da işlemler hem uzun sürüyor hem de belli bir yerden sonra hata verdiğinde bütün süre boşa gidiyordu. Bu nedenle her bir satırın tek tek taşınması ve iki farklı veri tabanındaki Schema’ların birbiri arasındaki uyumu görmek için SQL Management Studio içerisinde varsayılan olarak gelen Import Data seçeneğini tercih ettim. Bu aşamada Entity Framework’ün tarih tipindeki alanlar için .NET Framework’de datetime, .NET Core’da da datetime2 veri tipi farklılığı yarattığını gördüm.

Tekrar projeye dönüp Datetime alanlarının başına [Column(TypeName = “datetime”)]

Attribute’unu ekleyerek bu alanlarında Schema’da veri geçişi için bu şekilde kalmasını sağladım ve verileri başarılı bir şekilde kendi makinamda 15 dakikada taşıdım.

Production’da artık bir EF Core veri tabanı ayağa kaldırmak için Web Uygulaması açarak hem veri tabanını hem de uygulamayı Deploy ettim. Burada .NET Core kullandığım için Linux tipindeki Web Application ile ilerlemeye karar verdim ve sonrasında bazı problemler yaşadım. Bununla ilgili bir sonraki adımlarda bahsettim.

  • Cache Katmanında Kütüphane Değişikliğine Gidilmesi

Hem performans hem de API tasarımı daha iyi olmasının yanında kendisine özel geliştirilen JSON kütüphanesi ile daha performanslı bir önbellek çözümü sunan ServiceStack.Redis kütüphanesini kullanmaktaydık. Ancak hem bu geliştirmeyi yaptığımız Nuget kütüphanesinin uzun zamandır güncellenmediği için bu faydadan uzak kaldığımız hemde Connection Pooling ile ilgili performansını yeterince göremediğimiz için StackOverFlow tarafından geliştirilen StackExchange.Redis kütüphanesine geçiş yaptım.

  • Text. Json’daki Kritik Eksiklikler

Microsoft’un .NET Core içerisinde hem performans hem de JSON işlemleri için uzun zamandır saplantılı bir şekilde System.Text ve altındaki bütün kütüphanelerde geliştirme yaptığını söyleyebilirim. Benchmarking testleri yapıldığında System.Text Namespace’ini kullanan bir çok projede neredeyse her Framework versiyonunda büyük bir performans artışı görüldüğünü uzun zamandır takip ediyordum. Hem Newton.Json hemde ServiceStack.Redis’in JSON kütüphanesinden kurtulmak için API’dan dönen JSON’ları ve Cache’e veri okuma-yazma işlerinde Built’in gelen bir kütüphanenin daha iyi olacağını düşünerek tahmin ettim. Ancak sonrasındaki hayal kırıklığı çok büyük oldu! Zira Newton.Json’dan geçişle ilgili yayınlanan Microsoft dokümanında PreserveReferencesHandling, ReferenceLoopHandling gibi birçok özelliğin henüz geliştirilmediğini gördüm. Bu nedenle Built’in gelen bütün kodu geriye aldım ve Newton.Json ’la devam ettim.

  • Linux Web Uygulamasında Azure Tarafında Tamamlanmamış Özellikler

Uygulamayı öncelikle elle test edebileceğim ve sonrasında performans testleri yapabileceğim, herhangi bir Pipeline beklemeden, Staging sonradan devam etmek üzere standart bir şekilde ayağa kaldırdım. Publish ederek işlemi başlattım ve o gün Azure’da yaşanan bir saatlik bir kesinti ile şans eseri karşılaşıp uygulamada bir problem olduğunu düşündüm. İki saatimi kaybettikten sonra Microsoft tarafında bir Incident yaşandığını ve çalıştığımız Avrupa kıtasındaki bazı işlemlerde problem olabildiği bilgisini aldım. O sırada uygulamanın sonraki adımlarını incelemek üzere diğer çalışmalara başladım. Fark ettim ki kesintiyi iyi ki yaşamışım!

Döviz ve hava durumu ile ilgili çektiğimiz verilerin bazıları anlık akarken bazılarıysa saatlik gelmektedir. Bunları uygulama içerisinden çıkmadan, Azure Job olarak zaten daha öncesinde de ilerletiyorduk. Aynı şekilde kalmasına ve olacaklar ile ilgili problemleri gözlemek için Web Application içerisinde Web Job sekmesini aradığımda sekmeyi bulamadım! Önce uygulamanın Tier’ı ile alakalı olabileceğini düşündüğüm bu problem için uygulamayı bir üst Tier’a geçirdim ve Web Job tekrar gelmedi. Sonrasında araştırdığımda henüz Linux tipindeki Azure Web Application’larda birçok şeyin eksik olduğunu öğrendim. Kesintinin bitmesini beklemeden direkt uygulamayı sildim ve Windows tipinde yeni bir web uygulaması açarak devam ettim.

Bu aşamada bu kararı vermemin sebebi Load testlerde yakalanacak başarıya göre yapının tamamen Kubernetes ve Container üzerinden devam etmesiyle ilgili oldu.

  • Load Testlerin Yapılması

Herkesin Email Marketing şirketi olarak bildiği SendLoop’un mühendislik takımı tarafından geliştirilen hem ücretli hem de ücretsiz bir aracı bulunuyor. https://loader.io/ adresinden erişebileceğiniz bu Tool ile her zaman önce ilk testin buradan geçmesini bekler sonrasında da Apache’nin AB projesi ile yük testlerini gerçekleştiririm. 10,000 isteğe kadar çıkan bu ücretsiz Tool ile ilk test oldukça başarılıydı. Response Time’da ciddi düşüşler görülüyor ancak uygulama belli bir süre sonra yavaşlamaya başlıyordu.

Azure içerisinde Web Application’da Memory’de anlamsız bir şişme ve bir yerden sonra 1MB boyutunda bile yer kalmadığını fark ettim. İstekleri incelediğimde Redis Cache içerisinde kullandığım metodun verinin verilen Key üzerinde OverWrite yerine AddAndWrite senaryosu ile ilerlediğini fark ettim! Hemen bu problemi çözüp paketleri güncelledikten sonra testlere devam ettim.

SendGrid tarafında isteklerin başarılı bir şekilde geçtiğini gördükten sonra AB Tool’u ile testler yapmaya başladım. Bunun için internet bağlantısı çok iyi olarak bir sunucuyu kullandım. Artık her şey hazır ve DevOps’daki son adıma geçebilirdim.

  • DevOps Pipeline Kurulumundaki Yenilikler

Projeyi artık istek alır hale getirdikten sonra makalenin girişinde de bahsettiğim Production, canlı ortam ve son kod geliştirmesiyle birlikte çalışan Beta ve DEV olacak şekilde üç Stage’e ayırmaya başladım. Önce Master yani Production sonrasında da silsileyi takip edecek şekilde geçişleri tamamladım. Her bir Stage için ayrı veri tabanı açtım ve hepsini Master’dan taşımaya devam ettim.

Azure’un DevOps Pipeline’ında yaptığı bir arayüz değişikliği ile ilk defa karşılaştım. Artifact çıktısını Release adımına geçirirken burada bir Versionlama sistemiyle artık kütüphane alt yapısının yani ConnectionString, özel anahtarlar gibi ayarlar ile ilgili yapılan değişikliklerin de bir Step olarak eklendiğini öğrendim.

.NET Core, .NET Standart ve Felsefe Taşı – Part II

Previously on : .NET Core, .NET Standart ve Felsefe Taşı – Part I

“It does not do to dwell on dreams and forget to live.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

J.K. Rowling’in de dediği gibi, hayal dünyasının içerisinde hayat sürüp yaşamayı unutmak pek olmuyor. İşte PCL’ler hayatımıza böyle girmişti fakat, hayal dünyasının içerisinde, yani teoride mantıklı bir yaklaşım, gerçek hayata uyarlandığında pek de tutarlı olmadı, olamadı. Çok mu abarttım? Olabilir. Ama bu ortada çözülmesi gereken bir durumun olduğu gerçeğini değiştirmiyor.

Soruyu tekrar alabilir miyim?

Ha, şu soru. .NET Standart neden var? Ondan öncesinde PCL’ler neden var diye sormamız gerekiyor değil mi? Çözmeye çalıştığı problem aslında yazdığınız kodların farklı .NET proje tiplerinde kullanılabilmesini sağlamak. Peki neler bu proje tipleri ? .NET Framework, Silverlight, Windows 8 (Metro), Windows Phone, Xamarin, Mono, Universal Windows Platform (UWP), XBox 360, liste daha uzuyor.

enter image description here

Evet, tabii, güzel fikir. Bir çok ihtiyacı da karşıladı aslında, bu sebeple tamamen kötülemek doğru olmaz ama bir süre sonra bu yaklaşımın eksikliklerini görmeye başladık.

Nerede benim API’ım ?

dotnet-today

Birinci problem, PCL altyapısı, uygulamayı yazarken kullanabileceğiniz API’ı, desteklemeye çalıştığınız platformların kesişimine göre belirliyor. Bir platformda olan bir API diğer platformda yoksa, o kısım çıkartılıyor. Örneğin Xamarin.iOS, Xamarin.Android ve UWP için yaratayım bir PCL dediğinizde, yapacağınız dosya okuma ve yazma işlemleri artık düşündüğünüz kadar kolay olmuyor. Çünkü bir tarafta System.IO varken, diğer tarafta Windows.Storage var. Kesişimin içerisinde bu iki API da yok. Yani, var da yok. System.IO namespace olarak var ama tanıdık olduğumuz File ve Directory yok mesela. Bu sefer kulağınızı tersten tutmaya ve şuradaki gibi bir guide’ı takip etmeye başlıyorsunuz. Bu da size hayatınızı ve mesleki kararlarınızı sorgulatabiliyor. Halbuki sadece bir dosya okumak istemiştiniz. Bu tür eksiklikleri kapatmak için ortaya PCLStorage gibi paketler çıkıyor ama bu nedense yama hissiyatı yaratıyor. Her kombinasyonda eksik kalan parçalar ve o eksiklikleri kapatmaya çalışan paketler. Sonu gelmez bir döngü.

Ama Cross-Platform oluyor değil mi ?

Aslında tam değil. Yazdığınız kod her platform için ayrı ayrı derleniyor. Evet, bir PCL paketini NuGet üzerinden çekerken bütün desteklenen platformlar için derlenen dosyalar da yanında geliyor. Şimdi, bundan iki yıl sonra başka bir .NET platformu çıksa – ki bu hızda giderse hiç de düşük bir olasılık değil – bu paket o platformda çalışacak mı? Tabii ki hayır. Çünkü paketin, bu platform da eklenerek tekrar derlenmesi gerekiyor. Bu arada kaybedebileceğiniz API’ları da bir yandan düşünseniz iyi olur. Onlara da bir “yama” gerekecek.

.NET Standart

Yani bu iki büyük soru işaretine karşı çözüm olacak yapının, öncelikle stabil bir API sunması gerekiyor. Bu ise, hali hazırdaki platformların bu API’ı implemente etmesi gerektiği anlamına geliyor ki geliştirmek istediğim platformlara göre erişebildiğim API oranı azalmasın. Aynı zamanda, sonrasında geliştirilebilecek diğer platformların da aynı API’ı implemente etmesi sağlanırsa, bu yapı için derlenen paketlerin de gelecek platformda çalışması sağlanabilir.
Buradan ise yapının görevinin, bütün .NET platformları için ortak bir API sunmak ve bunun devamlılığını sağlamak olduğunu söyleyebiliriz ve iki soru işaretimiz de böylece ortadan kalkmış olur.

Sonuç olarak ortaya .NET Standart çıkıyor.

.NET Standart sayesinde artık tek bir API kullanarak, .NET Standart API’ını implemente etmiş olan bütün .NET platformlarını destekleyebiliyoruz. Yakın zamanda 2.0 versiyonu çıkan .NET Standart tarafından desteklenen API setinin içerisinde Networking, IO ve Threading gibi önemli yapı taşları mevcut.

netstandard-apis

Bir süre sonra PCL’ler yerini .NET Standart’a bırakacak. Kişisel kanaatim, .NET Standart’ın çok daha iyi bir yaklaşım olduğu yönünde. Umarım yakın zamanda bir standarta daha ihtiyaç duymayız.

“The truth.” Dumbledore sighed. “It is a beautiful and terrible thing, and should therefore be treated with great caution.” ― J.K. Rowling, Harry Potter and the Sorcerer’s Stone

Bir sonraki yazıda görüşmek üzere.

.NET Core, .NET Standart ve Felsefe Taşı – Part I

Merak etmeyin, bu yazının ne Harry Potter, ne de maddeyi altına dönüştürme ile bir ilgisi yok. Bu yazı dizisinde daha çok, .NET Core ve .NET Standart’ın kendilerini, ortaya çıkmalarındaki nedenleri, ekosistemde yapacakları değişiklikleri ve bizim bu değişikliklere nasıl ayak uydurmamız gerektiği ile ilgili konuşacağız.

Giriş

Yakın zamanda .NET Core 2.0 ve ASP.NET Core 2.0 duyuruldu. Bir çok değişiklik ve güzel haber var fakat boşverin, şimdi oradan kopup, biraz daha geriye, bütün bunların başladığı zamana gidelim. Fazla değil Kasım 2014’te Microsoft, .NET Core’u (CoreFX) Open Source yaptı. Tabii kimse .NET Core’un ne olduğunu bilmiyordu. Blog yazısında, aslında bu teknolojinin içeride ASP.NET 5 (vNext) ve .NET Native’de -ki başlı başına ayrı bir konu- hali hazırda kullandıklarını, gelecekte .NET platformunun temel taşının bu yapı olacağını söylediler. Open Source olmasındaki sebep ise, .NET’in arkasında daha güçlü bir ekosistem oluşturmak ve cross-platform bir hale getirmek için hazırlıklara başlamaktı.

.NET Core’un arkasındaki ana sebep ise, .NET Framework yaklaşımının pek de doğru olmaması ve bunu değiştirmeye yönelik çalışmalar yaparken de aynı zamanda zaten olması gereken cross-platform desteğini de göz önünde bulundurmaktı. İki amaç da zamana göre daha fazla önem kazanabilir.

.NET Core’un alt yapısını anlatmadan önce size .NET Framework yaklaşımını ve yanında getirdiği problemleri biraz daha açmam gerek.

Bir Sorunun Tanımı

Yukarıdaki ekranı hatırladınız değil mi? Hiç görmediyseniz eğer ne mutlu size, bugünün şanslı 10.000 kişisinden birisiniz. Özetlemek gerekirse, yüklediğiniz bir uygulama, çalışmak için .NET Framework’ü gerektiriyor ve önce onu yüklemeniz gerek. Bunun sadece Windows içerisinde karşılaşılan bir durum olduğunu söylemiyorum, keza diğer sistemlerde yüklediğiniz paketler, başka paketleri gereksinim olarak isteyebiliyor, fakat buradaki ana sorun teknik değil. Ana sorun, yukarıdaki problemin son kullanıcı tarafından çözülmesinin beklenmesi. Aynı zamanda bu paket öyle elzem ki, bütün .NET uygulamaları* kullanıyor ve versiyonları var. Uygulama hangi versiyonu kullanıyorsa ona göre yüklenmesi gerek. Yukarıdaki “Yes” butonuna basınca sizi o paketin indirme sayfasına yönlendiriyor, siz de inen paketi kuruyorsunuz. Tabii paket kullandığınız işletim sistemi tarafından destekleniyorsa. Örneğin Windows 7 kullandığınızı varsayarsak ve açmaya çalıştığınız uygulama .NET Framework 4.6 kullanıyorsa eğer, SP1 yükseltmesini önceden yapmış olmanız gerek. Yapmamışsanız uygulama çalışmıyor. Yani bir uygulamayı kullanmak için önce sistem güncellemesi, sonra paket kurulumu ve en sonunda kullanmak istediğiniz uygulamanın kurulumunu yapmanız gerekebilir. Bu arada bütün bunları teknik bilgisi fazla olmayan birinin yapmaya çalıştını düşünürseniz, durum pek iç açıcı değil.

Diğer bir sorun, bu kütüphanenin içerisinde herşeyin olması. Siz bir uygulama yazarken sadece küçük bir kısmını bile kullansanız, bu o uygulamanın .NET Framework kullandığı gerçeğini değiştirmiyor. .NET Framework 4.6’nın kurulum paketi 62.4 MB. Kurulum sonrası boyutu 100 MB’ı aşıyor. Amacı iki sayı toplamak olan bir konsol uygulamasının çalışması için de bu kütüphanenin kurulması gerek.

Ha bu arada yukarıdaki bu iki uygulama da diğer işletim sistemlerinde çalışmıyor.

Sanırım yavaş yavaş problemin kaynağının ne olduğunu ve nasıl çözülebileceğini düşünmeye başlamışsınızdır. Öyle bir şey olmalı ki, uygulama herhangi bir dış kaynağa gereksinim duymamalı, yani kullandığı paketleri yanında götürmeli.

* = Bütün .NET Framework uygulamaları yani WinForm, WPF, ASP.NET gibi.

Bir Efsanenin Doğuşu

.NET Core işte bu fikrin hayata geçmiş hali. Tabi şu “kullandığı paketleri yanında götürmesi” kısmı için .NET Framework parçalara ayrıldı ve çoğu paket NuGet üzerinden referans edilebilir hale getirildi. En temel parçalar (CLR ve içerisindeki GC ve JIT) ise cross-platform çalışması için baştan yazıldı ve .NET Core CLR oluştu. Tabii hepsinin cross-platform çalışması için değiştirilen bir çok yaklaşım da oldu.

Peki Web?

ASP.NET 5 (vNext) yani ASP.NET Core ise, .NET Core’un üzerine ASP.NET mimarisinin bindirilmesi ile oluşmuş bir platform. Ocak 2016’ta ASP.NET 5 adı ASP.NET Core olarak değiştirildi çünkü ASP.NET  5 sanki ASP.NET 4.5’in bir üst versiyonu gibi anlaşılıyordu. Halbuki ASP.NET 5,  yapısal anlamda ASP.NET 4.5’i andırmıyordu bile ve bu insanlarda kafa karışıklığı yaratabilirdi. Bu sebeple isim değişikliğine gidildi.

Soru İşaretleri

Peki .NET Standart bunun neresinde. Bugün itibarıyla üç tane .NET platformu var; .NET Framework, .NET Core ve Xamarin. Her birisinin amacı ve kullandıkları altyapılar farklı. Tabii bu kullanılan dil aynı olsa bile oluşan paket uyuşmazlığı, yazılan kodların platformlar arası kullanılmasını engelliyor. Zaten her biri programlayan kişiye farklı API’lar sunuyor. Yani her türlü yazılan kod belirli bir platforma özel olmuş oluyor. Bu sorunu çözmek için üretilen PCL ise sorunu daha da büyük bir hale getiriyor.

Part II’de ise .NET Standart’ın ne olduğunu ve yukarıdaki probleme nasıl bir çözüm getirdiğini göreceğiz.

.NET Core, .NET Standart ve Felsefe Taşı – Part II