Blazor 0.2.0 dağıtımı yayınlandı

Takip edenler bilir 22 Mart 2018 de Blazor ilk public preview ini yayınlamıştı. Henüz aradan bir kaç hafta geçmesine rağmen yeni bir preview daha yayınladıklarını (Blazor 0.2.0) 17 Nisan 2018 ‘de ASP.NET Blog‘unda duyurdular.

Bu dağıtım ile birlikte Blazor 0.2.0 da yer alan yeni özelliklerden bazıları :

  • Tekrar kullanabileceğimiz component kütüphanelerimizi oluşturabiliyoruz
  • Event handling ve data binding için söz diziminde iyileştirmeler
  • Visual studio içerisinde build
  • Conditional attributes
  • HttpClient geliştirmeleri

Yeni gelen özelliklerin tamamını incelemek isterseniz Blazor 0.2.0 release notlarına bakabilirsiniz.

Blazor ‘a başlangıç yapmak isteyenler blogumu takip edebilirler. Fakat işi asıl kaynağından öğreneceğim diyenler blazor dökümantasyon ve öğreticilerinin olduğu http://blazor.net sitesini inceleyebilir.

 

EntityFramework Core ilişkili verilerin yüklenmesi (Eager Loading)

EntityFramework Core navigation property ler üzerinden modelinizin ilişkili olduğu varlıkları da yüklemenizi sağlar. Bu işlemi yapmak üzere tasarlanmış 3 temel ORM kalıbı bulunur.
• Eager Loading : ilişkili verinin ilk sorgunun bir parçası olarak yüklenmesi
• Explicit Loading : ilişkili veri daha sonra veri tabanından expilicty (açıkça) yüklenmesi
• Lazy Loading : Siz navigation property’e başvuru yaptığınızda verinin database den yüklenmesi. Ben bu yazıyı yazdığımda EF Core 2.0 versiyonunda ve halen lazy loading senaryosunun olması gerekip gerekmediğine karar veremediler. Takip etmek isteyenler buradan

Ben bu makalede yalnızca eager loading üzerine bir kaç şeyden bahsedeceğim. Vakit bulabilirsem daha fazlasını da devam yazıları ile bloga eklerim.

Ayrıca konu ile ilgili şuradan github’taki güzel örneğe ulaşabilirsiniz.

Eager Loading

Include metodu ile sorgu sonuçlarınıza ilişkili verileride yükleyebilirsiniz. Örneğin

using (var context = new BloggingContext())
{
 var blogs = context.Blogs
 .Include(blog => blog.Posts)
 .ToList();
}
 

birden fazla ilişkili veiyide sorgu sonucuna dahil etmeniz mümkün o da şu şekilde

 
using (var context = new BloggingContext())
{
 var blogs = context.Blogs
 .Include(blog => blog.Posts)
 .Include(blog => blog.Owner)
 .ToList();
}

Peki multi level ilişkiler nasıl olacak? (İlişkili verinin ilişkili verisi)

Onuda bu şekilde halledebiliriz.

 
using (var context = new BloggingContext())
{
 var blogs = context.Blogs
 .Include(blog => blog.Posts)
 .ThenInclude(post => post.Author)
 .ToList();
}

Dikkat!

Visual Studio intellisense özelliğinde bulunan bir issue kaynaklı navigation property görünmeyebilir ya da syntax hatası varmış gibi görünebilir. Siz property adını doğru şekilde yazarsanız derlediğinizde sorunsuz çalıştığını görebilirsiniz.

.NET ve Blazor ile tarayıcı tabanlı web uygulamaları

Birkaç gün önce Daniel Roth .NET Web Development and Tools Blog blogunda yeni bir deneysel projeyi duyurdu. ASP .NET ekibi bu projeyi Blazor olarak isimlendiriyor.

Blazor Nedir?

Browser + Razor = Blazor!

Bloglarında çok güzel bir ifade ile özetlemişler. Ben de sizlere aynen aktarmak istedim. Blazor, HTML ve CSS gibi mevcut web teknolojilerini temel alıyor. Fakat web kullanıcı arayüzü oluşturmak için JavaScript yerine C# ve Razor söz dizimini kullanıyor.

Blazor’un neye benzediğini görmek isterseniz Steve Sanderson’un geçen yıl ki NDC Oslo’daki prototip demosunu veya ASP.NET Community Standup’ın prototip demosunu izleyebilirsiniz . Sizler ile paylaşacağım son link ise statik bir site olarak çalışan  Blazor uygulamasına ait. Girip deneyebilirsiniz.

Blazor henüz deney aşamasında. Önemle belirtmek isterim ki Microsoft ASP .NET ekibi projenin devamlılığına dair bir garantide vermiyor. Yani proje sonlanabilir.

Fakat ben yine de inceleyeyim ne yapmışlar diyenleri buradan github projesine alalım. ASP. NET ekibi projeyi açık kaynak kodla geliştiriyor. Ve bakın bizi bu projede neler bekliyor.

Blazor ‘ın modern bir web frameworkte olması gereken her şeye sahip olacağını söylemişler. Çevirmeden aynen yazıyorum.

  • A component model for building composable UI
  • Routing
  • Layouts
  • Forms and validation
  • Dependency injection
  • JavaScript interop
  • Live reloading in the browser during development
  • Server-side rendering
  • Full .NET debugging both in browsers and in the IDE
  • Rich IntelliSense and tooling
  • Ability to run on older (non-WebAssembly) browsers via asm.js
  • Publishing and app size trimming

WebAssembly Web’i değiştirir!

WebAssembly, .NET ‘in web browserlar içerisinde çalışmasını mümkün kılıyor. Kulağa çok acayip geliyor değil mi?

WebAssembly (wasm) nedir? 

WebAssembly kısaca wasm, web’e derleme için uygun, taşınabilir, boyut ve yükleme süresi açısından verimli yeni bir biçim. Şu anda, tüm önemli tarayıcıların temsilcilerini içeren bir W3C Topluluk Grubu tarafından bir açık standart olarak tasarlanmakta. bknz. http://webassembly.org/

WebAssembly önemli bir gelişme. Bu arkadaş sayesinde web uygulaması geliştirmek için temelde yeni yollarda geliyor. WebAssembly ‘ye derlenen kodlar  browser üzerinde native hızlar ile çalışabiliyor. Microsoft bu gelişmeler ile hemen deneylere başlamış gördüğünüz gibi. Tek dil ile her şeyi yapabilelim mantalitesine devam. Demişler ki bizde o zaman WebAssembly ile tarayıcıda çalışabilen bir .NET çalışma zamanı (.NET runtime) oluşturalım. Peki tarayıcıda bir .NET Runtime çalışırsa ne olur? Şöyle söyleyim biz .NET geliştiricileri için tadından yenmez olur. Arkadaşlar bu proje devam edip release olabilirse, herhangi bir eklenti ya da dönüştürmeye vs. gerek kalmadan yazdığımız normal .NET assembly lerimizi WebAssembly tabanlı runtime da derler ve çalışırırız.

Single Page Application geliştirmek için JavaScript, jQuery, Knockout, Angular, React vs. kullanmanıza gerek kalmaz. Tek bilmeniz gereken C#, Razor, HTML ve CSS zaten ASP .NET ve C# ‘ı sunucu tarafında kullanıyorduk. 😉

Tabi sevinmek için henüz erken WebAssembly hala tasarlanmakta. Blazer projesi de sadece bir deney şu anda. Umarım başarılı olur.

Sizce Microsoft bunu başarabilir mi? Yorumlayın tartışalım.

 

Üniversitede Yazılım Eğitimi

Bir çoğumuz üniversitelerdeki yazılım eğitimlerinden şikayetçiyiz. Genel sebebi ise güncel programlama dillerinin yeteri kadar derinlemesine anlatılmaması. Ayrıca sosyal medya mecralarında ki ön yargılı paylaşımlarda cabası. Bu durum aslında bu kadar da kötü sayılmaz. Dikkat edin kötü olmadığını söylemiyorum. Günümüzde kullanılan popüler dillerşn temelleri üniversitelerde gördüğümüz C , C++ gibi tabiri caizse eski diller. Yapmayın arkadaşlar eski dediğimiz diller de halen kullanılıyor. Tamam kimse masaüstü uygulaması geliştirirken kimse bu dilleri kullanmıyor olabilir fakat güncelliğini yitirdi demek değil. Facebook, Google, Microsoft vb. Bir çok dev firma bu dilleri aktif olarak kullanarak ürünlerinin alt yapılarınıngeliştiriyor. Hatta işe alımlarda mülakatlarda dahi bu dillerden algoritma soruları karşımıza çıkıyor. 

Peki biz ne yapalım? C/C++ ile sektörde ne iş bulacağız? Haklısınız kolay olmayacak dakat bu diller ile programlama mantığını, genel terimleri, algoritma yapılarını öğrendiysen güncel dilleri öğrenmen oldukça kolay. Coder Bilişim Akademisi uzaktan eğitimlerinde  C# ta bir dizinin resize işlemini Array.Resize metodu ile yapabilirsiniz dediğim anda metodu inceleyen ve C/C++ dillerini bilen öğrenci kafasında metodun arka planda neler yaptığını içerisine ref ile aldığı parametrenin aslında pointer adresi olduğunu anlıyor. Örnekteki gibi daha bir çok konuda çok daha hızlı kavrayıp öğrenebiliryor. 

Diğer yandan size kimse yeni nesil dilleri öğrenmeyin demiyor. 4 yıl boyunca hem okul için hem kendinizi geliştirmek için çabalarsanız emin olun kısa sürede meyvelerini toplarsınız. 

Şikayet etmek yok. Hedefinizi belirleyip bu yönde kendinizi geliştirmek için uğraşın. Bu sayfa altına yorum ile sorularınızı sorarsanız sizlere nacizane kariyer tavsiyelerimi seve seve paylaşırım

.

ASP.NET Core MVC Filters (Filtreler) – 5

Filter Pipeline da Kısa Devre

Filtre metoduna sağlanan context parametresinde Reult özelliğini ayarlayarak herhangi bir noktada filter pipeline kısa devre yaptırabilirsiniz. Örneğin aşağıdaki Resource Filter filter pipeline ın geri kalanının çalıştırılmasını engeller.


using System;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;

namespace FiltersSample.Filters
{
public class ShortCircuitingResourceFilterAttribute : Attribute,
IResourceFilter
{
public void OnResourceExecuting(ResourceExecutingContext context)
{
context.Result = new ContentResult()
{
Content = "Resource unavailable - header should not be set"
};
}

public void OnResourceExecuted(ResourceExecutedContext context)
{
}
}
}

Aşağıdaki kodda ShortCircuitResourceFilter ve AddHeader filtresi SomeResource isimli action metodu hedefler. Fakat dikkat edin, ShortCircuitResourceFilter önce çalışır (çünkü bu bir resource filtresi ve Add Header bir Action filtresi) ve pipeline ı kısa devre yaptırıyor.

AddHeader filter SomeResource action ı için asla çalışmaz.


[AddHeader("Author", "Steve Smith @ardalis")]
public class SampleController : Controller
{
public IActionResult Index()
{
return Content("Examine the headers using developer tools.");
}

[ShortCircuitingResourceFilter]
public IActionResult SomeResource()
{
return Content("Successful access to resource - header should be set.");
}

ASP.NET Core MVC Filters (Filtreler) – 4

Filtrelerin Çalışma Kapsamları ve Sıralaması

Bu makalemde ASP.NEt Core MVC Filtrer ların çalışma zamanı kapsamlarını inceleyeceğiz.  ASP.NET Core MVC Filter ile ilgili önceki yazılarımı okumanızı tavsiye ederim.

Bir filtre pipeline a üç kapsamdan biri ile eklenebilir. Dilerseniz belirli bir contoller yada action a attribute kullanarak ekleyebilirsiniz. Bunun yerine filtrenizi tüm controller ve action lar için global olarak Startup sınıfı içerisindeki ConfigureService metodunda MvcOptions.Filters koleksiyonuna kayıt edebilirsiniz.


public void ConfigureServices(IServiceCollection services)
{
 services.AddMvc(options =>
 {
 options.Filters.Add(new AddHeaderAttribute("GlobalAddHeader",
 "Result filter added to MvcOptions.Filters")); // an instance
 options.Filters.Add(typeof(SampleActionFilter)); // by type
 options.Filters.Add(new SampleGlobalActionFilter()); // an instance
 });
 services.AddScoped<AddHeaderFilterWithDi>();
}

Varsayılan Çalıştırma Sırası

Pipeline ın belirli evrelerine bir çok filtre eklediğiniz zaman, kapsam varsayılan filtre yürütme sırasını belirler. Global filtreler class filtrelerini çevreler, class filtrelerde metot filtrelerini çevreler. Matruşkaya benzer bir yapıdır. Bu iç içe yapı sayesinde filtrelerimizdeki after kodlarımız before kodlarımızın ters sırası ile çalışır.

  • Global uygulanan before filtre kodları
    • Controller lara uygulanan before filtre kodları
      • Action lara uygulanan before filtre kodları
      • Action lara uygulanan after filtre kodları
    • Controller lara uygulanan after filtre kodları
  • Global uygulanan after filtre kodları

Senkron action filtreleri için filtre metotlarının çağırılma sırası

Sequence Filter scope Filter method
1 Global OnActionExecuting
2 Controller OnActionExecuting
3 Method OnActionExecuting
4 Method OnActionExecuted
5 Controller OnActionExecuted
6 Global OnActionExecuted

Eğer Asenkron bir filtre içerisinde isek OnStageExecutionAsync metodu, tüm filtreleri stack içerisinde dar bir kapsamda çalışır.

Varsayılan Sıralamayı Değiştirme

Varsayılan çalıştırma sıralamasını IOrderFilter ın uygulanması ile override edebiliriz. Bu interface sıralama işlemi için Order property sini sağlar. Order özelliği kapsamdaki yürütme sırasını belirler.

Daha düşük Order değerine sahip filtrenin before kodu yüksek Order değerine sahip filtrenin before kodundan önce çalışır.

Daha düşük Order değerine sahip filtrenin after kodu yüksek Order değerine sahip filtrenin after kodundan sonra çalışır.

Order property sinin değerini yapıcı metot ile verebilirsiniz.


[MyFilter(Name = "Controller Level Attribute", Order=1)]

Aynı 3 Action filtresine sahipseniz ve controller ve global filtrelerin Order özelliklerini sırası ile 1 ve 2 olarak ayarlarsanız yürütme sırası tersine çevrilmiş olur.

Sequence Filter scope Order property Filter method
1 Method 0 OnActionExecuting
2 Controller 1 OnActionExecuting
3 Global 2 OnActionExecuting
4 Global 2 OnActionExecuted
5 Controller 1 OnActionExecuted
6 Method 0 OnActionExecuted

Order özelliği filtrelerin çalışma sırasını belirlemek için mükemmeldir. Filtreler öncelikle Order değerine göre sıralanır. Tüm built-in filtreler IOrderedFilter arayüzünü uygular ve varsayılan olarak Order özelliğinin değeri 0 dır. Sıralamak için tek yapmanız gereken 0 dan başka değerler vermek.

 

ASP.NET Core MVC Filters (Filtreler) – 3

Built-In Filters

Bu makalemde Built-in Filter Attribute leri ele alacağım. ASP.NET Core MVC Filter ile ilgili önceki yazılarımı okumanızı tavsiye ederim.

Framework, alt sınıflar üretip özelleştirebileceğiniz built-in attribute tabanlı filtreler içerir. Örneğin aşağıda Result filter Response a bir header eklemekte.


using Microsoft.AspNetCore.Mvc.Filters;

namespace FiltersSample.Filters
{
public class AddHeaderAttribute : ResultFilterAttribute
{
private readonly string _name;
private readonly string _value;

public AddHeaderAttribute(string name, string value)
{
_name = name;
_value = value;
}
public override void OnResultExecuting(ResultExecutingContext context)
{
context.HttpContext.Response.Headers.Add(
_name, new string[] { _value });
base.OnResultExecuting(context);
}
}
}

Attributeler filtrelere argüman geçirmemizi izin verir. Üstteki örnekte gösterildiği gibi. Artık aşağıdaki gibi bu attribute, controller veya action metodumuza ekleyebilir ve özel name-value anahtarlarımızı HTTP Header a gönderebiliriz.


[AddHeader("Author", "Steve Smith @ardalis")]
public class SampleController : Controller
{
public IActionResult Index()
{
return Content("Examine the headers using developer tools.");
}

[ShortCircuitingResourceFilter]
public IActionResult SomeResource()
{
return Content("Successful access to resource - header should be set.");
}

Uyguladığımız index action nı istek aldığında sonuç aşağıdaki gibi olacaktır. Sağ altta Response Header a dikkat edin.

built in filter attribute

Filtre arayüzlerinin bir çoğu özel implementasyonlar için base sınıf olarak kullanabileceğimiz attributeler sunar.

  • ActionFilterAttribute
  • ExceptionFilterAttribute
  • ResultFilterAttribute
  • FormatFilterAttribute
  • ServiceFilterAttribute
  • TypeFilterAttribute

ASP.NET Core MVC Filters (Filtreler) – 2

Bu makaleden önce ASP.NET Core filtre yapısına giriş makalesi olan ASP.NET Core MVC Filters (Filtreler) – 1 yazımı okumanızı öneririm.

Daha önceki makalede filtrelerin ne olduğu ile ilgili bilgi vermiştim. Bu yazımda ise nasıl uygulandığı ile ilgili bilgi paylaşmak istiyorum.

ASP.NET Core Filters (Filtrelerin) uygulanması

Filtrelerin senkron ve asenkron desteği vardır. Bunu farklı interface tanımlamaları sayesinde gerçekleştirebiliriz. Gerçekleştirilecek göreve göre senkron ya da asenkron olarak istediğiniz varyasyonu seçebilirsiniz.

Pipeline evresinden önce veya sonra kod çalıştırabilen senkron filtreler OnStageExecuting ve OnStageExecuted methodlarını tanımlar. Örneğin OnActionExecuting action metot çalışmadan önce çağrılır. OnActionExecuted ise action metot çalıştıktan sonra çağrılır.


using FiltersSample.Helper;
using Microsoft.AspNetCore.Mvc.Filters;

namespace FiltersSample.Filters
{
#region snippet_ActionFilter
public class SampleActionFilter : IActionFilter
{
public void OnActionExecuting(ActionExecutingContext context)
{
// do something before the action executes
}

public void OnActionExecuted(ActionExecutedContext context)
{
// do something after the action executes
}
}
#endregion
}

Asenkron filtreler tek bir OnStageExecutionAsync metodu ile tanımlanır. Bu metot filtrenin pipeline evresini yürüten bir FilterTypeExecutionDelegate temsilcisi alır. Örneğin; ActionExecutionDelegate action metot çağırır ve siz kodunuz içerisinde dilediğiniz yerde kullanabilirsiniz. Aşağıdaki örnekte durum incelenmiştir.


using System.Threading.Tasks;

using Microsoft.AspNetCore.Mvc.Filters;

namespace FiltersSample.Filters

{

public class SampleAsyncActionFilter : IAsyncActionFilter

{

public async Task OnActionExecutionAsync(

ActionExecutingContext context,

ActionExecutionDelegate next)

{

// do something before the action executes

await next();

// do something after the action executes

}

}}

Dilerseniz tek bir class’ a  içerisinde bir çok filtre evresini ele almak için birden fazla interface uygulayabilirsiniz. Örneğin ActionFilterAttribute abstract sınıfı IActionFilter ve IResultFilter ı uygular. Asenkron biçimlerini de aynı şekilde ele alınabilir.

IFilterFactory Arayüzü

IFilterFactory interface i IFilter interface ini uygular. Böylece bir IFilterFactory örneği filter pipeline da herhangi bir yerde bir IFilter örneği gibi kullanılabilir. Framework filtreyi çağırmaya hazırlanırken onu bir IFilterFactory’ ye cast etmeye çalışır. Eğer cast başarılı ise CreateInstance metodu IFilter örneğini oluşturmak için tetiklenir. Bu yapı bize oldukça esnek bir yapı tasarım kazandırır. Çünkü artık uygulama başlarken filter pipeline nın hassasça ayarlanmasına gerek kalmamıştır.

IFilterFactory interface ini kendi Attribute uygulamalarınızda kullanarak filtre oluşturma işlemlerinde farklı bir yaklaşım olarak kullanabilirsiniz.


public class AddHeaderWithFactoryAttribute : Attribute, IFilterFactory

{

// Implement IFilterFactory

public IFilterMetadata CreateInstance(IServiceProvider serviceProvider)

{

return new InternalAddHeaderFilter();

}

private class InternalAddHeaderFilter : IResultFilter

{

public void OnResultExecuting(ResultExecutingContext context)

{

context.HttpContext.Response.Headers.Add(

"Internal", new string[] { "Header Added" });

}

public void OnResultExecuted(ResultExecutedContext context)

{

}

}

public bool IsReusable

{

get

{

return false;

}

}

}

ASP.NET Core MVC Filters (Filtreler) – 1

Dün akşam Coder Bilişim Akademisi’ nde verdiğim eğitimde anlattığım konuyu blogumda da makale olarak yayınlamak istedim. Umarım sizin için faydalı olur.

ASP.NET Core MVC içinde filtreler belirli bir evreden önce veya sonra kodlarınızı çalıştırmanıza izin verir.

Yapı içerisine dahil (Built-in) filtreler bazı görevleri yerine getirmek için önceden hazırlanmıştır. Örneğin authorization yetkisiz kullanıcıların kaynaklara erişimini engellemek için kullanılmakta, bir diğeri tüm isteklerin HTTPS üzerinden geldiğinden emin olmak ve response caching gibi cache den cevap dönerek istek hattında kısa devre yapmak gibi.

Eğer isterseniz kendi özel filtrelerinizi geliştirerek uygulamanızdaki çapraz kesişimleri ele alabilirsiniz. İşlemler arasında kod kopyalamaktan kaçınmak istediğinizde, filtreler size çözüm sunacaktır. Örneğin hataların yakalamak için geliştireceğiniz kodları exception filer içerisinde ele alabilirsiniz. Böylece uygulama genelinde beklenmedik durumlar için kurallar uygulayabilirsiniz.

Nasıl Çalışır ?

Filtreler MVC Action Invocation Pipeline içerisinde çalışır. Buna kimi zaman Filter Pipeline da denilir. Filter pipeline, MVC action ı seçtikten hemen sonra çalıştırılır.

filter pipeline

Filtre Tipleri (Filter Types)

Her bir filtre tipi filter pipeline da farklı evrelerde çalışır.

  • Authorization filter : Bu filtre ilk kez kullanıcının geçerli istek için yetkili olup olmadığını belirlemek için kullanılır ve çalıştırılır.
  • Resource filter : Kimlik doğrulamadan sonra çalışan ilk filtredir. Filter pipeline nın geri kalanından önce kodlarımızı çalıştırabilir ve sonra filter pipeline ‘ı tamamlayabiliriz. Resource filter caching işlemleri için ya da diğer performans için yapacağımız kısa devre işlemleri için kullanışlıdırlar.
  • Action filter : Action filter lar action metot kodlarından hemen önce ve sonra çağrılırlar. Bir action’ a geçen parametreleri ya da dönen sonuçları manipüle etmek için kullanılırlar.
  • Exception filter : İstisna filtreleri yanıt gövdesine herhangi bir şey yazılmadan önce ortaya çıkan işlenmemiş istisnalara genel ilkeler uygulamak için kullanılır.
  • Result filter : Sonuç filtreleri, action sonuçlarının gerçekleştirilmesinden hemen önce ve sonra kod çalıştırabilir. Dikkat edilmesi gereken nokta ise yalnızca action başarılı bir şekilde yürütüldüğünde çalışırlar.

Aşağıdaki şekil bu filtrelerin filter pipeline içerisinde nasıl etkileşimde olduğunu gösterir.

filter pipeline 2

Şimdilik bu kadar başka bir makalede filtre uygulamalarını da ele alacağım.

 

Kaynak : http://docs.asp.net

 

ASP.NET Core MVC project.json Elveda. Merhaba Yeni csproj

Nerede project.json ?

Peki bağımlılıklarımı nasıl yöneteceğim ?

Gün geçmiyor ki Microsoft yeni bir şeyler yapmasın. .NET Core, ASP.NET Core ve Visual Studio 2017 yi takip edenler bilir sürekli bir güncelleme ve değişiklik içerisinde ilerliyor projeler. Biz geliştiriceler için yeni fırsatlar ile birlikte işimizi kolaylaştırmak için yapılsada bir çok takipçinin github, twitter, blog vb. mecralarda yaptığı yayınlardan değişiklere yetişip adapte olunmasının güç olduğu aşikar. Bu nedenle geçtiğimiz 6 ay içerisinde Visual Studio 2017 RC ile birlikte csproj dosyalarında yapılan değişiklikten bahsetmek istedim.

Biraz işin geçmişini inceleyelim

Biraz geri çekilip, .NET Core ve ASP.NET Core ‘un tarihini anlamaya çalışayım. ASP.NET Core (daha önce ASP.NET 5 olarak adlandırılmıştı) için beta öncesinde ASP.NET ve .NET ekipleri birbirlerinden bağımsız olarak çalışıyordu. .NET ekibi, .NET çekirdeğinin API yüzeyinde yoğun bir şekilde çalışıyorken, ASP.NET ekibi .NET ekibinin hazırladığı API’nin üstünde ASP.NET Core uygulama platformunda çalışıyordu. ASP.NET Core ile çalışmak için kullanılan araç, erken bir önizlemeydi ve o sırada DNVM ve DNU komutlarını kullanıyorduk. DNVM ve DNU o zamandan beri dotnet CLI’yi oluşturmak için birleştirildi ve değiştirildi.

ASP.NET projelerinin geliştirilmesini destekleyen ekip, yeni bir proje dosyası biçimini geliştirmeye karar verdi. Birincisi project.json, csproj tabanlı projelerle çalışan topluluğun yaşadığı birçok sorunu ele alıyordu ve daha basit bir yapıydı. O zamanlar, özellikle .NET Core projeleri için hiçbir şey mevcut yada kesin değildi. Henüz yeni geliştiriliyordu. ASP.NET Core platformu için yeni bir başlangıç oluşturulduğundan, değişiklik yapmak için iyi bir zaman olduğunu düşündüler. Betalarda ve sürüm adayı sırasında, web uygulamaları oluştururken insanlar yeni project.json ve xproj tabanlı çözümleri kullanıp test etmeye başladı. Yanıt gerçekten çok olumluydu. Project.json, bağımlılıkların otomatik tamamlanması, okunmasının kolaylığı ve daha basit bir genel yapı sağladı.

Şahsen project.json ile çalışmaya bende oldukça hızlı adapte oldum. tüm bağımlılıkların tek yerden hızlı ve pratik yönetilmesi işlerimizi kolaylaştırdı. Öyleki bugüne kadar bir projenin bağımlılıklarını yeni versiyonları ile değiştirmek hiç bu kadar basit, hızlı ve sorunsuz olmamıştı.

Ancak sürüm adayı periodunda kararlarda değişimler oldu. Aslına bakarsanız öncesinde daha geniş bir çerçevede düşünülmesi gereken bir durumdu. Ne mi? Yeni bir ASP.NET Core projesine başladıysanız sorun yoktu. Peki eski bir projenizi taşımaya karar verdiyseniz. Tabi birde diğer .NET proje tipleri sözkonusu. Geliştiriciler project.json hakkındaki endişelerini ve MSBuild içerisinde desteklenmediğini paylaşmaya başlamışlardı.Tüm bunlar monolit projeler için ne anlam taşıyordu ? Bu projeler .NET Core a nasıl taşınacaktı ? Adil olmak gerekirse bu endişelerinde haklılardı. Özetle yeni bir ASP.NET Core projesine başlayıp project.json ın imkanları ile geliştirme yapmak harikaydı. Fakat eski bir projeyi taşımak ekstra çaba ve gayret gerektiriyordu. Bunları göz önünde bulunduran ekip daha geniş bir .NET proje biçimi etrafında kararlar almaya başladı. Kararları gecikmişte olsa oldukça yerinde bir karar olduğunu itiraf etmeliyiz. Bir duyuru
ile project.json ‘ın geriye doğru MSBuild uyumluluğu için csproj formatının hazır olduğunu bildirdiler.ASP.NET Core 1.0 ın RTM öncesinde tamamlanması için çok geçti. Fakat bu gelişmenin Visual Studio 2017 ile kullanılabileceği hakkında da söylemler olmuştu.

Ve bu bizi bugüne getiriyor, Visual Studio 2017 RC ilan edildi. Bununla birlikte yeni (veya eski demeliyiz) csproj proje formatını kullanan projeler üzerinde çalışabiliriz. Neyin değiştiğini görmek için dosyaya bir bakalım.

Visual Studio 2015 in project.json’ı ile Visual Studio 2017 RC’nin csproj’unu karşılaştıralım

Microsoft, project.json dosyasının geliştiricilere, geliştirilmiş csproj formatında yaptığı iyileştirmelerin birçoğunu taşımak istedikleri değişim üzerinde çalışırken güvence verdi.

project.json csproj karşılaştırması
project.json csproj karşılaştırması

Yukarıdaki resimde varsayılan template ile Visual Studio 2015 (soldaki) ve visual Studio 2017 (sağdaki) de birer web application başlattım. Resimdende anlayacağınız üzere en belirgin fark project.json ın, json formatına sahipken yeni csproj formatının xml olması.Dosyalarda satır uzunlukları arasındaki farkın fazla olmadığına dikkat edin. project.json 65 satır, csproj ise 77 satır. Geleneksel csproj hatlarında bir azalma söz konusu.

Benim düşüncem her ne kadar Microsoft csproj da iyileştirmeler yaparak gürültüyü azaltsada xml tag ‘leri arasında aradığımı bulmaya çalışmak json formatına göre zor geliyor.

Bir de hoşuma giden avantajdan bahsetmek istiyorum. Csproj dosyasının project.json üzerine güzel bir avantajı artık (Core olmayan) NET projelerine de referanslar ekleyebilmemizdir. Daha önce entegrasyon mevcut değildi.

Pek hoşuma gitmeyen bir durumda, ben yazarken paketlerin ve sürümlerin uygun olanı otomatik tamamlanması durumu artık yok. Project.json ile bir bağımlılık adını yazmaya başladığımda Visual Studio bana olasılıkları Intellisense özelliği ile sunuyordu. Bu, csproj dosyasında yok gibi görünüyor. Şahsen ben sadece bazı durumlar için temel intellisense gördüm, ama hepsi değil, sadece xml etiketlerinde var.

Kısaca project.json ve yeni csproj formatına değinmeye çalıştım. Daha sonra project.json migrating konusunu da ele alacağım.