Apa cara terbaik untuk menangani referensi dalam aplikasi .NET

9

Baru-baru ini di tempat kerja kami mengalami masalah di mana kami menandai / bercabang proyek dan memiliki beberapa masalah kompilasi karena dll / referensi proyek yang menunjuk ke struktur folder lama.

Kami membuat folder 'bin eksternal' untuk masing-masing proyek dan menyalin dll yang direferensikan ke folder ini. Apakah ini cara terbaik atau adakah standar industri khusus untuk menangani ini?

c#

— Andre Lombaard
sumber

21

Saya akan mengatakan bahwa nuget adalah cara terbaik untuk menangani dependensi.

nuget dapat mengelola versi DAN secara otomatis mengunduh dependensi dari server nuget lokal Anda .

Sangat mudah untuk membuat / mengkonfigurasi server lokal. Cukup buat proyek ASP.NET kosong baru dan instal nuget-serverpaket nuget (menggunakan nuget;).

Itu juga berarti bahwa Anda tidak perlu memeriksa semua dependensi dan / atau mengelola versinya menggunakan TFS.

— jgauffin
sumber

1

Saya menemukan bahwa sebagian besar perusahaan gagal memanfaatkan ini dengan baik. Bahkan, saya belum melihat build server yang dikonfigurasi dengan benar untuk mendapatkan manfaat dari ini, jadi +1 untuk sesuatu yang ingin saya lihat di mana-mana.

— deltree

Saya berencana untuk mengajukan pertanyaan jika nuget tidak dapat dituliskan skrip (atau sesuatu) untuk menjaga paket tidak berversi dan mengunduh dependensi secara otomatis ... Dan hasil pencarian pertama memberi tahu saya bahwa nuget mendukung ini di luar kebiasaan! Terima kasih!

— Mormegil

5

Ini tidak benar-benar - Microsoft mengatakan cara terbaik untuk menangani referensi adalah membangun proyek Anda dalam satu solusi besar. Ya, saya tahu, mereka benar-benar bersungguh-sungguh juga.

Tim pola dan praktik telah menggabungkan praktik terbaik mereka dengan TFS, tetapi berlaku untuk bangunan umum. Ada 3 jenis pengaturan solusi, "1 solusi besar", pendekatan yang dipartisi yang sangat mirip dengan cara kebanyakan orang mengelola bangunan dengan membangun secara bergantian dan menyalin artefak ke direktori umum (yang tidak dibantu oleh .NET tidak memiliki jalur 'sertakan' atau 'pustaka' di seluruh server untuk referensi), dan pengaturan Beberapa Solusi yang merupakan versi yang lebih kompleks dari yang dipartisi.

Mereka bilang

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

Untuk TFS, mereka merekomendasikan untuk melakukan percabangan proyek eksternal di dalam proyek Anda, daripada mengandalkan pemetaan ruang kerja yang lebih mirip dengan eksternal subversi. Secara pribadi, saya pikir saran mereka tidak ada praktik terbaik, tapi saya kira mereka mencoba untuk meminimalkan masalah pembangunan yang akan Anda dapatkan ketika menggunakan referensi.

Saya memiliki masalah dengan .NET build yang mencoba untuk pintas sistem dengan hanya membangun apa yang diperlukan, membangun malam yang melakukan segalanya, dan menyalin setiap perakitan baru ke direktori adalah cara terbaik bagi semua orang untuk tetap sinkron - terutama para penguji. Catatan ini benar-benar hanya berlaku untuk aplikasi .NET, C ++ yang cenderung masih berfungsi karena mereka tidak memiliki rakitan berversi atau aspek serupa yang dapat menyebabkan masalah dengan komponen panggilan. Pendekatan ini bekerja dengan baik, tetapi Anda tidak selalu bisa berasumsi bahwa build parsial baik-baik saja, menyelesaikan semuanya dan membangun kembali adalah yang paling aman.

— gbjbaanb
sumber

Ini masuk akal, satu solusi yang mengandung banyak proyek (DLL API Anda, proyek aplikasi).

— Mengintai

1

Ini tergantung pada bagaimana solusi Anda disusun dan apa kemampuan perangkat lunak kontrol versi Anda. Sebelumnya, kami biasa menyimpan proyek yang tidak dibangun / dilewati dalam solusi kami yang menyimpan dokumentasi dan folder khusus untuk perpustakaan referensi pihak ketiga mana pun. Karena itu adalah bagian dari solusi, jalur ke file-file ini dapat dirujuk menggunakan jalur relatif. Setelah kami pindah ke TFS 2010, singkirkan proyek ini dan cukup tambahkan direktori "Dukungan" di folder solusi di proyek tim yang sejajar dengan cabang utama kami. Dalam kedua kasus, versi kontrol sumber perpustakaan akhirnya berada di tempat yang sama relatif terlepas dari bagaimana para pengembang telah mengkonfigurasi mesin mereka.

— Joel Etherton
sumber

0

Saat menggunakan subversi untuk kontrol versi, Anda dapat memanfaatkan properti "eksternal" untuk tujuan ini. Ini memungkinkan Anda untuk menyimpan salinan lokal dari DLL bersama di jalur relatif di dekat proyek Anda saat ini. Itu membuatnya mudah untuk mereferensikan DLL dengan jalur file relatif yang tidak berubah, bahkan ketika Anda mengubah direktori utama proyek Anda ke folder yang berbeda. Eksternal memungkinkan Anda juga menentukan versi spesifik atau revisi untuk dimasukkan.

— Doc Brown
sumber