Kimi zaman uygulamalarımızda ihtiyaç gereği (örneğin plugin tabanlı bir mimari kullanılarak uygulama geliştirilirken) çalışma zamanında Reflection tekniklerini kullanarak dinamik assembly dosyalarını ilgili application domaine yükler ve kullanırız. Bu kısımda dikkat edilecek noktalardan birisi de biribirini kullanan assembly'ler varsa bağımlı olunan diğer assembly'lerin de yüklenmesini sağlamak gerekmetedir.




Kısa bir örnek üzerinden inceleyelim. Örneğimizde üç proje yer almakta.

cl1.dll : Ana uygulama tarafından kullanılacak assembly
cl2.dll : cl1.dll in bağımlı olduğu diğer dll
Diğer uygulama da test kodlarımızın yer aldığı projemiz.

cl1.dll içerisinde Class1.cs isimli kod dosyamız bulunuyor. İçeriği aşağıdaki gibidir. Tabiki cl2.dll i de referans edildiğini dikkate alıyoruz.

namespace cl1
{
    public class Class1
    {
        public int Test()
        {
            cl2.Class2 c2 = new cl2.Class2();
            return 2 * c2.Test();
        }
    }
}
cl2.dll içerisinde de Class2 isimli bir dosya bulunmakta ve içeriği de aşağıdaki gibidir.
namespace cl2
{
    public class Class2
    {
        public int  Test()
        {
            return 10;
        }
    }
}
Görüldüğü gibi Class1 sınıfının Test metodu çağrıldığında Class2 sınıfından bir nesne yaratılmakta ve onun da Test metodu çağrılmaktadır. Bu durumda eğer cl1.dll dinamik olarak yüklenir ve Test metodu kullanılmak istenirse cl2.dll in de application domaine yüklenmesi zorunluluğu ortaya çıkmaktadır. Bunun için de AppDomain sınıfının AssemblyResolve eventine kendi metodumuzu yazarak bir assembly application domaine yüklendiğinde eğer bağlı olduğu başka bir assembly var ise bu event ateşlenecek ve metodumuzda da ilgili assembly yi yükleme imkanı bulacağız. Örnek kod aşağıdaki gibidir.

  private void button1_Click(object sender, EventArgs e)
        {
            AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
            Assembly asm = Assembly.LoadFile(@"C:\temp\WindowsFormsApplication9\cl1\bin\Debug\cl1.dll");
            Type t = asm.GetType("cl1.Class1");
            object o = Activator.CreateInstance(t);
            MethodInfo mi = t.GetMethod("Test");
            int sonuc = (int)mi.Invoke(o,null);
        }

        Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
        {
            Assembly asm = Assembly.LoadFile(@"C:\temp\WindowsFormsApplication9\cl1\bin\Debug\"+args.Name.Split(',')[0]+".dll");
            return asm;
        }


 
Categories: .NET | C#

June 19, 2009
@ 05:22 PM
Gemiş zaman içinde bir blog girdisinde -ado.net takımının blog'u - artık OR/M konusunda baya yol alındığını .net ile OR/M  yapılacaksa bunun için Ado.net Entity Framework kullanılmasının tavsiye edildiğini LINQ to SQL konusunda ise duruma göre bakacaklarını müşterilerden gelen geribildirimlere göre de ilgileneceklerini içeren bir yazı okumuştuk. Maşallah iyi de etmişler yazmışlar çizmişler. Baştan söyledik, olmadı, hata ettiniz, gitmez bu böyle, düzeltin vs. diye. Yerine Ado.net Entity Framework getirdiler de biz daha "acaba mı? oldu mu ?" bir bakalım diyerek eleştirilerimize başlamadan Microsoft bize " But not Perfect" demişti bile. (Resim için Sefer Hoca'ya teşekkür ederim)



Neyse sağlık olsun dedik.Geliştirilmesi durduruldu, linq to sql öldü mü? ( google'da bir arayalım bakalım ?) diye herkes bişiler söylerken -ki herkes öldü diyor - Microsoft takımı yine sağ gösterip sol vurdu gibi geliyor bana. .NET 4.0 ile beraber oldukça fazla yenilikler ile değişerek karşımıza çıkmaya hazırlanıyor. Değişiklikleri ve iyileştirmeleri merak edenler şurdaki linkden - çok uzun olduğu için buraya kopyala yapıştır yaparak yazıyı boğmak istemedim - detayları inceleyebilirsiniz. Yani ne diyelim şimdi Linq to SQL ölmedi mi ?


 
Categories: .NET | Inceleme