Mengelola paket NuGet internal dengan akses kode sumber

Kami memiliki banyak perpustakaan internal yang ingin kami bagikan antar proyek di dalam perusahaan. Ini adalah beberapa persyaratan:

sumber perpustakaan disimpan dalam repositori yang terpisah dari proyek akhir
proyek akhir termasuk perpustakaan melalui NuGet
harus mungkin untuk dengan mudah memeriksa kode sumber untuk perpustakaan yang diberikan saat mengerjakan proyek akhir

Menyiapkan repositori NuGet pribadi kami bukan masalah, tetapi mengelola sumber adalah. Kami mencoba untuk mengekspos sumber melalui server sumber dan agak bekerja, tetapi tidak cukup: VS mendownload sumber saat debugging kode eksternal, tetapi tidak ketika Anda mencoba untuk menavigasi ke definisi / implementasi. Pada dasarnya, Anda hanya dapat pergi ke kode sumber saat debugging, yang tidak cukup yang kita butuhkan.

Jadi, pertanyaannya adalah:

cara apa yang ada untuk menyediakan akses ke kode sumber perpustakaan internal tanpa perlu memiliki kode dalam repo / solusi yang sama
apakah ada cara untuk mengatur combo server Symbol / NuGet feed sehingga VS menggunakan simbol untuk navigasi, bukan hanya untuk debugging?

Menggunakan ReSharper / add-in lainnya adalah sebuah opsi.

c# source-code closed-source nuget

— Dyppl
sumber

Kami menemukan penggunaan Nuget untuk mengelola proyek internal yang kurang optimal; kami akhirnya merobeknya demi proyek dan referensi DLL. Saya ingin sekali mendengar dari seseorang yang dapat membuat pekerjaan ini.

— Robert Harvey

Apakah Anda juga mengatur server simbol untuk file pdb yang sesuai dengan dll yang terkandung dalam paket NuGet Anda?

— RubberDuck

Kami memiliki pengaturan yang sama persis di tempat kerja saya saat ini. Server NuGet (berisi DLL tanpa PDB) plus server simbol (berisi DLL, PDB, dan sumber). Kami juga memiliki masalah yang sama (sumber dan PDB hanya diambil saat debugging). @RobertHarvey: Manajer Paket NuGet adalah klien NuGet yang buruk. Itu tidak membedakan antara ketergantungan langsung dan sementara dan membutuhkan tindakan "konsolidasi" konyol. Kami beralih ke Paket dan tidak pernah melihat ke belakang sejak itu. Itu membuat manajemen paket waras dan tertahankan, berbatasan dengan menyenangkan.

— Allon Guralnek

Saya harus bertanya - meskipun saya pikir ini bukan persyaratan yang tidak masuk akal - mengapa Anda harus dapat melihat paket bersama / umum? Setidaknya secara alami ini harus didokumentasikan kotak hitam dan kebutuhan untuk melihat ke dalam harus pengecualian daripada norma. Bagaimanapun, mereka tersedia di repo sumber Anda dan karenanya sepele untuk mengunduh solusi untuk diperiksa. Saya dapat melihat sejumlah alasan mengapa ini atau bagian dari ini mungkin tidak sepenuhnya terjadi, tetapi masih layak ditanyakan.

— Murph

@ Murph - Saya bukan OP, tetapi dalam dokumentasi pengalaman saya tidak pernah menangkap detail yang saya inginkan. Apakah saya perlu membersihkan negara ini atau akankah callee? Apa sebenarnya pelarian ini? Bagaimana perbedaan kelebihan ini? Apakah entitas ini mendukung kesetaraan, dan jika demikian, berdasarkan apa? Berapa perkiraan kompleksitas panggilan ini? Satu-satunya rinci senilai dokumentasi memiliki adalah (bersih) sumber, karena selalu ada dan biasanya akan menjadi hal dokumenter tidak pernah dianggap tapi itu yang penting bagi Anda. Lebih buruk lagi, dokumentasi yang rumit pasti mengandung kesalahan dan menjadi basi.

— Eamon Nerbonne

Jawaban:

Apa yang harus bekerja adalah hanya memeriksa kode sumber untuk paket NuGet dan membuka solusi dalam contoh terpisah dari Visual Studio.

Visual Studio memiliki trik yang rapi untuk beralih antar kode dalam keadaan terbuka dengan mengerjakan apa yang telah Anda rujuk. Pertama kali ini terjadi pada saya ketika saya sedang debug, adalah sebuah wahyu.

Masalah utama yang Anda hadapi adalah memastikan kode yang diperiksa untuk paket dependen mewakili versi yang sama dengan referensi NuGet Anda di proyek utama. Bukan masalah jika Anda mengikuti kebijakan selalu membangun terhadap versi terbaru dari paket Anda.

Manfaat lain dari pendekatan ini adalah bahwa jika paket perlu diubah, Anda dapat melakukan perubahan di sana dan kemudian.

— Stewart Ritchie
sumber

Bisakah Anda memberikan beberapa detail tambahan tentang bagaimana seseorang membuat ini berfungsi? Itu tidak bekerja seperti yang Anda jelaskan untuk saya. Apakah Anda perlu memasukkan PDB dalam paket? Adakah trik tambahan?

— Dyppl

-1

Mungkin Anda dapat menggunakan https://github.com/GitTools/GitLink . Itu menambahkan tautan dalam file pdb yang menunjuk ke repositori sehingga Visual Studio akan mengambil kode sumber dari sana - dan kemudian Anda hanya perlu memasukkan file pdb dalam paket nuspec Anda dan tidak memerlukan server sumber.

— Jesper Balle
sumber

Apakah itu bekerja di luar proses debug? Sepertinya tidak.

— Dyppl

-1

Jadi ini bukan solusi yang sempurna, tetapi Anda menyebutkan bahwa Anda bisa menggunakan Resharper; dengan dotPeek dan resharper Anda dapat menavigasi ke pembongkaran kode asli, itu yang saya gunakan di tempat kerja, di mana kami memiliki pengaturan yang sama dengan Anda.

Saya menemukan kombinasi Symbol Server yang Anda sebutkan dan meramban pembongkaran biasanya cukup untuk mencari tahu apa yang terjadi.

Semoga itu bisa membantu.

Sunting: Setelah membaca kembali pertanyaan Anda, saya sadar Anda secara khusus meminta untuk dapat menelusuri kode sumber, yang ini bukan. Meski begitu semoga bermanfaat bagi seseorang.

— BaronVonDrew
sumber