.NET e Geri Dönerken 1 : .NET CORE , .NET Standart , Xamarin ve .Net Native ile Cross Platfrom .NET

Son 4 yıldır .NET dünyası dışındaki alternatfilerle uygulama geliştirdiğim sürede, .NET in ve özellikle dil olarak C# ın özlediğim çok tarafı oldu. Ölçekleme sorunları başta olmak üzere , Unix tabanlı işletim sistemleriyle daha ucuz ve daha yüksek performanslı  yeni nesil “daha taşınabilir ve daha küçük yapıda (micro-service benzeri )” servisler yazıp dağıtık sistemler oluşturma imkanının yeteri düzeyde olmaması en önemli 2 neden di çalıştığımız projelede “.NET ” i bir süreliğine bir kenara bırakmak için.

Ayrıca, son noktada web ve mobile uygulamalarımızda daha fazla kod ve servis paylaşım imkanı sunan başta Javascript olmak üzere diğer dillerin ve platformların “özellikle , yeni başladığımız projelerde” maliyet olarak ciddi kazanımları söz konusuydu. (Hem zaman hemde maddi anlamda)

.NET i teoride başka platformlarda çalıştırma imkanız olsada, son 1-2 yıla kadar pratikde .NET “Windows only and Legacy Platform / En iyi windows da çalışacak ve eski sürümlerle uyumlu olacak ” bir platformdu.

Mono benzeri projeler olasada, varlıkları  açığı kapatmaktan çok ama çok uzaktı. Sorun sadece Cross platform run-time meselesi değil, ayrıca komple bir eko sistemin , windows platformu dışındaki zayıflığınıda bununla beraber düşünmek gerek.  Bu tür sıkıntılar, microsoftun sadece Framework ü değil framework ün eko-sisteminide çok ciddi şekilde desteklemesi, zenginleştirmesi anlamına geldiği için, Her şey Microsoft a kalmış durumdaydı. .NET JAVA paltformun “open source” dünyadan aldığı desteği hiç bir zaman alamamıştı.

Hadoop , Elastic Search, Spring Framework, Hibarnate , JVM üzerinde çalışan diğer diller vs vs.. sadece şu saydığımı 5-6 proje bile Java dünyasındaki zenginliğin ve open source un eko sisteme yaptıgı katkıyı görebeilirsiniz. Microsoft tarafında ise, her yeni teknolojiye , her başarılı framework e rakip “bir microsoft ürünü yada microsoft detseki bir proje” ile cevap verilmeye çalışılsada ,”Windows only ve Legacy ” kavramı her zaman bir frenleme mekanizması gibiydi

Geçtiğimiz dönemde , .NET dünyasının çok hızlı ve sert bir dönüşüm içine girdiğini gördük , önce “.NET Open Source ” olarak dağıtılmaya başlandı.  Sonrasında, Framework ün 3 ana parçaya bölünerek devam edilmesi kararlaştırıldı. Yazının devamında bazıalrından bahsedeceğim başka önemli değişiklikler de oldu.

Bu süreci ilgiyle izlesemde, son 3 – 4 aya kadar neler oldu bitti anlamakta zorlanmıştım, taki iş yerinde küçük bir servisimizi yeniden yazma ihtiyacı ortaya çıkına dek. Bütün istemcilerimizin,(web, mobile, cron jobs vs) ulaştığı ve bir ürün hakkında “yasal bilgi aldığı bir web servis” di bu. Restful , çok sade , tek bir iş için özelleşmiş, ana DB ler le bir bağlantısı olmayan bir API.

Ayrıca bu servis en eski servisimiz olduğu için, elimizdeki .NET ile yazılmış son ve tek servisdi. “Son .NET li” . Bu servis , başta .NET Core olmak üzere .NET dünyasındaki yenilikleri anlamak için “yeniden en yeni .NET teknolojileriyle ” yazılmak adına süper bir adaydı.

Özellikle, ana DB leri kullanmayışı ve kendi küçük db sinin olması, bu servisi çok daha iyi bir aday haline getiriyordu. Böylece hem servisimi yeniden yazacak hemde .NET dünyasındaki yeniliklere bakma fırsatım olacaktı.

Birlikte bir kaç yazı ile, yukarıdaki süreçle tecrübe etme ve tanıma imkanını bulduğum, yeni nesil .NET teknolojilerini beraber tanımaya çalışacağız. .NET CORE ve WEB API ile küçük bir uygulama ile “.NET e geri dönerken”  ilk önemli adımları beraber atmış olacağız.

.NET in şuanki hali

.NET eko sistemi hala değişimini sürdürsede 3 aşağı 5 yukarı bir standart oluşmuş durum da . Bugünki hali için aşağıdaki görsel ile bir tanımlama yapabiliriz

Yukarıdaki görsel biraz kafamızı karıştırabilir, ayrıca yukarıda “.Net Native” gösterilmemiş durumda. Ama işin aslı aslında okadar zor ve karışı değil. İlk olarak Bildiğimiz(ve yıllardır kullandımız) .NET e bakalım sonrasında işin aslında okadar karışık olmadığını görmüş olacağız.

.NET Standart

Bugüne kadar , .NET dediğimizde anladığımız ve kullandığımız eko-sistem , bugün itibariyle “.NET Standart” ismini almış durumda. Peki .NET aslında hangi parçalardan oluşmakta ve hangi ihtiyaçlarımızı karşılamakta.

.NET in 3 ana parçasına bakarak devam edelim:

  1. Class Libraries / Kütüphanelerimiz
  2. CLR (Common Language Runtime) – Kodlarımızın çalışmasını sağlayan / yöneten sistem
  3. JIT(Just in time Compiler)

Yukarıdaki 3 parça bizim için .NET in ana yapısını oluşturmakda . İlk madde muhtemelen anlaşılması en kolay olan madde , tahmin edeceğiniz gibi, uygulama geliştirme sürecine ihtiyacımız olan bir çok ihtiyacı ve alt yapıyı sağlamakta.

Geliştirici olarak framework yada platforum sağladığı bu hazır yapıları hemen hemen her uygulamada kullanmaktayız. Örneğin, hiç birimiz temel veri türleri için kendimiz bir sınıf vb. yazmayız. Int, double, string gibi en temel veri türleri  zaten hali hazırda bize sunulmuştur.

Temel veri türlerinin yanında daha özelleşmiş yada gelişmiş veri türleri “out of the box ” olarak kullanıma hazırdır. Array, List , HashTable, Dictionary vs. gibi.  Yine aynı şekilde, bazı ihityaçlarımız için özelleşmiş sınıflar da bize hazır olarak sunulmakta, örneğin: dosya yazma işlemleri için kullanabileceğimiz sınıflar yada XML dosyalarını ayıklamak/parsing için gelenler gibi.

Ve tabi bir de utliliy / araç tarzında gelen kütüphanler sınıflarımız var, email göndermek, veri tabanına bağlanmak yada http istekleri yapmak için kullanabileceğimiz sınıflar gibi. İşte bütün bu hazır alt yapı .NET dünyasında , yukarıda birinci madde de “Class Libraries / Kütüphanelerimiz” dediğimiz kısmı oluşturmakta.

.NET (standart) işte tam bir set halinde devasa bir “Class Libraries ” desteğiyle gelmekte, hemen hemen her türlü ihtiyacımız için kullanabileceğimiz bir çok hazır yapı.

İkinci madde  “CLR (Common Language Runtime) – Kodlarımızın çalışmasını sağlayan / yöneten sistem” olarak bahsettiğimiz CLR  ise daha teknik ve mimari açıdan önemli olan bir konu. Bunu daha iyi anlayabilmek için aşağıdaki örneğe bir “developer ” olarak ilk andan itibaren bakarak CLR ı anlamaya çalışalım.

Şöyle bir örneğimiz olsun;

  1. C# ile bir uygulama yazalım (her hangi başka bir .NET dili içinde durum aynı olacaktır)
    1. Uygulammızda yukarıda bahsettimiz .NET tarafından sağlanan hazır sınıflar ve yetenekleri kullandık(Class libraries)
    2. Ekrana “isminizi girin ” şeklinde bir mesaj yazdırdık
    3. kullanıcı “Ali” ismini girdi ve entere bastı
    4. sonra biz ekrena “Merhaba, Ali” yazdırdık
  2. Tek yöntem olmasada, en yaygın olan haliyle, Visual Studio içinde F5 e bastık,
    1. Visual Studio bazı işlemler gereçekleştirdi(derleme/compiling)
    2. Sonra bir konsol ekran açıldı ve bize “isminizi girin” diye sordu, ismimizi girdik ve entere bastık  (CLR <JIT> )
    3. “Merhaba Ali” mesajını gördük ve konsol kapandı. (Uygulamamız sonlandı)

 

using System;

namespace learn1
{
    class Program
    {
        static void Main(string[] args)
        { 
           string message = "Lutfen isminizi giriniz";
           Console.WriteLine(message);
           string isim = Console.ReadLine().ToString();
           string selam = $"Merhaba {isim}"; 
           Console.WriteLine(selam);
        }
    }
}

C# ile yazdığımız bu kodlara,  F5  e basınca ne olduğu ve sonrası,  CLR ı anlamak için önemli olan süreç. Kısaca özetleyecek olursak, Aşağıdaki adımlar sözkonusu

  1. F5 e basmamızla birlikte, Visual Studio , C# Compiler ı çalışıtırıp (eğer visual basic.net ile yazsaydık onun derleycisi çalışacaktı) yazdığımız C# kodunun derlenmesini sağlayacak. Derleme işlemi tıpkı Java da olduğu gibi direkt olarak Native Code/ makine koduna değil bir ara dile çevrilecek.
    1. C# => IL(intermediate language) / makina kodundan onceki ara form
  2. Daha sonra bir .exe uzantılı çalıştırılabilir bir paketimiz oluşturulacak
    1. Exe uzantili bu nihayi paket IL kodlarini ve diger referanslari tutacak
    2. Biz .exe uzantili bu dosyayi çalıştırdığımızda , devreye başka bir -aracı- olan JIT(Just in time compiler ) girererek , IL kodunu native/makine koduna dönüşürecek ve böylece “C#” olarak başlayıp, IL olarak devam eden bu süreç en sonunda makina koduna dönüşmüş olacak.

C#            =>      IL                                                =>  Native Code

int i = 0;      .locals init ( [0] int32 num)                 0000

Peki ilk olarak aklımınıza gelmesi muhtemelen olan soru : Neden yazdığımız C# kodları direkt olarak native code / makina diline  (101010100110) değilde aracı bir forma dönüşmekte? Ve sonrasında (IL)  başka bir işlemden daha geçip (JIT) öyle çalışmakta.

C/C++ gibi diller aracı formlara dönüşmeden direkt olarak makine diline derlendiği için daha yüksek performansa sahiptir. Java ve C# ise Makine dilinden önce bir ara form kullanmaktalar.(Java, Byte Code, C# ise IL) Bu seçimin kendine has artıları ve eksileri bulunmakta.

İlk neden olarak , CLR ın isminden de anlayabileceğimiz gibi (Common …) Hangi dili kullanırssanız kullanın , eğer doğru IL kodunu üretirseniz CLR sizin için bu kodu çalıştırıp yönetebilecektir.

İkinci olarak, .NET managed/ yönetilen, denetlenen bir platform olarak sunulduğu için, Garbage Collection / Hafıza temizliği yada otomatik hafıza yönetimi başta olmak üzre, ilgili referans modüllerinin yüklenmesi ve çalışma zamında hazır edilmesi,  Thread yonetimi , Çalışma zamanında hata denetimin yapılabilmesi (exception management subsystem)  ve sonrasında ilgili kodun Makine Diline çevrilip çalıştırılması gibi  bir çok işlemin, CLR tarafında  bizim için yapıldığını görmekteyiz.

Ayrıca başka bir önemli noktada, Bu ara katman, uygulamanın çalışacağı “donamın ve işletim sistemine ” uygun bir şekilde derlenebilecektir. Geliştirici, sadece C# kodunu yazıp derleme ile kodları IL e dönüştüken sonra, gerisine karışmayacak ve herşey CLR tarafından yönetilecebilecektir.

Java nın da buna benzer bir döngüye sahip olduğunu söylemiştik, Java tarafında, CLR ın yerini JVM(Java Virtual Machine) , IL in yerinide byte code almakta. İki paltformun tabiki fakrlı yönleri olsada ortak noktaları, makine kodundan önce bir ara formun sözkonu olması.

Eğer dikkat ettiyseniz, Java, çalışma zamanı için “JVM – Java Virtual Machine /  Sanal java  makinesi” terimi kullanılıyor, bu vurgu aslında, .NET içinde rahatlıkla kullanılabilir . İşletim sistemi üzerinde çalışan bir alt “sanal” makine simule ediliyor diyebiliriz.

Scala, Groovy , clojure , Xtend, Kotlin gibi dilleri duyduysanız, bu dillerin hemen hepsinin dökümantasyonunda şuna benzer bir cümle görürsünüz “compiled to JVM bytecode”  bu diller run time olarak JVM kullanmakta . Bu dilleri geliştirenler, üst seviyede dilleri kendi istekleri gibi şekillendirirken, işin zor ve en önemki kısmını JVM ye bırakmaktalar.

Tıpkı JVM üzerinde çalışan bu diller gibi, CLR ı hedef alan ve IL koduna doğru dönüştürülen her dil de aynı şekilde, işin zor kısmını CLR a bırakabilir.

Bu noktada IL kodlarımızın oluşturulduktan sonraki saklanma halleri olan .dll ve .exe uzantılı halleri için bilememiz gereken tek şey “.exe (executable)” olan dosyalarımız kendi başlarına çalışabilmekteler iken, .dll olarak paketlenen IL kodlarımız başka programlar içinde kullanılmak için oluşturulmuş olması. Microsoft Excel i bilgisayarınıza kurduğunuz da program files altında ki halini gösteren aşağıdaki görsele bakalım

yukarıda, kırmızı ile işaretlediğim .exe isimli dosyayı çfit tıklarsak(çalıştırırsak) excel i başlatmış olacağız,  mavi ile işeratlediğim dosyalar ise .dll  uzantısına sahipler ve excel in içinde kullanacağımız bir çok özellik ilgili .dll dosyası olarak tutulmakta.

Bu konuda son olarak bir hatırlatma yaparak bir sonraki konuya geçelim, “CLR “ veya “JVM” IL kodlarını yada Byte Code u hedef donanım ve işletim sistemine göre uygun derleme işlemine sokabilmekte. Yazdığımız C# kodları, IL kodlarına dönüşeceği için, “Cross platform ” uygulama geliştirme konusunda da CLR , kodlarımızı Linux üzerinde yada MacOS üzerinde ve tabiki Windows üzerinde ayrı ayrı hedef sisteme uygun olarak makine diline dönüşüm ve çalıştırma sürecini sağlayabilecek.

JIT(Just in time Compiler)

C# ile kodlarımızı yazmış, sonrasında derleme işlemini gerçekleştirip, IL kodlarımızı oluşturmuştuk bu noktaya kadar.  IL kodlarımızın tutulma şekli olarak da 2 alternatifden bahsetmiştik .exe veya .dll uzantılı iki farklı tür iki farklı alternatif. Şimdi sıra CLR ın IL kodlarımızı makine koduna dönüştürüp çalıştırmasına geldi.

CLR, JIT Compiler ı kullanarak, IL kodlarımızı makine kodlarına dönüştürürken, “just in time” terimine dikkat etmek lazım, “tam zamanında” yada “gerektiğinde” dönüşüm olarak tercüme edebileceğimiz  bu kavram ile, CLR , ihtiyacımız olduğunda ilgili IL kodunu JIT e aktarak makine koduna dönüştürmekte ve çalıştırmakta.

Makina koduna dönüşen her IL kodu , bir geçici bellekte tutulmakta, ve tekrar lazım olduğunda yeniden derlenmek yerine, bu bellekten alınıp çalıştırılmakta. Böylece performans açısından daha iyi bir netice eldedilmekte.

Eğer bir yerlerde “PreJIT” yada “EconoJIT” gibi terimler duyarsanız çok endişelenmeyin, bunların bazı özel durumlar için özelleşmiş farklı JIT verisyonları olduğunu bilmeniz ve genelde %90 oranında şimdiye kadar bahsettiğimiz JIT  i kullandığımızı bilmemiz yeterli olacaktır.

Ekstra bilgi olarak, PreJIT ve EconoJIT , sırasıyla, makine kodunun nezaman oluşturulacağı ve oluşturulan makina kodlarının hafızıda sonraki erişim için tutulup tutulmayacakları konusunda farklılık göstermektedeler.  

Asagidaki gorsele bakarak devam edelim:

 

Yukarıdaki resimle , tüm süreci tekrar özeteleyecek olursak

  1. C# yada VB.NET yada her hangi bir diğer .NET dili ile uygulamamız yazdıldı
  2. Kodlarımızı derledik
    1. İlk derleme, makina koduna değil bir ara form olan “IL”  koduna dönüştü
    2. Kodlarımız, .exe yada .dll olarak tutulmakta.
  3. IL kodlarımızın çalışma zamanı geldiğinde devreye CLR girdi
  4. CLR bizim için
    1. Uygulamanın başlatıldığı andan en sonuna kadar,
      1. Hata denetimi
      2. Hafıza yönetimi,
      3. ilgili referansların takip edilmesi
      4. vb. bir sürü işlemde yükü bizim üzerimizden almakta
    2. CLR, zamanı geldiğinde IL kodlarımızı çalıştırmak için, 2.bir derleme sürecini sağlamakta
      1. IL kodlarımız CLR tarafından, JIT  e gönderilmekte,
      2. JIT compiler, IL kodlarımızı, Makine koduna dönüştürüp , CLR a geri vermekte
      3. Son adım olarakta, CLR, bu kodları işlemcimiz aracılığıyla, çalıştırmakta.
  5. Uygulamamızın çalışması sonladığında, CLR ilgil temizlikleri yapıp, Döngüyü tamamlamakta ve uygulamamız sonlanmakta.

Neden bu sürecin üzerinde bukadar konuştuk  diye düşünüyorsanız, .NET eko-sistemindeki diğer kavramları anlamak için (.NET Core veya .NET Native gibi) bu süreci bilmemiz çok önemli.

Benim olabildiğince özetlemeye ve genel başlıklar halinde tutmaya çalıştığım bu büyük ve “Managed Flow / Yönetilen Süreç”  bilinmeden de uygulama yazabilsek de, arka planda neler olup bittiğini anlamak biz geliştiriciler adına çok önemli.

Şimdi artık .NET (standart) i biraz konuştuğumuza göre , .NET Core bakabiliriz.

.NET Core Nedir?

Şimdiye kadar bahsettiğimiz herşeyin , en önemli başlangıç noktası “Windows Platformu” idi. İster web uygulamaları geliştirin isterseniz Masa üstü, şimdiye dek bahsettiğimiz herşeyi “Windows” üzerinde çalışma “önceliğiyle ” konuştuk. .NET core u anlamaya ise iki önemli noktadan başlayabiliriz

  1. .NET Standart çok büyük bir platform
  2. Windows önceliği ve Eskiye uyumluluk yükü

İlk maddemizi anlamlandırmak kolay olacaktır. .NET in standart sürümü , Wındows platformu için uygulama geliştirme adına hemen hemen tüm ihtiyaçlarımızı karşılamaya yönelik çok büyük bir alt yapı olarak gelmekte. bu çok büyük kavramın için de hem “Class Libraries” hemde “alt frameworkler” ve tabiki eskiye uyumluluk için bir çok başka yüküde beraberinde taşımakta.

İşte .NET Core ile hedeflenen ilk yenilik, daha küçük daha minimal ve ihtiyacınıza göre genişletebielceğiniz “yeni bir başlangıç” noktası oluşturmak. Örneğin sadece windows platformu için geçerli olan bir çok şeyi çıkartıp (Windows Forms, ASP.NET WEB FORMS vs.)  Lİnux, Windows, ve MacOS içinde uygulama geliştirmede temel ihtiyacınız olan minimal seviyede bir alt yapıyı sunmak.

Bir web uygulaması geliştireceğinizi düşünün, ve bunu Windows üzerinde değilde, bir Linux dağıtımı örneğin “Ubuntu” üzerinde dağıtmak / host etmek isteyelim, Ubuntu üzerinde çalışmayacak yada bulunmasının anlamı olmayacak(WinForm yada Web uygulaması geliştireceğimiz için desktop uygulama alt yapısına ihtiyacımız yok.) bir çok parçayı kaldırıp, Sadece .NET Core ile temel düzeyde bir alt seti kullanabilmek bu işin ilk adımı olarak çok önemli.

Projemize sonrasında , ASP.NET MVC Core yada WEB API Core u dahil ederek ubuntu üzerinde de çalıştırabileceğimiz bir cross platform uygulama geliştirme sürecimizin ilk adımı olarak, frameworkün “.NET” küçültülmesi ve gereksiz kısımların temizlenmesi gerekmekte.

İkinci madde “Windows Only / Windows için”  den Cross Platform / farklı platformları da destekler hale gelebilmemiz için tekar CLR  ve JIT e vurgu yapmamız gerekecek. Yukarıda biraz uzun tutarak bahsetmemizin nedenide “.NET Core” u daha iyi anlamak adına buydu.

İlk olarak, frameworkü ciddi anlamda küçültük, daha küçük ve daha özelleşmiş bir hal demek  ,”başka platformlar ” içinde daha kolay uyum sağlanabilirlik demek. Sonrasında ise ihtiyacımız olan, daha özel bir CLR. 

 CoreCLR, ve Küçültülmüş  Class Libraries  CoreFX.

Yukarida, CLR ı tıpkı Java dünyasındaki gibi JVM ye benzetmiştik,  yani bir yönüyle , sanal bir makinaya. Ozaman CLR için tıpkı Java Sanal Çalışma ortamı JVM gibi “.NET virtual machine “diyebiliriz. Eğer herhangi bi işletim sisteminde CLR varsa , bunun “işte IL kodlarım, sen hangi işletim sistemindesin ne istersin ne yaparsın bilmiyorum ama, Linux se Linuxe göre Windows ise Windows a göre çalıştır kodlarımı ve uygulamamı yönet” demek olduğunu söyleyebiliriz.

İşte CLR ın Windows dahil farklı işletim sistemleri üzerinde çalışacak versiyonuda “CoreCLR” olarak isimlendirilmekte. Aynı şekilde, daha küçük  ve özel bir alt set olarak, hem windows, hem linux hemde MacOS da ortak olarak ihtiyacımızı karşılayacak bir class library sürümü olan CoreFX de .NET Core un bir parçası durumunda.

Kodlarımızı, C# ile yazdık, yazarken, .NET CoreFX(.NET standart ile gelen devasa Class Library yapısını değil) i kullandık ve IL kodlarımız artık CoreCLR üzerinde çalışmaya hazır. CoreCLR Linux yada MacOs yada Windows a göre uygun bir şekilde derleme ve yönetim yaparak kodlarımızı Cross Platform olarak kullanmamıza imkan vermiş oldu.

Ayrıca, başka bir yenilik ve avantajda, CoreCLR ın uygulamamızla birlikte paketlenecek olması yani artık, eskisi gibi, Uygulamamın çalışması için bu makinada “.NET X.x.x” sürümü lazım gibi sıkıntılarda olmayacak.

Ve birden farklı .NET sürümü aynı makinada sorunsuz olarak çalışabilecek. Yani Uygulamamız artık “Self-Contained” bir şekilde , ihtiyacınıda yanında taşıyacak. Ve sadece istediğimiz parçaları kullanma özgürlüğümüz olacak.

CORE CLI

Eğer .NET geliştiricisyseniz, muhtemelen komut satırından (konsol) çalışmaya pek alışık değilsinizdir. .NET Core ile birlikte yeni bir araç olarak Core CLI da yayınlandı. Core CLI komut satırından çalışmaya alışık olanlar yada Visual Studio ortamı dışında kalmak zorunda olanlar için ideal bir alternatif. Core CLI ile yeni proje oluşturabilir, derleyebilir dağıtıma hazır hale getirebilrsiniz.

Eğer Visual Studio kullanıyorsanız, eskiden alışık olduğumuz gibi her şeyi yine visual studio içinde “clikler, f5 ler vs. ile ” yapmaya devam edebilirsiniz. Core CLI zorunlu bir araç değil eğer Visual Studio kullanıyorsanız. Sadece bir alternatif. CLI sisteminize yüklendikten sonra komut satırından dotnet komutu ile kullanabilmekteyiz.

İlk .NET CORE Projemiz.

Yazının ilk başında bahsettiğim , küçük servis(ASP.NET CORE MVC ve EF CORE kullanarak) örneğini yazmaya bir sonraki yazıda başlayacak olsakda, bu kısımda projemizi geliştirmeye hazır hale getirerek devam edelim.

Her şeyden önce , ihtiyacımız olan şeylere bakalım ;

  1.   Eğer Visual studio 2017 sisteminizde yüklüyse, .NET Core ile uygulama geliştirmeye ihtiyacınız olan her şey sisteminizde hazır olacaktır.
    1. https://www.microsoft.com/net/core#windowsvs2017 adresinden, Visual Studio yu indirip kullanabilmekteyiz.
  2. Core CLI ı kullanmak istiyorsanız, yada linux veya MacOs üzerinde geliştirme yapmak istiyorsanız öncelikle,  https://www.microsoft.com/net/core#windowscmd adresindeki önergeleri takip ederek
    1. .NET Core SDK yi indirip kurulumu yapmamız yeterli.

Biz örneğimizde, iki kısımda görülsün diye, Projemizi CLI ile oluşturup, geliştirmeyi Visual Studio ile yapacağız. Ama , tüm süreç için sadece visual studio yu kullanmak isterseniz de sorun yok hem daha kolay hemde herşey tek noktadan ulaşılabilir. Visual Studio ile aşağıdaki adımları izleyerek projemizi kolayca oluşturabiliriz

  • New Project => Asp.net Core Web(.net core) => Web Api

CLI ile kurulumda gayet basit ama kurulum sonrası normalde, Visual Studio nun bizim için yaptığı bazı şeyleri bizim yapmamız gerekmekte. Projenizi oluşturmak istediğiniz klasör içinde (power shell veya komut satırından “cmd“)

(öncelikle dotnet yazıp entere basıp, CoreCLR ve Core SDK nin yüklü olduğundan emin olalım.)

Yukarıdaki ekran görüntüsünü alıyorsanız, her şey hazır demektir. Projemizi oluşturmadan önce, bir kaç template yükleyelim. Örneğimiz de Angular 2 kullanacağımız için , her şeyi sıfırdan oluşturmak yerine bir angular starter template kullanabiliriz.

komut satırından

dotnet new --install Microsoft.AspNetCore.SpaTemplates::*

komutu ile, bir çok hazır başlangıç template ini yüklemiş olacağız.(.NET Javascript Services : React, Angular 2 vs..) . Bu işlemi komut satırından yapsanızda visual studio içinde de artık bu yeni template ler erişelebilir olacaktır.

Using ASP.NET Core Javascript Services to Play Nice with Client-side Frameworks

 

Yükleme sonrası aşağıdaki gibi bir özet ekranımız olacaktır.

(Not: Eğer Angular , react vb teknolojileri kullanmak istemiyorsanız, yada kurulumu kendiniz yapmak istiyorsanız, bu yüklemeyi yapmak zorunda değilsiniz. )

Artık yeni projemizi oluşturabiliriz. Komut satırından

dotnet new angular

dememiz yeterli olacaktır. Bu komutla birlikte, CLI bizim için bir başlangıç noktası olarak (ASP.NET CORE MVC/API + Angular 2  ) bir proje oluşturmuş olacak.

bu noktada eğer visual studio ile devam etmek isterseniz, resimde işaretli olan .csproj u visual studio ile açmanız yeterli , gerisini visual studio sizin için halledecektir. Eğer CLI ile devam etmek istiyorsanız, yapmamız gereken iki şey var. İlk olarak ilgili nuget paketlerinin indirilmesi ve sonrasında da angular ın ihtiyaç duyacağı javascript kütüphanelerinin indirilmesi.

İlk olarak , komut satırından

dotnet restore

ile ilgili .NET paketlerimizi indirelim , indirme işlemi ilk seferde biraz zaman alabiliyor. Sonrasında,

npm install

komutu ile, Angular ve diğer javasciript kütüphanelerini indirelelim. (Eğer npm i hiç duymadıysanız, kısaca, node.js in paket yöneticisi diyebiliriz. .NET nuget, Nodejs, npm gibi. npm i kullanabilmeniz için sisteminizde, nodejs in yüklü olması lazım. https://nodejs.org/en/)

dotnet restore işleminden sonra

npm install sonrası

Projemizin tüm ihtiyaçlarını indirmiş olduk. Kodlarımıza bakmadan önce her şeyin yolunda olduğunu anlamak için (VS kullanıyorsanız F5 🙂 ) CLI ile projemizi derleyip test edelim.

komut satırından

dotnet run

dememiz , projemizin bu haliyle derlenip çalışmasına yeterli olacaktır.

eğer herhangi bir sorun yoksa, gördüğümüz gibi artık , tayıcımızdan, http://localhost:5000 adresini ziyaret edip , uygulamamızın çalışan halini görebiliriz.

İlk .NET Core uygulamamızı böylece oluşturup çalışır hale getirdik. Yazı buraya kadar zaten uzun olduğu için uygulamamızı bir sonraki yazıda yazmaya devam edeceğiz.  Sonrasında da Xamarin ve .NET Native ile bitireceğiz.

Kolay Gelsin.

 

 

7 thoughts on “.NET e Geri Dönerken 1 : .NET CORE , .NET Standart , Xamarin ve .Net Native ile Cross Platfrom .NET

  1. Merhaba öncelikle bu bilgilendirici yazı için teşekürler.
    .NET Core şuan da uyguluma geliştirmek için ideal bir yapıya kavuştumu merak ediyorum, yoksa biraz daha zaman geçmesi lazım diye bilirmiyiz?

    1. Merhaba,
      .NET Core suan production da kullaniliyor(genelde web tabanli uygulamalarda), fakat biraz projenin niteligine gore bazi durumlar icin bir sure daha (belki bir 6 ay daha) .NET standart tercih etmek gerekebilir.

      .NET Core 2.0 surumune yaklasiyor muhtemelne 6 aylik bir sure zarfinda 2.0 surumune gecilecek ve bu surumle birlikte artik, .NET Core , hemen hemen her turlu proje icin ideal bir noktaya kavusmus olur diye dusunuyorum.
      Roadmap icin asagidaki adrese bakabilirsiniz.

      https://github.com/dotnet/core/blob/master/roadmap.md

  2. .net standart denilen şey verdiğiniz grafikteki gibi .net framework (klasik,bildiğimiz),.net core ,xamarin de kesinlikle bulunacak/bulunması gereken en temel(3 platformda da bulunması anlamlı/üçündede işe yarar kütüphane dosyalarını kasteden reference library nin adıdır.adı üstünde referencedir.asla implemente edilmemiş ve edilmeyecektir.aynen networkteki osi reference model gibi düşünülebilir.yani .net core da System.falanca.* gibi bir namesapace ve altındaki sınıflar bulunur iken net framework te bulunmayabilir ama xamarinde aynı şey bulunabilir.yada xamarinde ve .net framework de bulunan bir şey .net core olmayabilir.kombinasyonları siz yaparsınız.adamların yazdığına göre çalışma mantığımız net standart denen reference kataloğu oluştururken şuna bakıyoruz:biz kesinlikle şu sınıf .net standartta bulunsun hadi implemente edin demiyoruz diyorlar..net framework,.net core ve xamarin ekipleri eğer lütfedip belirli classları kendileri için yazarlarsa biz bu classları değerlendirmeye alırız.eğer 3 platform için de iyi çalışan ve işe yarar bulursak onu gerekli olarak işaretleriz ama bazen de optional olarak işaretleriz her 3 platform da olsa da diyor.böylece .net standart oluşmuş olur ve önceden yaptığınız pcl(portable class library) olayına gerek kalmaz demeye getiriyor.bu konuda şuradakilerden faydalandım
    https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

    https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again

    diğer bir konu ise coreclr ın uygulamamız ile götürülecek olmasıdır.burada da yanlış anlaşılma olmasın bugün biz merhaba dünya yazdığımızda coreclr da ona eklenip dağıtılacak diye bir olay yoktur,mantığıda yoktur.çünkü zaten amacımız platform bagımsızlığı sağlamaktır.bahis ettiğiniz gibi clr/coreclr platform bağımlıdır ve kesinlikle bir platformda çalışan ile diğer platforma çalışan clr/coreclr ların arka yüzleri birbirinden farklıdır.yani biz merhabadünya.exe ye coreclr ı bundle edip yollasak(ikisini birbirine bağlasak) diğer platformda çalışmaz.bu yüzden “self hosted” kavramını böyle düşünmemek lazım..net core ile uwp uygulamalar içinde durum böyledir.kesinlikle bundle edilemez etmesi teklif dahi olunamaz.gelelim web tarafına asp.net core ve webapi mantığında ise minimalist bir web server olan kestrel isimli web server kullanılacağı için(zorunlu değil iis de olabilir) bu türden işler için arzu ederseniz kestreli daha önceden(build) esnasında hangi platformda çalışacağını belirterek bir çıktı alır ve bu çıktıyı ilgili platforma taşırsanız uygulamanız sorunsuz çalışacaktır lakin başka platformda çalıştırmak isterseniz bu kez o platforma göre build edeceğinizi baştan belirtmeniz gerek süreç yine tekrarlanmalı.dikkat ettiyseniz core clr degil kestrel bundle ediliyor bu durumda dahi eğer ilgili platformda coreclr yok ise uygulamanız size .net core.xxx nerede diye soracaktır..net core olmadan(coreclr ve corefx) ben çalışmam deyip mızıkçılık edecektir.”self hosted” kavramını böyle anlamak gerek diye düşünüyorum.
    yapacağınız çalışmayı ilgiyle bekliyor olacağım (bahsettiğiniz küçük proje)
    yazdığınız post genel olarak yapıyı özetlemiş ve zihinlerimizi aydınlatmıştır teşekkür eder yeni yazılarınızı ilgiyle bekleriz

    1. yaptığım yorumun bir kısmını şöyle düzeltiyorum:self containing olayı yazarın anlattığı gibiymiş yani biz basit hello world de yazsak self containing olayı doğru ve yaklaşık 50 MB gibi runnable bir klasör oluşuyor.yani bildiğimiz runtime(coreclr,ryujit,corefx,vs) tümüyle uygulamaya bağlanıp salınıyormuş.tabi burda .net core tümüyle gitmiyorda bir uygulamanın çalışması için gerekli bileşenler gidiyor haliyle compilerlar kalıyor ,uygulamaya bir de compile time ın araçlarını katmayalım daha da büyümesin diye düşünmüşlerdir herhalde. misal windows çalışma ortamından ubuntu için bir build oluşturdum tersi de mümkün tabiki, şunu farkettim birde bu oluşan release içinde bazı bileşenlerin native imageleri de var örneğin mscorlib.dll var iken mscorlib.ni.dll de var.

  3. “Bugüne kadar , .NET dediğimizde anladığımız ve kullandığımız eko-sistem , bugün itibariyle “.NET Standart” ismini almış durumda.”
    Bu ifade doğru değil dogrusu

    Bugüne kadar , .NET dediğimizde anladığımız ve kullandığımız eko-sistem , bugün itibariyle “.NET Framework” ismini almış durumda. Aslında bu ismi bugün almadı adı hep buydu ve bugün de bu..net standart ise xamarin,.net core ve .net framework icin bir reference kitapligidir.falanca,falanca iinde siniflariniz ve falan falanca adinda metotlariniz olmali diye belirtim yapar.gavur dili ile konusacak olursak .net standart not a implementaion it is just a spesification..net standartı belirlerken her platformda olmasi gerekli ve faydali kisinlari aliyorlar digerlerini tabiri caizse ellemiyorlar yaninbir acidan bakacak olursaniz mesela xamarin .net 1.6 yi destekler diyorsa xamarin gelistiricileri burdan sunu anlamak icap olunur.haa tamm xamarin de .net standart 1.6 ya yetecek kadar api var hatta daha fazlasi da.by tum platformlar icin bu sekilde dusunulmelidir..net core,xamarin,.net framework fark etmez.yukardaki sekil bu acidan biraz yaniltici bakinca saniyorsun ki.net standart daha genis .net core daha dar sanabiliyorsun sekle gore ,bu dogru degildir..net standardin amaci pcl vardi (portable class library) .net projeni farkli platforma gore tasirken sana yardimci olurdu bu yapi amma velakin zahmetli bir isti ve proje icin ayri ayri pcl deaign etmen gerekirdi.dediler ki kardes bu logic ve maintainable degil.bu .net standart diye birsey belirtirsek bu sorunu daha kolay asariz daha az eforla daha kokten cozum olur dediler ki zaten de yukarda yazdigim gibi .net standart da bulunan apiler her platformda olmasi elzem olan gerekli ve onemli apileri kapsar.makaleniz mukemmel olmus ,cok doyurucu olmuş elinize saglik

Leave a Reply

Your email address will not be published. Required fields are marked *