.Cs dosyalarını .cs dosyalarını projelere bağlamak üzerine kullanmanın avantajları (kendi genel yardımcı sınıfları / uzantım yöntemleri için)

Yarattığım tüm uygulamalarda kullandığım yardımcı bir projem var. Bazı uzatma yöntemleri ve bir sürü genel yardımcı sınıf, kontrol vb. İçerir. Yardımcı projeyi zaman zaman güncellerim / genişletirim. Bunlar genellikle küçük ve ilgisiz projelerdir ve hepsinde çalışan tek kişi benim.

Kullanmak için iki yaklaşım denedim

• kullandığım her projeye .cs dosyalarını doğrudan (bağlantı olarak ekle) ekleyin
• .dll olarak derleyin ve başvuru olarak ekleyin

Bu yaklaşımların bazı faydalarını ve sakıncalarını görüyorum.
İlki:

• daha basittir, çünkü yardımcı sınıflar exe dosyasına derlenir, bu yüzden genellikle çok iyi çalışacak sadece tek bir .exe dosyası sağlayabilirim. Bağlantı olarak eklediğim için, yardımcı kullanan herhangi bir proje oluşturduğumda, yardımcı dosyaların en son sürüm olacağından emin olabilirim.
• Daha da basit, çünkü dosyaları ayırabilirim, böylece .NET 4.0 üzerinde çalışan uzantı yöntemlerim, .NET 4.5 gerektiren programlardan ayrı olarak başvuruda bulunabilir; bu, bir bütün olarak uygulamanın .NET 4.0'da çalışabileceği anlamına gelir
• Kesme noktalarının vb. Tüm avantajlarıyla kodda hata ayıklamaya izin verir.
• 'en iyi uygulama' gibi görünmüyor

İkinci olan:

• doğru yaklaşım gibi görünüyor, ancak:
• Bir nedenden ötürü kullanıcılar için çok daha zor olan ayrı bir .dll dosyası teslim etmemi gerektiriyor (programlarmı .dll olmadan paylaşmaya meyillidirler;
• tek bir .dll dosyasına derlendiğinden, .NET'in en yüksek sürümünü gerektirir - kullanıcılarımın çoğu .NET 4.5'e sahip değil ve yalnızca yardımcı sınıfımın bazı öğeleri bunu gerektiriyor, bu da bazı insanları zorlayabileceğim anlamına geliyor sebepsiz yere sistemlerini güncellemek
• Ayrıca, programlarımdan herhangi birini ne zaman güncellersem, aynı zamanda .dll dosyasını da teslim ettiğimden emin olmalıyım - son sürümden beri değiştirilip değiştirilmediğini bilmeme rağmen (ancak olabilirdi, ama aynı sürümde olabilirdi). Bunu yapmanın basit bir yolunu göremiyorum, montaj versiyonunu takip etmeden ek bir iş. Şimdilik programlarımı güncellediğimde yalnızca güncellenmiş exe veriyorum ve küçük ve düşük profilli tutmayı seviyorum.

Peki, burada .dll dosyasını kullanmanın asıl yararı nedir? Lütfen, tüm uygulamaların ve yardımcı dosyaların kodunu düzenleyen tek kişi olduğumu unutmayın.

Ayrıca, açıklığa kavuşturmak için - uygulamalar genellikle çok azdır, oysa yardımcı sınıflarda yer alan kod hepsine tamamen geneldir (bazı basit dize karşılaştırmaları, yollar veya XML işlemleri vb.)

Aslında, birisi beni şimdi üçüncü bir seçenek olduğunu anlamamı sağladı. Ayrı bir projede yardımcı kodum olduğu için, bu projeyi ayrı ayrı uygulamalarımın çözümlerine ekleyebilirim - bu da tek bir dosya için 'bağlantı olarak ekle' gibi çalışır, ancak yalnızca tek bir proje eklerim ... Doc Brown tarafından fark edildiği gibi, bu aslında .dll projeye yine de eklenmesi gerekeceği anlamına gelir ...

Yine de dll dosyalarını kullanmama lehinde olan bir başka şey de yardımcı sınıf boyunca aktif olarak hata ayıklama yeteneği ...

Artıların ve eksilerin çoğunu zaten gördünüz. Cs dosyalarını referans olarak kullanmak gerçekten daha hafiftir ve yönetimi genellikle kolaydır. Ancak, csdosyalarınız tamamen kendi kendine yeten ve herhangi bir özel oluşturma gereksinimi olmadığında, bu yaklaşımı yalnızca kullanmanızı öneririm .

Ayrı DLL kullanmak

• Diğer yardımcı programlara veya kütüphanelere açık bir şekilde bağımlılık yapacak (bu tür bir bağımlılığa sahip olmadığınız sürece, iyi çalışacaktır)

• Belirli derleme yapılandırmaları tanımlamanıza izin verecektir (örneğin, bir sınıf yalnızca x86 yapılandırmasında çalışıyorsa veya en az .NET 4.0'a ihtiyaç duyuyorsa, derlemenin yapı yapılandırması bu gereksinimi açık hale getirir).

Bu yüzden özellikle çok sayıda tek sınıf, kendi kendine yeten bileşen varsa, dosyalara başvuru kullanmak iyi olabilir, ancak diğer bileşenleri veya belirli derleme gereksinimlerini gösteren bileşenleriniz varsa, DLL kullanmanızı öneririm.

Birçok ayrı DLL'yi yönetme ile ilgili sorunları azaltmak için, bir yükleyici paketi oluşturabilir veya bir derleme kümesini tek bir yürütülebilir dosyaya gömebilen ILMerge'den yararlanabilirsiniz . Çevremizde, her uygulama için bir betik komut dosyası kullanarak sorunu farklı şekilde ele alıyoruz. Bu komut dosyası, tüm gerekli DLL'lerin her zaman yeni bir uygulama sürümü yayımlandığında üretime teslim edilmesini sağlar.

Bir uygulama büyük olduğunda ve güncelleme gerektiren parçalar olduğunda, ancak uygulamanın tamamı için değil, DLL'ler kullanışlıdır. Bu nedenle, MS Word yazıyorsanız, yazım kontrol kodunun bir DLL dosyasında MS Word'ün tamamını güncellemek zorunda kalmadan güncellenebilecek olması yararlıdır. Yazdığınız şey küçük bir yardımcı program uygulamasıysa (veya hepsinin başına gelen aynı kodu kullanan bir dizi bağımsız uygulama), kodun uygulamalara gömülüp gömülmemesi fazla bir fark yaratmaz.

Sorunuzda hemen hemen özetlediniz, ekleyeceğim sadece birkaç nokta var.

Mono Options , ilk yaklaşımı çok iyi kullanan bir NuGet paketine harika bir örnektir.

Alternatif olarak, borçları kullanmaya karar verirseniz, söz konusu referansı gömülü bir kaynak olarak yürütülebilir dosyasına yerleştirmek için Costura gibi araçları kullanabilirsiniz . Kullanmak için sadece Costura.Fodypaketi ekleyin :

Install-Package Costura.Fody

Bir dll'nin daha faydalı olup olmadığı birkaç faktöre bağlıdır:

1. Kodun boyutu (derlendiğinde).
2. Kaç tane exes kullanıyor.
3. Kodu ne sıklıkla güncellemeyi düşünüyorsunuz?
4. Varoluşların bir arada tutulmaları mı yoksa tamamen ayrı olarak mı var olmaları gerektiği.

Paylaşılan bir kütüphanenin amacı, birden fazla çalıştırılabilir dosya için ortak olan kodu almak ve tüm çalıştırılabilirlerin bir kopyasını paylaşması için merkezileştirmektir. Bu, yerden tasarruf sağlamak ve kodun güncellenmesini kolaylaştırmak için tasarlanmıştır.

Yardımcı sınıfınızdaki kodun miktarı çok küçükse, kodun ek yükünün bir dll'de yer alması, onu merkezileştirmenin yerden tasarruf etme avantajını ortadan kaldırabileceğinden, onu bir dll'ye taşımayı hak etmeyebilir.

Ayrıca, yalnızca birkaç çalıştırılabilir dosya yapıyorsanız, her çalıştırılabilir koddaki kodun boyutu bir sorun olmayacak kadar küçük olabilir. Bununla birlikte, aynı kodu ne kadar çok çalıştırırsanız, kodun bir dll'ye taşınması o kadar faydalı olur.

Basitleştirilmiş bir örnek olarak, yardımcı sınıfınızın bir exe dosyasında 128 byte'a derlendiğini, ancak bir dll'ye taşındığında, dll'nin 512 bayttığını söyleyin. Eğer sadece 3 çalıştırıcınız varsa, kodu çalıştırılabilir dosyalara dahil ederek yerden tasarruf edersiniz. Ancak, 5 çalıştırılabilir hesabınız olsaydı, o zaman bir dll'den daha iyi olacağınız bir noktada olursunuz, çünkü kodun 5 kopyası (5 * 128 = 640 bayt) tarafından alınan birleştirilmiş alan, alınan alandan daha fazladır. kodu bir dll'de (512 bayt) alarak.

Şimdi, örneğin yardımcı kodunuzda bir hata bulduğunuzu söyleyin. Tüm çalıştırılabilir dosyalarınızı içinde kayıtlı olan kod ile derlerseniz, her çalıştırılabilir dosyayı derlemeniz ve ardından yeniden derlenmiş sürümleri yeniden dağıtmanız gerekir. Kodu bir dll'ye derlediyseniz, yalnızca bir dll'yi yeniden derlemeniz ve yeniden dağıtmanız gerekir ve hata, onu kullanan tüm yürütülebilir dosyalar için otomatik olarak düzeltilir.

Son olarak, bir programın bir dll bulması için dll'nin nereye bakacağını bilmesi gerekir. Tüm çalıştırılabilir dosyalarınızı bir arada tutuyorsanız, dll'yi aynı dizine koyabilirsiniz ve hepsi hemen bulurlar. Eğer onları kasıtlı olarak ayırıyorsanız, aynı dll'yi kullanmak için onları koordine etmek zorlaşır.

Üçüncü seçeneğiniz en uygunudur (çözümü ayrı bir "sınıf kütüphanesi" projesi olarak ekleyin). Bu, tüm yaklaşımların yararlarını birleştirir:

• "Yardım projeniz" her zaman tüm farklı projelerde güncel.
• Değişiklikleri hızla görmek istediğinizde projenin koduna başvurabilirsiniz.
• Her seferinde doğru .NET sürümü için oluşturabilirsiniz.
• Zaten bir exe bir DLL gömebilirsiniz, bu yüzden sadece derlemenin bir parçası olarak sahip olabileceği konusunda endişelenmeyin.

Bunu her zaman yapıyoruz ve hiçbir şey yapamıyorum ama bu yaklaşımı tavsiye ediyorum.

Bahsetmediğiniz bir başka dördüncü alternatif, onu doğru bir şekilde sürümlendirmenize ve her çözümde fazladan bir proje olmadan referans vermenize izin verecek özel bir NuGet deposuna koymak.

Bir geliştirici olarak, kodda hata ayıklamama izin verdiği için yardımcı programın çözümünün referansını her zaman eklemeyi seviyorum (ve Yardımcı Program'da olası hataları da görebiliyorum!) Ve uygulamada yapılan değişiklikler otomatik olarak uygulamaya dahil edilir.

Yani, aslında karar , Programın ne kadar olgun olduğuna bağlı ! Yardımcı program hatalarından emin değilseniz, hataları bulmak için her zaman bu yardımcı programın .cs dosyasını eklemelisiniz. Ancak, Yardımcı Programın yeterince olgun olduğundan ve bu tür hatalarla sonuç döndürmeyeceğinden eminseniz Yardımcı Programda geliştirme için bir kapsam değildir, devam edebilir ve DLL dosyasını dahil edebilirsiniz.