.Net’ten .Net Core’a Adım Adım Geçiş Rehberi
Merhabalar herkese,
Bir önceki .Net’ten .Net Core’a geçtik, ne sıkıntılar yaşadık? yazımda ele aldığım .Net Core geçişimizdeki sıkıntılarımızdan bahsetmiştim. Bugün size bunu yaparken bizim izlediğimiz yolu anlatan bir yazı hazırladım.
.Net Core çıkış yaptıktan kısa bir süre içinde çok hızlı bir kullanıcı kitlesinin dikkatini çekti. 2.0 versiyonu ve .Net’ten geçiş için tasarlanmış bir shared library olan netStandard ile en fazla tercih edilen yapılardan biri oldu. Her .Net geliştiricisinin aklındaki soru “.Net Core’a geçmeli miyiz, yoksa .Net’te kalalım mı?” Bizde bu soruyu sorduk ve şöyle cevaplar edindik.
.Net Core vs .Net Framework
Microsoft göründüğü üzere 2 framework’ü de aktif olarak geliştiriyor. Uzun süre de bunu destekleyeceğini açıkladı. İhtiyaçları dolayısıyla .Net Core’a (dotnet) geçmek isteyenler ne yapacaktı derken Microsoft çok güzel bir hamle yaparak PCL library’lerindeki mantığı ileri bir seviyeye taşıdı ve Shared API ile netStandard’ı oluşturdu.
Bilinmesi gereken en önemli şey hala C#, F# tam destekli şekilde .Net Core’da devam ediyor. VB.Net için aynısını söyleyemiyoruz çünkü resmi olarak support var ama çok az bir miktar. Microsoft’un takımı da flagship’leri olan C# dilini kullanmamızı istiyor. Bence biraz haklı gibiler.
Ne zaman .Net Core(dotnet) kullanmalı?
En önemli olarak .Net Core’un tamamen open-source ve cross platform bir framework olduğunu belirtelim. En fazla microservices yapısını benimsemiş firmalarda kendine yer buluyor. Eğer sizde cross platform istiyorsanız, yazdığınız uygulama macos, linux farketmeden çalışsın istiyorsanız zaten şuan başka seçeneğiniz yok gibi bir şey diyebilirim. Docker’a kolay adaptasyonu gerçekten çok başarılı. Çok iyi seviye bir console desteği ile çok başarılı scalable, yüksek performanslı uygulamalar yazabilirsiniz. Bunlar en temel özellikleri diyebilirim bunlar sizin ihtiyacınızsa hemen aşağıda anlattığım analizlere başlayıp geçişi planlamaya başlasanız iyi olur. Sonuçta Linux daha ucuz 🙂
Ne zaman .Net Core kullanmamalı?
WPF, Win Forms, Asp.Net WebForms, WCF, Workflow(WF), Windows API gibi şeyler yazıyorsanız .Net Core geçişini baya bir erteleseniz iyi olur. 3.0 versiyonu ile wpf, win forms gibi şeylerin geleceğini söylediler ama ilk anda nasıl olur kimse emin değil. 3.0 release’inden sonra incelerseniz ve ihtiyaçlarınız orada var ise o zaman düşünürsünüz ama şuan minimum Şubat 2019'a kadar beklemede olacaksınız.
Ayrıca sizin kullandığınız bazı feature’lar .Net Core’da olmayabilir. Kullandığınız nuget pakedinin desteği bitmiş ve .Net Core’a destek vermiyor olabilir. Bu noktada o library’leri tek tek kaldırmanız ve kodunuzu düzenlemeniz gerekecektir.
.Net’te olup .Net Core’da olmayanları şöyle bir sıralarsak;
Memory management
Memory safety
Security
Networking
Data structures
Windows APIs
AppDomains
Remoting
Security Transparency (Silverlight)
Memory Mapped Files
Buraya kadar okudunuz ve bunları ben zaten kullanmıyorum ya da vazgeçebilirim, .Net Core’a geçebilirim diyorsanız gerisi sizin için!
Porting Reçetesi
İlk olarak iş listemiz aşağı yukarı şu şekilde olacak;
1 — 3rd party dependency’lerinizi tespit edin.
2 — Her projenizi (csproj) target framework’ünüzü minimum .Net 4.6.2 yapın. Eğer uygunsa en son sürüme çıkarın.
3 — Microsoft’un çıkardığı şu extension’ı kurun ve tüm projelerini taratın. (https://marketplace.visualstudio.com/items?itemName=ConnieYau.NETPortabilityAnalyzer)
4 — Library’lerinizi netStandard’a taşıyın eğer target’ınız .Net Core 2.0+ ise hiç düşünmeden netStandard 2.0'a taşıyın.
5 — Unit testlerinizi .Net Core’a çevirin.
Burada önemli bir nokta olarak; piyasadaki bilinen neredeyse tüm unit test framework’leri .Net Core’a destek veriyor. O açıdan ilk bunları çevirirseniz iyi olur.
Bu değişiklikte eğer MVC,API vb. bir yapınızı UI test, Integration test vb. şekilde test ediyorsanız bunları biraz sonraya bırakırsanız iyi olur çünkü ana projelerin geçişini yaptıktan sonra bunları geçirmekte fayda var.
6 — DB/ORM’lerinizi analiz edin ve planlayın.
7 — Multiple Target ihtiyacınız varsa Solution yapınızı buna göre düzenleyin.
8 — Multiple Target iseniz testlerinizi de multiple target yaparak test edin.
9 — Ana projelerinizi taşıyın. (API ve MVC’ler için global.asax vb. yapıları temizleyip tekrar yazmanız gerekecek.)
10 — Planı başlat! (Engine Ignition Start!)
3rd Party’ler ve analiz
3rd Party dependency’lerinizi tespit edin. Eğer sizin kullandığınız kendi Nuget repo’larınız varsa bunları da dahil edin ve matematik gibi düşenerek parantezin en içinden başlayarak yapın. Bu bizim için paylaşımlı olarak kullandığımız Enum, Constant, Helper vb. bir çok yardımcı yapıların bulunduğu projemizdi. Buradan başladık ve ihtiyaçları listeledik.
Daha sonra projeleri kademeli olarak hepsini en güncel .Net Framework’üne çektik. Paketlerin ve library’lerin detaylı analizi için bir arayış içindeyken Microsoft’un bu extension’ı denk geldi. ve bir çıktı üretti. Bu çıktı bize neyi dönüştürebiliriz, nereler bozulacak ve ne kadar sürede düzeltiriz gibi fikirler verdi. Buna göre yol haritamızı çizdik.
NetStandard 2.0'a geçiş
Üstteki resme göre zaten ASP.NET Core’a geçiş imkansız gibi duruyordu. İlk olarak en dipte yer alan library’lerimizden başladık. Bunları sırasıyla netStandard 2.0'a geçirdik. Bununla beraber O kırmızılıklar gittikçe azaldı. Sonra tüm 3rd Party’leri en güncel hallerine geçirdik. Tabi bunu yaparken patch note’ları dikkatli okuyun, benden söylemesi. Her şey en güncel hale gelince ve çok büyük kısmı %85–90 skalasına geldi. Standard’a geçiş inanılmaz kolay oluyor. Yapmanız gereken bir kaç yöntem var. En temiz olarak sıfır bir proje açıp *.cs dosyalarınızı taşıyıp, library’leri tek tek kurabilirsiniz, inanın zahmeti daha az olur. Eğer SOAP vb. entegrasyonlar var daha kolay olacaktı ama elinizde wsdl’i vs. olmayan şeyler varsa biraz saçma durumlar olabiliyor bunun için wsdl’i ya edinin ya da mevcuttakini kopyalayıp fiziksel bir dosya olarak bulundurun. Fiziksel olarak dosya elinizdeyse MS yine harika bir iş çıkartarak WCF Reference Provider yaratmış, kullanımına bu linkten ulaşabilirsiniz. https://docs.microsoft.com/en-us/dotnet/core/additional-tools/wcf-web-service-reference-guide
Dostça bir uyarı olarak, SOAP tüm service’leriniz async olacak 🙂 Eğer projeniz async değilse ya da async’ten korkuyorsanız size de bu başlığa yönlendireyim, benim bir kaç durumumu bu çözdü, https://stackoverflow.com/questions/9343594/how-to-call-asynchronous-method-from-synchronous-method-in-c
Eğer bizim gibi işleri zor yoldan ama sindire sindire yapacaksanız csproj’u direk editleyebilirsiniz. Uzun uzun size bunu anlatmayacağım ama saçma durumlar olabilir baştan uyarayım. Bunun için tek bir guide’ımız oldu o da bu linkte https://docs.microsoft.com/en-us/dotnet/core/tools/csproj
Burada dikkat etmeniz gereken şeyler, 3rd party’lerinizi csproj içine yazıyorsunuz aman dikkat. Ayrıca burada Compile, Runtime, ContentFiles, Build, Analyzers gibi bazı keywordler olacak onları 3rd party’leri eklerken dikkatli kullanın ( ya da otomatik yapın).
Eğer cross platform uygulamanız olacaksa sadece Linux gibi bir target’ınız yoksa RuntimeIdentifiers diye bir bölüm var, oradan win10-x64;ubuntu.16.04-x64 gibi self contained deployment helperını ekleyebilirsiniz. Ayrıca CI’ınız varsa DotNetCliToolReference sizin hayatınızı kolaylaştıracaktır. Kurabileceğiniz bazı tool’lar buradaki Github adresinde bulunuyor. https://github.com/natemcmaster/dotnet-tools
İnanılası güç ama neredeyse herşey var. Meraklısı dotnet tool install -g nyancat yazdıktan sonra nyancat komutunu çalıştırıp cli nelere kadir bakabilir 🙂 Hatta bazen üşengeçliğim tutuyor cli ile GUID, Hash ürettiğim bile oluyor. Favori tool’um ise bir devops meraklısı olarak dotnet-sonarscanner ve dotnet-outdated!
Önemli bir not olarak, Properties altındaki Assemblyinfo.cs dosyasını, package.config dosyalarınızı direk silin artık kullanmıyoruz. Duruma göre app.config de silinmesi gerekebilir.
Unit Test ve .Net Core
Biz xUnit.Net kullanıyoruz. Zaten .Net Core’da destekleniyor. Nunit ve MsTest’te destekleniyor. Muhtemelen bunlardan birini kullanıyorsunuz. Ekstradan AutoFixture, Moq, FluentAssertions gibi şeylerde kullanıyoruz. Bunların da tamamı destekleniyor. Tek yapmanız gereken üstteki gibi ya csproj edit ya da yeni proje açıp taşımak ve library’leri kurmak. Yapı olarak netStandard bir unit test projesi açılmıyor, açtığınız .Net Core projesi de console app olmak zorunda. En kolay geçiş adımı bu diyebilirim. Zaten netStandard’a taşıdığınız library’leri otomatik olarak buradan kullanabileceksiniz. Testleri de bir tur çalıştırıp emin olduktan sonra yolunuza devam edebilirsiniz.
Sadece Selenium, Integration test, web host gibi şeyler kullanılıyorsa onları tüm projeleri taşıdıktan sonra yaparsanız ruh sağlığınız açısından daha iyi olur.
DB/ORM taşıma
Geldik en eğlenceli bölüme! Gerçekten bu adım size inanılmaz kolay da gelebilir, inanılmaz sıkıntılar da çekebilirsiniz. Biz kısmen kolay kısmen kahreden bir geçiş yaşadık. Malum uzun süredir geliştirilen bir yapımız var, yer yer mantıklı güzel yerler olsa da bazı tablo ve db yapıları inanılmaz relation’lara sahip bu da bir ORM’de relation management açısından en sıkıntı şey. Daha önceki yazımda da bahsettiğim Entity Framework’ün en belalı işleri proxy ve lazy loading işleri. O yazımda tabiki sadece EF’i ele almıştım. Şimdi işler değişti. Yeni versiyonu gibi görünen EF Core aslında tamamen yeni bir oyuncu. Gerçekten öyle! Sonunda sesimizi duyup lazy loading ve proxy gibi şeyleri ayrı paketler ile dağıtıyorlar. Bunları isterseniz ekleyip kullanabiliyorsunuz ki lazy loading’i bu sefer yapabilmişler. Gerçekten ben de şaşırdım ama sonuçta kaliteli developer’lardan oluşan bir ekip söz konusu ayrıca open-source! Hal böyle olunca lazy load gerçekten tam olarak lazy olmasa da çağrılmadan query atmıyor ama ilginçtir ki query’i translate ediyor ve memory’de tutuyor, virtual object’inize dokunduğunuz anda bi anda sql query’i çalışıp size dönüş yapıyor. Çoğu durumda bu çalışıyor çünkü bir class create etme vb. işler için DI Framework’ünüz vardır, eğer built-in yeni DI’ı kullanırsanız bunu yapmıyor ama bizim gibi SimpleInjector ve Castle kullanırsanız bu property hit alabiliyor ve size ekstra bir query olarak dönüyor. Bunun için bir kaç option buldum ama bu yazının ana konusu olmadığı için burada konuyu park ediyorum.
Eğer Ado.net yazıyorsanız şansınız fena değil diyebilirim. DataTable .Net Core 2.0 preview versiyondan itibaren hayatımızda bu şekilde SP ve query class’larınızı sizin bildiğiniz (old school) yöntemlerle devam ettirebilirsiniz. Bazı noktalarda ufak tefek destek dokunuşları gerekebilir ama bunu build anında zaten farkedeceksiniz. Şaşırtıcı bir şekilde build oluyorsa genelde çalışıyor. En azından bizim için öyle oldu. Unit testleriniz varsa bu aşama baya kolay olacak diyebilirim.
Eğer EF varsa işte orada işler biraz ilginçleşiyor. İlk olarak DbContext Base class’ınız artık farklı parametreler alıyor. Bunları sağlamanız gerekiyor. Model’leri update etmeniz pek gerekmiyor ama multiple Key kullanımız varsa ya da hiç Key olmayan model’leriniz varsa bunları düzenlemeniz gerekecek. DB ile birebir olması gerekmiyor ama kendi iç yapısı için One Key Per Table gibi bir not düşmüşler source kodlarına, bu da ilginç doğrusu.
EF 6'da olup EF Core’da olmayan özellikler ise şöyle;
EDMX
DB First için Data Model Wizard
Object Context API
DB Interceptor’lar yok gibi bir şey
Automated migration
Many-to-many (bu neden yok diye bir açıklamaları var ama hoş değildi, alındım)
Entity Splitting
SP mapping
Olanlar daha güzel tabi 🙂 mesela;
Batch insert, update, delete
Relationship config
Shadow properties
Alternate keys
Field mapping
Pooling
Disconnected graph
In-memory (test için)
EF 6'yı sözde ASP.NET Core ile kullanabiliyorsunuz ama biz hiç denemedik. Sonuçta bir şey native değilse çakma çözümlerle iş nereye varacak dedik ve es geçtik. Map’lediğimiz SP’ler için iyi bir çözüm bulamadık, bunun için bir extension yazıp SP ve dönüş tipini verilen type ile döndüren bir yapıyla işin içinden sıyrıldık. Tüm SP çağıran noktaları da buna göre düzenledik. Hatalı bir çok relation buldu ve dbcontext’ler tabi ki ilk denemede ayağa kalkmadı. Daha uygulama ayağa kalkmadan “Context’ler çalışabilir durumda mı, hata var mı?” diye bakmak isterseniz EnsureCreated() methoduna bir bakın derim. Bu sayede exception’ları düzelte düzelte bir kaç yüz deneme de ayağa kaldırdık. Sonuç olarak daha az relation’lı bir db yapısı elde ettik 🙂
EF Core için migration + performans rehberi gibi bir yazı yazmayı hedefliyorum, bu konuları daha derin bir şekilde ele alacağım.
Multi Targeting
Multi target genel haliyle aynı solution içinde .Net462 ve .Net Core’a aynı anda kullanımı da dahil ediyor. Genelde tek bir solution üzerinden bir den fazla OS ya da framework versiyonu desteği diye de duyabilirsiniz. .Net ekipleri bunu tam olarak çözdü denemez ama elimizde işe yarar çözümler var. Destek vermeniz gereken durumlarda sizi öksüz bırakmıyorlar.
Burada .Net ekibi 2 çözüm öneriyor.
Mevcut projeleri tek bir projeye birleştirmek.
Mevcut projeyi tutup, yeni bir .Net Core projesi oluşturup ikisini de solution’dan yönetmek.
2.sini denedik gerçekten çok büyük failler yaşadık hatta hala yer yer yaşıyoruz. Taşımanın mantıksız olacağı bir noktada tamamen yok olacağı için gereksiz efor olan bazı projelerimiz hala .Net’te bu da yüküyle beraber geliyor. Eğer sizin de böyle bir durumunuz var ise, solution dosyalarınızı (*.sln) çoklayıp yönetmeniz en iyi yöntem. Çünkü tek bir solution kullanınca CI’da hem msbuild hem dotnet ile package yönetimi yapmanız gerekiyor. Bu da CI’da çok fazla workaround demek oluyor. Sistemciniz size bu konuda baya bir sitem edebilir.
Resmi öneri 1; aşağıdaki gibi bir yapı ile kod içinden ve csproj ayarları ile destek vermeniz yönünde. Bunları yapabilmeniz için preprocessor’lara ihtiyacınız var. Şu linkten preprocessor’lar hakkıdna detaylı bilgi alabilirsiniz. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-if
Preprocessor’lar şu meşhur “#if DEBUG” şeklinde yazılan kısımlar. Bunu aynı şekilde “#if NET462” gibi yazabiliyorsunuz. Framework-specific kodlarınız varsa burada ihtiyacınız olacak. Biz bunu Directory için kullandık. Linux ve Windows’ta farklı dizin formatları olduğu için burada baya bir hayat kurtardı. Sizinde buna benzer durumlarınız var ise bu şekilde kullanabilirsiniz. Temel alacağınız nokta ise OS farkları ya da framework farkları olacaktır.
Resmi öneri 2; aşağıdaki gibi bir yapı ile çoklu proje desteği ile hepsinin kendi klasör altyapısında olacak şekilde düzenleyebilirsiniz. Bu şekilde bir publish vb. gerekiyorse Net45 projelerinden publish edebilirsiniz. Bu şekilde herkesin ruh sağlığı daha iyi olur. Bu arada net olması için detay vereyim, burada .Net ve .Net Core projeleri birbirinin kod olarak replikası yani aynı kodları içeriyor, farklar framework level’ında yani API’de middleware’ler varken API.Net45'te global.asax var gibi gibi.
Bu da Hesapkurdu önerisi ise şöyle;
Denendi onaylandı 🙂
Burada bir kaç önemli noktaya değinmek istiyorum. Biz eski halini de tutmamız gereken bazı durumlar vardı ve böyle 2 solution halinde yönetiyoruz CI’ımız bunlara göre kurgulandı eski CI yapısını legacy’i okuyacak şekilde yaptık yenisini sıfırdan yazdık, bu şekilde eski yapılara desteği minimum sıkıntı ile atlattık.
Diğer bir nokta ise şu bizim birden fazla API’miz var ve bazı api’lerimiz bazı sebeplerden dolayı .Net ile hayatına devam edecek. Bu apiyi Legacy Solution’ına dahil ettik. Yani her solution’ımızda farklı projeler söz konusu, tabi .Net olan projelerde çok aktif geliştirme yapmadığımız için onlar bizim durumumuz için çok rahatsız edici değil. Zaten gün içinde görmüyoruz bile.
MVC ve WebAPI’yi taşıma
Daha önceki yazımda da bahsettiğim gibi artık API diye bir şey yok. Ya da farklı bir bakış ile artık her şey API. Veda edeceğimiz şeylerin başında meşhur ApiController parent class’ımız geliyor. Bu liste baya uzun veda edeceğimiz listeyi baştan vereyim de onun üzerinden gidelim 🙂
Veda listesi;
- ApiController
- Global.asax
- Properties->AssemblyInfo
- RouteConfig
- Package.config
- Web.config (var ama tam öyle değil 🙂)
- Webpages
- IHttpActionResult
- System.Web.Http
- HttpResponseMessageGenerators
- MediaTypeFormatter (var ama başka yerde başka isimle)
- HttpContext (üzdü)
- HttpModules
- Bana göre IIS’de bu listede
Bunlar gitti en çok HttpContext üzdü, çok kullanırdık HttpContext.Current diye ama çok da üzülmedik performansı kötüydü. Çok lazımsa aynı objenin taşıdığı dataları taşıyan başka bir obje var bunu singleton yapıp kullanabiliyorsunuz. İsmi aynı ama içeriği kısmen farklı, kullanınca göreceksiniz. Giden gitti ama bu sefer olay çok farklı oldu, gelen gideni aratmadı hatta bunca sene niye bunu getirmediniz bizi o eski hantal yapılara mahkum ettiniz dedirtti. Güzelliklerini say say bitmeyen bir yapı geldi. Kestrel ve Middleware’ler inanılmaz derece güzel bir yapı, bunca senedir bu kadar framework değiştirdim ama bu kadar hafif ve işe yarar bir şey görmemiştim. Kaliteli mimarların elinden çıkan bir ürün olduğu daha ilk dakikadan hissediliyor. Vedaya liste yaptık, bi’ liste de yeni gelen ışıltılı feature listemizi yapalım.
- Middlewares
- Kestrel
- Built-in DI (dependency injection)
- JS framework desteği (SPA)
- Tag Helpers
- Environment spesific kod
- Built-in şekilde ve localhost’ta test edilebilen HTTPS yapısı
- Asset yönetim modülü
- Webpack desteği
- Built-in logging
- Gelişmiş HTTP header desteği
- Automated anti-forgery tokens
- Cache desteği (Redis dahil)
- Cookie-based tempdata
- Websockets
- Url Rewriting
- Response caching (memory)
Bunlar sadece en başta gelenler, yüksek performans ve cross platform cabası oluyor. E tabi kolay dockerize edilebilir bir yapı da olması baya güzel olmuş. Hatta bir tane buton koymuşlar basınca uygulama otomatik dockerize oluyor ve Dockerfile generate ediyor. Bana göre baya güzel bir feature listesi.
Konumuza dönecek olursak, veda ettiklerimizi silip oralarda yazdığımız kodları entegre etmemiz gerekiyor. Global.asax’da vb. uygulama ayağa kalkarken ilk okunan tüm yapıları startup içerisinde tekrar yazmanız gerekecek. Middleware yapısında request handler, exception handler gibi yapılar kurup buraları daha da güçlendirebilirsiniz. Bunları yaparken yukarı da bahsettiğim netStandard geçişiyle işleriniz baya kolay olucak. Tam da bu noktada EF Core geçişini yapmış olmanız ya da yapıyor olmanız gerekli. Startup içerisinde tüm dbcontext’leri register etmeniz gerekli. EF Core geçişiyle bu api/mvc geçişi aynı anda olması gerekiyor. EF Core legacy’de EF de .Net Core’a uygun değil. Hiç uğraşmayın bu şekilde ilerleyin, daha verimli bir sonuç alacaksınız. Startup’ta daha önce kullandığınız route.config yapınız varsa Map() methodları ile tüm route’u map’lemeniz gerekiyor. Bu noktada dikkatli bir search&replace ile tüm işiniz halledebilirsiniz çok da zor olmaz. Biz Api’lerimizde Route Attribute kullandığımız için neredeyse sadece Startup’ı geliştirdik diyebiliriz. Burada redis, logging, caching, ef core, db context, error handler, request tracer, health checker gibi yapılarımız yazdık. Uygulamamız direk ayağa kalktı. Sıkıntı yaşadığımız noktalar ise aynı api ismini kullanan farklı methodlarda oldu. Bunlara izin vermiyormuş, isimlendirmeleri tekrar düzenleyip bunları kullanan diğer uygulamaları güncellemek için bir patch geçtik ve sorunu hızlı bir şekilde aştık. Şuanki Api’mizde SimpleInjector kullanıyoruz. Naçizane DI framework tavsiyemdir, hem hızlı hemde default aspnetcore paketleri ile geliyor ve kolay bir şekilde crosswire yapıyor.
HttpStatus vb. bazı yapıların namespace’leri değişti ya da silindi. Bunlar için hepsinin bir alternatifi var. ASP.NET Core cok iyi bir rest altyapısı sunuyor bu noktada çok endişe edilecek bir şey bulamadım. GraphQL gibi şeylere hevesiniz var ise buna da desteği var, belki entegre etmeyi düşünebilirsiniz.
Middleware ile ilgili diyecek fazla bir şeyim yok ihtiyacınız ne ise ona yönelik geliştirme yapacaksınız, daha önce logging için bir yazı yazmıştım orada bir middleware kullanımım vardı, aynı middleware’i error handling ve request tracing için de kullanabilirsiniz.
Özetle, .Net Core geçişi o kadar korkulacak bir şey değil. Proje boyutunuza bağlı çok şey değişebilir. En çok korkacağınız nokta ORM değişikliği olabilir. ASP.NET Core tarafında ise herşeyi Middleware’lerle hallediyorsunuz gerisi zaten geliyor. Bununla alakalı Microsoft’un MSDN sitesinde ve Github’da yüzlerce örnek kod, makale hatta MSDN’in kitapları var. Size bu yazımda ağırlıklı keyword’ler ve araştırma noktaları vermeye çalıştım, bahsi geçen yapıları araştırırsanız sizin durumunuza en uygun şeyleri bulabilirsiniz. Yeniliği yakalamak için geç kalmayın, bir an önce sizde .Net Core’a yelken açın!
Kişisel bir fikrimi beyan etmek istiyorum. Herkes .Net Core geçişi yaptığı bu sıralarda, çok firmada gördüğüm Windows, IIS vb. artık eskide kalması gereken bir çok hammaliyet ile devam ediyor. Eğer .Net Core’a geçiyorsanız bunu tam anlamıyla yapın. Gerçekten RESTful olun, Middleware kullanın, ASP.NET Core kullanın, uygulamanızı Kestrel’la ayağa kaldırın ve en önemlisi uygulamanız container’da koşsun!
İyi planlamalar!
Saygılarımla.
