Beberapa aplikasi dalam satu solusi Visual Studio [ditutup]


17

Saya melakukan pekerjaan untuk perusahaan yang ingin menempatkan semua. Net aplikasi mereka (aplikasi web, aplikasi Windows dan aplikasi konsol) bersama dalam satu solusi Visual Studio.

Saya mencari pengalaman dari pengembang yang menyusun aplikasi mereka sendiri dengan cara ini atau yang bekerja di perusahaan yang melakukan ini. Apakah ini ide yang bagus?

  • Apa pro / kontra untuk menempatkan semua aplikasi Anda dalam satu solusi daripada memiliki solusi terpisah untuk setiap aplikasi?

  • Seberapa cepat Visual Studio dengan solusi 20+ proyek?

  • Dan seberapa stabil file solusi dengan pengembangan bersamaan sumber-terkontrol?


Ingatlah bahwa jawaban mungkin khusus untuk versi Visual Studio tertentu.
stakx

Jawaban:


21

Baru-baru ini, kami memigrasikan hampir semua kode sumber di perusahaan saya menjadi satu solusi.

Mengapa?

Awalnya, kami memiliki banyak solusi. Beberapa proyek dari suatu solusi menggunakan kembali proyek-proyek dari yang lain, dan tidak ada yang peduli menggunakan manajer paket. Hari Anda secara substansial mengubah proyek yang digunakan hampir di mana-mana, mengharapkan jam kerja yang hilang untuk seluruh perusahaan selama beberapa hari atau minggu ke depan. Bagian terburuknya adalah Anda bahkan tidak tahu persis apa yang akan dipengaruhi oleh perubahan itu.

Menggabungkan semua kode menjadi satu solusi adalah alternatif. Ini berfungsi dengan baik untuk saat ini, dan dependensi sekarang mudah diikuti. Ingin memodifikasi metode tetapi juga melacak dampak perubahan ini di basis kode? Visual Studio dapat melakukannya dengan mudah. Bagi saya, ini sukses.

Integrasi berkelanjutan sekarang juga lebih mudah. Satu solusi untuk mengkompilasi dan menggunakan. Hampir tidak ada yang dikonfigurasi.

Apakah ini scalable?

Dari segi kinerja, saya sangat terkejut oleh Visual Studio . Saya pikir itu akan mulai menangis dengan solusi, katakanlah, 50 proyek. Saat ini, ada lebih dari 200 proyek; Visual Studio tampaknya cukup terukur untuk mengelolanya seolah-olah hanya ada 20 di antaranya. Ya, ada beberapa hal yang membutuhkan waktu. Jika Anda mengkompilasi ulang setiap proyek, dengan kontrak Kode, analisis Kode diaktifkan secara default, dll., Perkirakan itu akan memakan waktu. Tapi tidak ada yang akan mengharapkan untuk mengkompilasi 200 proyek secepat 10, dan omong-omong, Anda tidak boleh: ini adalah peran server integrasi berkelanjutan. Waktu mulai (mulai dingin, kemudian memuat solusinya) sangat cepat ; mungkin tidak secepat 10 proyek, tetapi masih sangat dapat diterima (di bawah 20 detik pada mesin yang dibeli lebih dari lima tahun yang lalu).

Untuk melangkah lebih jauh, membongkar proyek secara sistematis adalah ide yang bagus (dan sangat mudah ketika proyek disusun dalam direktori di dalam solusi). Jika seseorang mengerjakan sesuatu yang hanya memerlukan tiga proyek untuk dimuat, tidak perlu memuat semua 200 proyek (kecuali, tentu saja, ketergantungan mungkin terpengaruh).

Kontrol versi berfungsi seperti yang diharapkan juga (Saya menggunakan server SVN, jika itu penting). Saya belum bekerja di lingkungan konkuren yang nyata, dengan, katakanlah, puluhan pengembang sering melakukan kode, tetapi saya akan membayangkan bahwa ini tidak akan memiliki terlalu banyak masalah. Berhati-hatilah dengan kasus-kasus di mana banyak pengembang menambahkan proyek baru pada saat yang sama: menggabungkan file .sln bukan hal termudah untuk dilakukan.

Kesimpulan

Jika saya harus mengambil keputusan lagi:

  1. Saya masih akan memigrasi semuanya menjadi satu solusi. Ini sangat mengurangi rasa sakit dari ketergantungan yang rusak, dan manfaat ini saja sangat berharga. Memiliki tempat yang terpusat untuk semua kode juga merupakan ide bagus; ini memungkinkan, misalnya, untuk mencari sesuatu di dalam Visual Studio. Saya juga dapat bekerja pada dua proyek yang terkait lemah, dan masih memiliki hanya satu jendela Visual Studio yang dibuka.

  2. Saya juga akan mempelajari sedikit lebih banyak NuGet dan kemampuan untuk meng-host server NuGet pribadi. Mengelola dependensi melalui NuGet dapat menyelesaikan beberapa masalah ketika Anda tidak ingin menggabungkan beberapa proyek menjadi solusi bersama. Secara pribadi, saya tidak memiliki kasus seperti itu, tetapi saya membayangkan bahwa perusahaan lain mungkin memilikinya.

  3. Akhirnya, berinvestasi dalam SSD untuk setiap pengembang dapat membuat perbedaan besar. Tetapi Anda tidak perlu, dan dalam kasus saya, basis kode masih disimpan pada hard drive biasa.


2
Hanya beberapa poin FYI: Anda juga dapat membuka proyek melalui file .csproj di VS jika kecepatan / kinerja adalah masalah. "Server pribadi" NuGet hanyalah folder jaringan (dan tambahkan folder itu sebagai lokasi sumber paket di VS) - cukup letakkan file nupkg di sana dan berfungsi.
Steven Evers

Terima kasih, MainMa untuk berbagi pengalaman Anda dengan pengaturan solusi tunggal; jawaban yang sangat terperinci dan bermanfaat. Reservasi yang saya miliki adalah dengan memiliki semua aplikasi bersama dalam satu solusi adalah harus memberikan akses pengembang junior untuk semuanya. Kami menggunakan Ankhsvn dan saya lebih suka memberi pengembang junior URL untuk satu aplikasi yang saya ingin mereka kerjakan daripada memberi mereka akses ke semuanya. Ada pemikiran tentang ini?
BruceHill

@BruceHill: dengan SVN, Anda dapat mengkonfigurasi dengan tepat siapa yang memiliki akses ke apa. Pengembang junior masih akan dapat melihat setiap direktori root (lihat pertanyaan saya tentang Kesalahan Server ), tetapi tidak akan dapat mengakses proyek yang dibatasi.
Arseni Mourzenko

2
Bekerja untuk beberapa perusahaan besar dengan tim besar pengembang melakukan kode setiap hari saya dapat memberitahu Anda bahwa pendekatan solusi tunggal tidak berfungsi. Setiap proyek adalah overhead. Memuat, membangun dan Tuhan tahu apa langkah pra / pasca membangun seseorang mungkin telah melekat pada proyek tersebut. Sekarang dengan tim pengembang besar, Anda akan memiliki perubahan di banyak proyek tersebut setiap hari. Termasuk uji unit yang sedang berjalan, dll dengan setiap check-in untuk integrasi berkelanjutan dan kemudian Anda memiliki overhead yang lebih banyak. Miliki satu solusi untuk setiap unit yang dapat digunakan (layanan, situs web) dan gunakan manajer paket seperti NuGet.
Selalu Belajar

8

Ini adalah penggunaan yang dimaksudkan.

Apa pro / kontra untuk menempatkan semua aplikasi Anda dalam satu solusi daripada memiliki solusi terpisah untuk setiap aplikasi?

  • pro:
    • referensi easer antar proyek
    • lebih mudah debugging / melangkah
    • lebih mudah untuk dilampirkan ke proses (mis. Anda sedang melangkah melalui layanan windows, ketika itu melompat ke kode perpustakaan bersama, dan itu hanya berfungsi karena semua simbol sudah dimuat dan diperhitungkan)
    • pencarian kode dalam ide berfungsi lebih baik (Anda tidak perlu tahu proyek mana kode yang Anda cari berada)
    • daftar perubahan lintas proyek lebih mudah dikelola (mis. Anda mengubah kode pustaka, jadi Anda harus memperbarui kode klien secara bersamaan, dengan 1 checkin)
  • kontra:
    • kecepatan build: jika Anda terbiasa "membangun kembali semua" maka build membutuhkan waktu lebih lama. Lebih lama, dan bangunan tambahan terkadang memiliki perilaku yang funky.
    • kecepatan ide: lihat selanjutnya

Seberapa cepat Visual Studio dengan solusi 20+ proyek?

Dengan 20+ proyek ... mungkin tidak terlalu buruk. Saya telah melihat lebih banyak tanpa VS mengalami masalah. Cukup stabil / cepat. NAMUN ... jika itu adalah masalah, itu dapat dikurangi: buka .csproj di VS dan bekerja dari sana. Anda tidak mendapatkan manfaat dari memiliki semuanya dalam satu solusi, tetapi Anda selalu dapat membuka kembali sln ketika Anda perlu dan hanya bekerja di .csproj ketika Anda perlu (seperti yang Anda lakukan sekarang).

Dan seberapa stabil file solusi dengan pengembangan bersamaan sumber-terkontrol?

File solusi hanya berubah ketika Anda menambah / menghapus proyek atau objek tingkat solusi, sehingga jarang berubah. Itu xml, jadi Anda bisa melihat apa yang ada di dalamnya. Mereka jarang berubah.


Steve, Anda berkata, "Ini penggunaan yang dimaksudkan." Bisakah Anda memberikan referensi untuk ini? Terima kasih!
direformasi
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.