Pertanyaan Praktik terbaik dengan Nuget: Debug atau Rilis?


Saat ini, saya mengemas rilis rilis dengan Nuget untuk build resmi ke nuget.org, tetapi saya mengemas build debug dengan Nuget untuk sumber simbol yang mendorong ke symbolource.org.

EDIT: (Jon Skeet, dengan beberapa bias dari pengembangan Noda Time)

NuGet sekarang mendukung mendorong ke galeri NuGet dan symbolsource.org (atau server serupa), sebagaimana didokumentasikan. Sayangnya, ada dua persyaratan kontradiktif di sini:

  • Kapan saja menggunakan perpustakaan tanpa perlu melakukan debug, Anda benar-benar ingin membangun versi rilis. Itu adalah rilis rilis untuk apa.
  • Ketika debugging ke perpustakaan untuk tujuan diagnostik, Anda benar-benar ingin membangun debug dengan semua optimasi yang sesuai dinonaktifkan. Itulah yang membangun debug untuk, setelah semua.

Itu baik-baik saja, tetapi NuGet tidak (sejauh yang saya tahu) memungkinkan rilis rilis dan debug untuk dipublikasikan dengan cara yang bermanfaat, dalam paket yang sama.

Jadi, pilihannya adalah:

  • Distribusikan build debug ke semua orang (seperti yang ditunjukkan pada contoh di dokumen) dan hidupkan dengan ukuran dan performa apa pun.
  • Distribusikan rilis dibangun untuk semua orang dan hidup dengan pengalaman debug yang sedikit terganggu.
  • Pergi untuk kebijakan distribusi yang sangat rumit, berpotensi menyediakan paket rilis dan debug terpisah.

Dua yang pertama benar-benar mendidih ke efek dari perbedaan antara debug dan rilis membangun ... meskipun perlu dicatat bahwa ada juga perbedaan besar antara ingin masuk ke kode perpustakaan karena Anda ingin memeriksa beberapa perilaku, dan ingin untuk mendebug kode pustaka karena Anda yakin telah menemukan bug. Dalam kasus kedua, mungkin lebih baik untuk mendapatkan kode pustaka sebagai solusi Visual Studio dan debug seperti itu, jadi saya tidak terlalu memperhatikan situasi itu.

Godaan saya adalah terus dengan rilis rilis, dengan harapan itu relatif beberapa orang perlu melakukan debug, dan orang-orang yang melakukannya tidak akan terpengaruh banyak oleh pengoptimalan di versi rilis. (Kompiler JIT melakukan sebagian besar pengoptimalan.)

Jadi, apakah ada opsi lain yang tidak kami pertimbangkan? Apakah ada pertimbangan lain yang memberikan keseimbangan? Apakah mendorong paket NuGet ke SymbolSource dengan cukup baru bahwa "praktik terbaik" sebenarnya belum ditetapkan?


75
2017-11-21 07:26


asal


Jawaban:


Berbicara untuk SymbolSource, saya percaya bahwa praktik terbaik adalah:

  1. Dorong lepaskan paket biner + konten ke nuget.org saja (atau umpan produksi lainnya)
  2. Push debug binary + content packages ke feed pengembangan:
    • on-premise
    • di myget.org
    • di nuget.org sebagai paket pra-rilis.
  3. Dorong paket rilis dan debug biner + simbol ke simbolource.org atau toko simbol lainnya.

Sementara kita melakukannya, itu adalah kesalahpahaman umum yang rilis dan debug membangun di. NET benar-benar berbeda banyak, tapi saya mengasumsikan bahwa diferensiasi ada di sini karena berbagai kode yang mungkin atau mungkin tidak termasuk dalam membangun baik, seperti Debug .Asserts.

Yang mengatakan, itu benar-benar layak mendorong kedua konfigurasi ke SymbolSource, karena Anda tidak pernah tahu kapan Anda akan perlu debug kode produksi. Remotely dalam produksi untuk membuatnya lebih sulit. Anda akan membutuhkan bantuan yang dapat Anda peroleh dari peralatan Anda saat itu terjadi. Yang saya jelas tidak inginkan pada siapa pun.

Masih ada masalah yang perlu dipertimbangkan terkait pembuatan versi: apakah benar memiliki 2 paket berbeda (dibuat di debug dan di rilis) berbagi 1 nomor versi? SymbolSource akan menerima itu, karena ia mengekstraksi paket dan menyimpan binari di cabang-cabang mode build yang terpisah, JIKA HANYA NuGet diizinkan untuk menandai paket yang sesuai. Tidak ada cara saat ini untuk menentukan apakah paket itu debug atau mode rilis.


27
2018-02-01 07:31



Saya sepenuhnya setuju dengan kesimpulan Anda. Paket NuGet dengan RELEASE dan SymbolSource dengan debug. Tampaknya sangat jarang untuk langsung masuk ke paket dan kesalahan salah langkah sesekali dengan pengoptimalan yang diaktifkan mungkin dapat diterima.

Jika benar-benar ada masalah, saya pikir solusi yang ideal adalah meminta NuGet untuk mendukungnya. Sebagai contoh, bayangkan jika ketika debugging, itu bisa menggantikan rilis DLL dengan yang disertakan dalam paket SymbolSource.

Idealnya, apa yang akan terjadi kemudian adalah itu nuget pack SomePackage -Symbols terhadap versi rilis akan membuat paket nuget rilis, tetapi paket simbol debug. Dan plugin VS akan diperbarui untuk menjadi cukup pintar untuk melihat asosiasi dan menarik dalam rakitan Debug ketika menjalankan debugger dan memuat mereka sebagai gantinya. Agak gila, tapi akan menarik.

Namun, saya hanya tidak melihat cukup banyak orang mengeluh tentang hal ini sehingga akan sangat berharga saat ini.

Tim NuGet menerima permintaan tarik. :)


4
2018-02-04 21:41



Contoh dalam Membuat dan Menerbitkan Paket Simbol referensi file dalam direktori Debug sebagai sumber untuk file dll dan pdb.

Menentukan Isi Paket Simbol

Paket simbol dapat dibuat berdasarkan konvensi, dari folder yang terstruktur dengan cara yang dijelaskan di bagian sebelumnya, atau kontennya dapat ditentukan menggunakan bagian file. Jika Anda ingin membuat paket contoh yang dijelaskan sebelumnya, Anda bisa memasukkan ini ke dalam file nuspec Anda:

<files>
  <file src="Full\bin\Debug\*.dll" target="lib\net40" /> 
  <file src="Full\bin\Debug\*.pdb" target="lib\net40" /> 
  <file src="Silverlight\bin\Debug\*.dll" target="lib\sl40" /> 
  <file src="Silverlight\bin\Debug\*.pdb" target="lib\sl40" /> 
  <file src="**\*.cs" target="src" />
</files>

Karena tujuan penerbitan simbol adalah untuk memungkinkan orang lain untuk melangkah melalui kode Anda ketika melakukan debug, tampaknya paling bijaksana untuk menerbitkan versi kode yang dimaksudkan untuk debugging tanpa optimisasi yang mungkin mempengaruhi langkah kode melalui.


0
2018-02-01 07:28