Bagikan kelas C# dari perpustakaan kelas yang direferensikan melalui perpustakaan lain

Saya membuat perpustakaan kelas (MyLib), yang berisi kelas publik A. Kelas itu menentukan metode publik M yang mengembalikan turunan kelas B dari perpustakaan kelas eksternal (ExtLib).

Untuk menggunakan MyLib.A.M(), pengguna yang akan menggunakan perpustakaan kelas saya harus mereferensikan MyLib dan ExtLib.

Pertanyaan saya adalah, apakah mungkin membuat kelas ExtLib.B dapat diakses langsung melalui MyLib (misal: MyLib.B) sehingga pengguna tidak perlu mereferensikan kedua perpustakaan, tetapi hanya MyLib?


class c# dll
person STremblay    schedule 13.04.2016    source sumber
comment
Bagaimana pengguna dapat mengakses tipe eksternal jika mereka tidak mereferensikannya?   -  person Wjdavis5    schedule 13.04.2016
comment
Tidak. Itu tidak mungkin.   -  person Jcl    schedule 13.04.2016
comment
Anda dapat memuat rakitan ExtLib menggunakan Refleksi.   -  person Gosha_Fighten    schedule 13.04.2016
comment
@Gosha_Fighten atau Anda bisa mengeluarkan tipe tersebut saat runtime, tapi menurut saya bukan itu yang diminta OP: jika dia tidak menggunakan B (seperti pada: dengan cara yang aman untuk tipe), maka dia sebenarnya tidak memerlukan referensi ExtLib   -  person Jcl    schedule 13.04.2016
comment
Anda dapat mencoba ini: stackoverflow.com/questions/1829531/   -  person Mike Cheel    schedule 13.04.2016
comment
Gunakan ILMerge untuk ini.   -  person Greg Ferreri    schedule 13.04.2016
comment
@MikeCheel sebenarnya, ILMerge bisa menjadi solusi terbaik mengingat skenario ini. Kemungkinan lain adalah membuat pembungkus penuh di sekitar objek B, tapi itu tidak masuk akal jika tujuannya adalah untuk menghindari referensi (referensi yang dimiliki oleh perpustakaan utama)   -  person Jcl    schedule 13.04.2016
comment
Selain itu, bergantung pada seberapa kocaknya Anda dan jenis rakitan, Anda dapat membuka rakitan pihak ketiga dalam sesuatu seperti JustCompile, dekompilasi, dan cukup angkat kode yang Anda perlukan. Saya pernah melakukannya sebelumnya pada kesempatan langka =)   -  person Mike Cheel    schedule 13.04.2016
comment
@MikeCheel ILMerge akan menghasilkan perakitan lain. Jadi, jika ada perubahan di ExtLib, Majelis yang ada harus digabungkan kembali. Memancarkan menurut saya adalah pilihan yang lebih baik. Anda dapat melintasi semua properti B pada waktu JITing dan mengkompilasi properti baru jika ditambahkan. Namun, di sisi lain, harus ada antarmuka yang diimplementasikan dalam rakitan MyLib yang memperlihatkan properti baru. Jadi, MyLib juga harus diubah.   -  person Gosha_Fighten    schedule 13.04.2016

Jawaban (1)


arrow_upward
1
arrow_downward

Anda sebaiknya menerima bahwa pengguna Anda harus mereferensikan Majelis Anda dan yang mendukungnya.

Ya, Anda mungkin bisa mulai bekerja, sehingga rakitan pendukung dimasukkan secara keseluruhan ke dalam rakitan Anda sendiri. Namun hal ini sepenuhnya mengikat jadwal rilis rakitan Anda dengan jadwal rilis rakitan pendukung. Tidak mungkin rakitan pendukung diperbarui untuk digunakan dengan rakitan Anda tanpa merilis ulang rakitan Anda juga.

Ada juga pertanyaan tentang hak cipta dan lisensi. Jika Anda juga menulis majelis pendukung, saya rasa Anda tidak akan mengalami kesulitan sama sekali. Namun sebaliknya, menggabungkan majelis pendukung dengan majelis Anda mungkin paling tidak tidak disukai oleh pembuat majelis tersebut, atau bahkan dilarang sama sekali.

Opsi buruk lainnya mungkin adalah mengembalikan objek dynamic dari API Majelis Anda alih-alih tipe yang dideklarasikan dalam Majelis pendukung. Hal ini tentu saja akan memiliki kemungkinan dampak kinerja, dan juga akan meniadakan kemungkinan keamanan tipe waktu kompilasi yang seharusnya menjadi manfaat normal menggunakan bahasa seperti C#. Tapi itu bisa dilakukan.

Jika Anda benar-benar tidak tahan dengan gagasan pengguna menambahkan referensi ke perpustakaan pendukung, opsi yang masuk akal dari sudut pandang rekayasa perangkat lunak adalah mengubah API Majelis Anda sehingga tidak mengembalikan tipe dari perpustakaan pendukung. Mereka masih memerlukan Majelis itu pada saat run-time jika Anda menggunakannya, tetapi setidaknya kode pengguna tidak memerlukan referensi eksplisit. Sebaliknya, API Anda akan mengembalikan tipe yang dideklarasikan oleh Majelis Anda sendiri dan yang menggabungkan tipe Majelis pendukung, mungkin memodifikasi antarmuka tipe tersebut (menghapus anggota yang tidak diperlukan, menambahkan ekstensi baru, dll.) agar lebih sesuai dengan kebutuhan pengguna Anda. Dengan begitu tipe rakitan pendukung disembunyikan dari pandangan sehingga tidak memerlukan referensi eksplisit oleh rakitan pengguna Anda.


IMHO perlu diperhatikan bahwa pengguna Anda sudah mereferensikan banyak rakitan lain tempat rakitan Anda bergantung, yaitu jika tidak ada yang lain, setidaknya berbagai rakitan .NET. Memang benar, banyak di antaranya yang diperlukan agar kode .NET dapat berfungsi sehingga proyek pengguna sudah memiliki referensi ini, namun referensi tersebut masih mewakili referensi perakitan tambahan. Rakitan .NET non-default lainnya mungkin diperlukan atau tidak, bergantung pada apa lagi yang digunakan rakitan Anda dan dikembalikan ke kode pengguna. Bagaimanapun juga, hal semacam ini cukup umum dan bukan sesuatu yang harus menghabiskan banyak waktu untuk menghindarinya.

Sekali lagi, faktanya adalah bahwa perakitan pendukung akan diperlukan pada saat run-time. Jadi sepertinya tidak terlalu sulit untuk meminta perakitan tersebut direferensikan oleh proyek pengguna sendiri. Rakitan referensi yang mendeklarasikan tipe kodenya sendiri bergantung pada cara kerja .NET. Mengapa melawannya? Masalah menarik apa yang mungkin dapat memotivasi upaya nyata untuk menghindari referensi tambahan dari proyek pengguna?

person Peter Duniho    schedule 14.04.2016
comment
Saya akan menjawab pertanyaan Anda Apa ... masalah yang bisa ... memotivasi menempatkan ... upaya untuk menghindari referensi ini Jawabannya sederhana, tugas sekolah dengan batasan yang dikenakan (sesudahnya) di mana perakitan A harus menggunakan antarmuka perakitan B saja , dan rakitan B hanya menggunakan antarmuka rakitan C. Namun, saya sudah merancang Majelis C sehingga beberapa kelas akan berguna untuk Majelis A dan B, sebelum diberitahu tentang kendala tersebut. Jadi saya mencari cara untuk mengganti nama kelas tersebut dari C dan membuatnya terlihat seperti milik B. - person STremblay; 15.04.2016
comment
Ah. Tugas sekolah? Maka jawabannya mudah: bungkus tipe rakitan pendukung dengan tipe rakitan Anda sendiri (yaitu opsi ketiga yang saya sarankan di atas). Batasan tersebut sudah sewenang-wenang, diberlakukan karena alasan akademis; tidak ada alasan untuk membuang waktu mencari solusi yang lebih pintar dari itu. (Selain itu, masih bisa diperdebatkan apakah penggunaan ilmerge akan mematuhi batasan yang diberlakukan, karena hal ini sama saja dengan mengeluarkan rakitan pendukung dari persamaan sepenuhnya, atau tidak mengubah pemaparan tipe dan rakitannya, tergantung pada bagaimana seseorang melihatnya. dia.) - person Peter Duniho; 15.04.2016
comment
Terima kasih, saya akan melanjutkan dengan pembungkusnya, itu adalah ide pertama saya, tetapi saya bertanya-tanya apakah ada semacam mekanisme impor terintegrasi yang secara otomatis dapat memasukkan beberapa bagian dari suatu rakitan ke bagian lain. Jawabannya sepertinya tidak, jadi saya pilih bungkusnya! - person STremblay; 15.04.2016