Microsoft’un .net ile ilgili politikaları ileride tamamen .net platformu altyapısına sahip bir işletim sistemi çıkarması ile devam edecek. Şu an itibari ile .net’in performansı ne kadar iyi olsa da, tamamen .net platformu için geliştirilen bir işletim sisteminde performansı daha iyi olacaktır. İşletim sisteminin .net platformunun performansına niçin bu kadar etkide bulunduğunu ileride ele alıcagız.
.Net sadece MS işletim sistemi ailesi için geliştrilmiş bir platform değildir. Zaten .net’in tüm dünyanın ilgisini çekmesinin temel nedeni de .net’in yazılım konusunda platform bağımsızlığını sağlamayı hedefliyor olması. Tabii bunun için diğer işletim sistemleriyle de (Unix, Linux...) uyumlu çalışacak framework’lerin geliştirilmesi gerekmektedir. Macintosh ve FreeBSD için Microsoft Framework geliştirme çalışmalarına başlamış durumdadır. Bu yazılımlar da tamamlandıktan (yani framework ailesinin gelişimi tamamlandıktan) sonra MS .net platformu üzerinde geliştirilmiş bir yazılım Unix üzerindeki .net platformunda da çalışabilir olacaktır.

Peki bu işlemler nasıl gerçekleşecektir. .Net üzerinde çalıştırılan bir programın çalışma mantığı mevcut programların çalışma mantığından biraz daha farklıdır. Diğer bir deyişle .net ile geliştirilmiş bir .exe sadece framework ile konuşur, framework de işletim sistemi ile haberleşir. İsterseniz şimdi bir .net exe’sinin nasıl bir evre geçirdiğine bakalım:

Kaynak kod derlendiğinde .net compiler bu kaynak kodu MSIL (Microsoft Intermediate Language) denilen bir ara koda çevirir. Java’daki byte code mantığına benzer bir yapıda bulunur. Bu dosya .exe uzantılı ve Portable executable bir dosyadır. Çalıştırılmaya hazır ama henüz daha hiç çalıştırılmamış bir durumdadır. Bu dosyayı ilk sefer çalıştırılmak istendiğinde Just in time Compilation (JIT Compilation) denilen bir işlemle makine koduna çevriliyor. Artık .exe uzantılı dosyamızın içinde makina kodu bulunmaktadır ve cache’lenmiştir. Bu kodun cache’de bulunma süresi yine programlanabilmektedir. Bundan sonraki çalışmalarda cache’deki kod çağrılıyor ve daha hızlı bir şekilde çalışıyor. Dolayısı ile sadece ilk seferde kaynaklanan bir performans kaybının dışında iyi bir performans gösteriyor. Fremawork’un temelindeki assembly’lerde MSIL’in paketlenmiş halleridir. Yani bizler framework’un temelindeki assembly’leri kullanarak exe, Assembly veya module gibi IL’ler oluştururuz.

.Net ortamının bize sunduğu diğer avantajlardan biri de kullanılan dil konusunda sağladığı kolaylık. Yazılacak projenin pozisyonuna göre dikkat etmemiz gereken noktalar (performans, programın çalışacağı alan... ) vardır. .Net ortamında çalışan bütün diller çalışırken aynı performansı gösterirler yani aynı hızla çalışırlar. Kullanıdığımız dil sadece kaynak kodun MSIL’e dönüşümündeki süreyi etkiler. Daha sonraki seferlerde bu arakod aktivite edilecegi icin artık kaynak kod ile işimiz kalmamıştır. Sonuçta aynı işi yapan bütün .net dilleri (VB.net, c# ) ara koda çevrildiklerinde aynı MSIL’e sahip olacakları için birşey değişmeyecektir. Fakat yine de bir projenin hangi noktasında hangi dil ile yazılım geliştirdiğimiz önemlidir. Bunun sebeplerini ve faydalarını yine ileride ele alıcağız.

Bazen bir projede birden fazla dili kullanmak zorunda kalırız bunun için daha önceden Com objelerini kullanıyorduk. .Net ile birlikte bu işlemler için Com oblerinin yanı sıra Assembly’leri veya modulleri kullanabiliriz. Daha önceden Com objelerini kullanırken karşımıza çıkan bir sorun da dillerin tür uyumsuzluğu idi. Yani VB de tanımlı bazı türlerin C++ da olmaması gibi. VB de yazılmıs bir com objesinin variant tipi ile geri döndüğünü düşünürsek C++’da bu geri dönüş değerini alacak bir tür yoktur. Gerçi bir şekilde bu tip sorunlara çözüm buluyor idi ama gereksiz işgücü kaybı... .net platformunda tüm diller System namespace inin içindeki veri türlerini kullandığı için birbiri ile entegre çalışması gereken dillerde hiçbir uyumsuzluk yaşanmıyor. Çünkü C# da VB.net de aynı veri türleri ile işlem yapmaktadır.

.Net platformunun diğer bir yeniliği ise Java’dakine paralel bir mantıkta kaynakların kontrolü yani garbage collector mekanizması. Yazılımı gerçekleştirirken kullandığımız kaynaklar bizim müdahalemizde gerek kalmadan GC (garbage collector) tarafından kontrol ediliyor. Garbage Collector’ ün nasıl çalıştığından ileride bahsedeceğiz. İstediğimiz taktirde garbage collector’ü devre dışı bırakabiliriz. Fakat bu durumda kodumuzun .net uyumluluğu ortadan kalkar. Bu tür kodlara Unmanaged kod denir.

Frameworkun içinde ciddi bir kütüphane bulunmaktadır. Bu kütüphaneyi bütün .net dillerinde kullanabilriz. .Net ile gelen Data Access componentları(ADO.net) veritabanı işlemlerimizde ciddi avantajlar sağlamaktadır. Bunlarla ilgili ileride uygulamalar yapacağız. İşin güzel tarafı ise bu kütüphanelerin hepsini bütün .net dillerinde benzer yapılar içerisinde kullanacak olmamız. Dolayısı ile bu kütüphaneleri VB.net içinde kullanan birisi C# da kullanırken çok da zorlanmıyacaktır.

Bu makalede bahsetmediğim daha bir çok .net avantajlarından ileride fırsat buldukça bahsetmeye çalışacagım. Özellikle .net in Object Orianted bir yapı içerisinde olması ve bunun getirmiş olduğu avantajlardan daha ileride bahsedeceğim. Ayrıca yazımızın başından beri .net dilleri diyerek kastetmiş olduğum MS tabanlı .net dillerinin dışında diğer dillerin de .net versiyonlarının çalışmaları devam ediyor. VS.net içinde MS tabanlı olmayan dillerle de yazılım geliştirmek mümkündür. Bu işlem için VS.net de bir import mekanizması bulunmaktadır. Bu mekanizma ile Delphi.net‘i VS.net içinden kullanabileceğiz.