Pertanyaan Pengembangan lokal bebas rasa sakit sementara juga merujuk paket NuGet


Saya mencoba untuk mempublikasikan dan mengonsumsi paket-paket NuGet versi pustaka kelas sambil menghindari sakit kepala untuk pengembangan lokal. Berikut ini contoh tata letak solusi Visual Studio:

| Libraries
  | LibraryA
  | LibraryB
  | LibraryC
| Applications
  | ApplicationD
  | ApplicationE

Ini adalah solusi tunggal yang berisi pustaka kelas bersama dan beberapa aplikasi. Saat ini referensi ke perpustakaan kelas oleh aplikasi adalah referensi lokal dalam solusi.

Apa yang saya ingin lakukan adalah mempublikasikan pustaka (A, B, C) sebagai paket NuGet berversi yang kemudian direferensikan oleh aplikasi sesuai kebutuhan (D, E). Ini memungkinkan perubahan ke pustaka bersama menjadi independen dari pembaruan ke aplikasi yang diterapkan. Tanpa ini, mengubah satu pustaka dapat menyebabkan binari berubah dalam selusin atau lebih aplikasi, yang semuanya secara teknis perlu diuji. Ini tidak diinginkan, dan versi dengan NuGet memperbaiki ini.

Namun, mari kita katakan bahwa saya ingin memperbarui konten LibraryA dan ApplicationD pada saat yang bersamaan. Untuk melakukan hal ini setelah kami beralih ke NuGet, saya harus membuat perubahan pada LibraryA, lakukan, tunggu paket yang akan dibuat, beri tahu ApplicationD untuk memperbarui rujukannya ke LibraryA, dan kemudian uji atau kembangkan di ApplicationD. Ini jauh lebih rumit daripada hanya bekerja dengan keduanya pada saat yang sama menggunakan referensi lokal dalam solusi.

Apa cara yang lebih baik untuk mendapatkan ketahanan paket NuGet versi untuk pustaka kelas bersama saya sambil menjaga pengembangan sederhana bahkan jika itu mencakup beberapa proyek dan aplikasi? Satu-satunya solusi lain yang saya temukan melibatkan terlalu banyak biaya overhead atau sakit kepala, seperti harus selalu mengubah referensi untuk ApplicationD antara paket NuGet dan proyek lokal.

EDIT: Untuk memperjelas premis, pertanyaan ini mengasumsikan sebagai berikut:

  • Arsitektur (solusi dan organisasi proyek) tidak dapat ditata ulang secara signifikan
  • Pustaka bersama akan berubah pada frekuensi yang tidak sepele
  • Mengubah pustaka bersama tidak dapat memaksa aplikasi apa pun untuk diperbarui
  • Aplikasi dapat merujuk ke berbagai versi pustaka bersama

32
2017-12-30 19:30


asal


Jawaban:


Sayangnya, sebenarnya tidak ada cara untuk mendapatkan yang terbaik dari kedua dunia. Secara internal di perusahaan saya, kami telah sedikit memitigasi dengan proses build / deploy yang cepat, yang melawan sebagian besar beban dengan selalu mereferensikan paket NuGet. Pada dasarnya, semua aplikasi kami menggunakan versi berbeda dari pustaka yang sama yang dihosting di repositori NuGet lokal. Karena kami menggunakan perangkat lunak kami sendiri untuk membangun, menyebarkan, dan meng-host paket, itu membuatnya cukup cepat untuk memperbarui pustaka, kemudian memperbarui paket NuGet-nya dalam solusi lain. Pada dasarnya, alur kerja tercepat yang kami temukan adalah ini:

  1. Buat perubahan ke pustaka
  2. Secara otomatis membuat dan menyebarkan versi pustaka ditambah 1 untuk umpan NuGet internal
  3. Perbarui paket NuGet di aplikasi konsumen

Seluruh proses mulai dari check-in hingga update memakan proyek memakan waktu sekitar 3 menit. Repositori NuGet juga memiliki server simbol / sumber yang sangat membantu dalam debugging.


3
2017-12-30 21:23



Meskipun dibutuhkan beberapa pekerjaan, dimungkinkan untuk mengedit .csproj file tangan untuk mengatur referensi bersyarat dengan menambahkan Condition atribut ke referensi yang sesuai.

EDIT Saya telah memindahkan ketentuan ini ke ItemGroups, karena tampaknya ini adalah bagaimana kode produksi yang saya sebutkan berfungsi, dan telah disebutkan bahwa ini adalah masalah yang mungkin terjadi di VS 2013.

<ItemGroup Condition="'$(Configuration)' == 'Debug Local'">
    <!-- Library A reference as generated by VS for an in-solution reference, children unmodified -->
    <ProjectReference>...
</ItemGroup>

<ItemGroup Condition="'$(Configuration)' == 'Debug NuGet'">
    <!-- Library A reference as generated by NuGet, child nodes unmodified --> 
    <Reference Include="LibraryA">...
</ItemGroup>

Ini akan memungkinkan Anda untuk memiliki, pada Proyek D & E, konfigurasi "Debug NuGet" vs. "Debug Local" yang merujuk pustaka secara berbeda. Jika kemudian Anda memiliki beberapa file solusi yang konfigurasinya dipetakan ke konfigurasi yang sesuai pada proyek dalam, pengguna akhir tidak akan pernah melihat lebih dari "Debug" dan "Rilis" untuk sebagian besar operasi, karena itu adalah konfigurasi solusi, dan hanya akan perlu membuka solusi lengkap untuk mengedit proyek A, B, & C.

Sekarang, seperti untuk mendapatkan proyek A, B, & C keluar dari jalan, Anda dapat mengaturnya di bawah folder ditandai sebagai subrepo (dengan asumsi Anda menggunakan SCM yang mendukung ini, seperti Git). Sebagian besar pengguna tidak perlu menarik subrepo karena mereka tidak mengakses proyek ABC, dan malah mengambil dari NuGet.

Pemeliharaan bijaksana, saya dapat menjamin bahwa VS tidak akan mengedit referensi bersyarat, dan akan menghormati mereka selama kompilasi - Saya telah melalui kedua VS 2010 dan 2013 (EDIT: Versi profesional, meskipun saya telah berusaha melakukan hal yang sama dengan express) dengan proyek referensi bersyarat yang sama di tempat kerja. Perlu diingat daripada di VS, referensi dapat dibuat versi-agnostik, membuat NuGet satu-satunya tempat dari mana versi perlu dipertahankan, dan itu dapat dilakukan seperti paket NuGet lainnya. Sementara saya berharap, saya TIDAK menguji apakah NuGet akan bertarung dengan referensi bersyarat.

EDIT Mungkin juga bijaksana untuk dicatat bahwa referensi bersyarat dapat menyebabkan peringatan tentang hilangnya DLL, tetapi tidak benar-benar menghalangi kompilasi atau dijalankan.


16
2017-12-30 19:42



Saya tahu ini adalah posting 2 tahun, tetapi hanya menemukannya ketika menghadapi situasi yang sama. Juga menemukan ini untuk VS2015, saya sedang dalam proses mengujinya. Saya akan kembali dan menyesuaikan jawaban saya.

https://marketplace.visualstudio.com/items?itemName=RicoSuter.NuGetReferenceSwitcherforVisualStudio2015


6
2018-05-09 14:25