Tek bir Visual Studio çözümünde birden fazla uygulama [kapalı]


17

Tüm .Net uygulamalarını (web uygulamaları, Windows uygulamaları ve konsol uygulamaları) tek bir Visual Studio çözümünde bir araya getirmek isteyen bir şirket için çalışıyorum.

Kendi uygulamalarını bu şekilde yapılandıran ya da bunu yapan bir şirkette çalışan geliştiricilerden deneyim arıyorum. Bu iyi bir fikir mi?

  • Profesyonellerin / aleyhtarlarının her bir uygulama için ayrı çözümlere sahip olmak yerine tüm uygulamalarınızı tek bir çözüm haline getirmesi nedir?

  • 20'den fazla projenin çözümü ile Visual Studio ne kadar hızlı?

  • Kaynak kontrollü eşzamanlı geliştirmeye sahip çözüm dosyası ne kadar kararlıdır?


Yanıtların Visual Studio'nun belirli sürümlerine özgü olabileceğini unutmayın.
stakx

Yanıtlar:


21

Son zamanlarda, şirketimdeki neredeyse tüm kaynak kodlarını tek bir çözüme taşıdık.

Neden?

Başlangıçta onlarca çözümümüz vardı. Bir çözümün bazı projeleri başka bir projeyi yeniden kullandı ve kimse bir paket yöneticisi kullanma konusunda umursamadı. Neredeyse her yerde kullanılan bir projeyi önemli ölçüde değiştirdiğiniz gün, önümüzdeki günler veya haftalar boyunca tüm şirket için saatler ve saatler süren iş kaybı bekler. En kötü yanı, değişiklikten tam olarak neyin etkileneceğini bile bilemezsiniz .

Tüm kodu tek bir çözümde birleştirmek bir alternatifti. Şu an için iyi çalışıyor ve bağımlılıkları takip etmek artık çok kolay. Bir yöntemi değiştirmek ama aynı zamanda bu değişikliğin kod tabanının herhangi bir yerinde olabileceği yansımaları izlemek mi istiyorsunuz? Visual Studio bunu kolaylıkla yapabilir. Benim için bu bir başarı.

Sürekli entegrasyon da artık daha kolay. Derlemek ve dağıtmak için tek bir çözüm. Neredeyse yapılandırılacak bir şey yok.

Ölçeklenebilir mi?

Performans açısından Visual Studio beni çok şaşırttı . 50 proje ile bir çözümle ağlamaya başlayacağını düşündüm. Bugün 200'den fazla proje var; Visual Studio, bunları sadece 20 tane varmış gibi yönetecek kadar ölçeklenebilir görünüyordu. Evet, zaman alan şeyler var. Her projeyi yeniden kodlarsanız, Kod sözleşmeleri, Varsayılan olarak etkinleştirilmiş Kod analizi vb. İle, biraz zaman almasını bekleyin. Ancak hiç kimse 200 projeyi 10 kadar hızlı derlemeyi bekleyemez ve bu arada yapmamalısınız: Bu, Sürekli entegrasyon sunucusunun rolüdür. Başlangıç ​​zamanı (soğuk başlatma, ardından çözeltiyi yükleme) etkileyici bir şekilde hızlıdır ; belki 10 projede olduğu kadar hızlı değil, ama yine de çok kabul edilebilir (beş yıldan fazla bir süre önce satın alınan bir makinede 20 saniyenin altında).

Daha da ileriye gitmek için, sistematik olarak boşaltma projeleri iyi bir fikirdir (ve projeler çözüm içindeki dizinlerde düzenlendiğinde gerçekten kolaydır). Birisi sadece üç projenin yüklenmesini gerektiren bir şey üzerinde çalışırsa, 200 projenin tümünü yüklemeye gerek yoktur (tabii ki bağımlılıklar etkilenmeyebilirse).

Sürüm kontrolü de beklendiği gibi çalışıyor (önemliyse bir SVN sunucusu kullanıyorum). Örneğin, sık sık kod işleyen düzinelerce geliştirici ile gerçek bir eşzamanlı ortamda çalışmadım, ancak bunun çok fazla sorunu olmayacağını hayal ediyorum. Birçok geliştiricinin aynı anda yeni projeler eklediği durumlara dikkat edin: .sln dosyasını birleştirmek en kolay şey değildir.

Sonuç

Kararı tekrar seçmem gerekirse:

  1. Yine de her şeyi tek bir çözüme taşıyacağım. Bu, kırık bağımlılıkların acısını büyük ölçüde azaltır ve bu fayda tek başına buna değer. Tüm kodlar için merkezi bir yere sahip olmak da iyi bir fikirdir; bu, örneğin, Visual Studio'da bir şey aramayı mümkün kılar. Zayıf şekilde ilişkili iki projede de çalışabilirim ve yine de yalnızca bir Visual Studio penceresi açtım.

  2. Ayrıca biraz daha NuGet ve özel bir NuGet sunucusu barındırma yeteneği üzerinde çalışacaktım. NuGet aracılığıyla bağımlılıkları yönetmek, birkaç projeyi ortak çözümle birleştirmek istemediğinizde bazı sorunları çözebilir. Şahsen, böyle davalarım yoktu, ama diğer şirketlerin de olabileceğini hayal ediyorum.

  3. Son olarak, her geliştirici için bir SSD'ye yatırım yapmak büyük bir fark yaratabilir. Ama gerek yok ve benim durumumda, kod tabanı hala sıradan bir sabit diskte saklanıyor.


2
Sadece bazı noktalar FYI: Hız / performans sorunu varsa projeleri VS'deki .csproj dosyası üzerinden de açabilirsiniz. Bir NuGet "özel sunucusu" sadece bir ağ klasörüdür (ve bu klasörü VS'de paket kaynak konumu olarak ekler) - nupkg dosyalarını oraya bırakın ve çalışır.
Steven Evers

Deneyimlerinizi tek bir çözüm kurulumuyla paylaştığınız için teşekkürler MainMa; çok ayrıntılı ve yararlı bir cevap. Sahip olduğum bir rezervasyon, tüm uygulamaları tek bir çözümde bir araya getirmektir, bir geliştiriciye her şeye erişim vermek zorunda. Ankhsvn kullanıyoruz ve küçük bir geliştiriciye çalışmasını istediğim tek bir uygulamanın URL'sini her şeye erişmekten ziyade vermeyi tercih ederim. Bunun hakkında bir fikrin var mı?
BruceHill

@BruceHill: SVN ile kimin neye erişebileceğini tam olarak yapılandırabilirsiniz. Yeni geliştirici yine de her kök dizini görebilecek ( Sunucu Hatası ile ilgili soruma bakın ), ancak kısıtlı projelere erişemeyecek.
Arseni Mourzenko

2
Her gün kod yapan büyük geliştirici ekipleri ile birkaç büyük şirkette çalışarak size tek çözüm yaklaşımının işe yaramadığını söyleyebilirim. Her proje genel gider. Yükleme, inşaat ve tanrı, birinin söz konusu projelere hangi inşaat öncesi / sonrası yapım adımlarını ekleyebileceğini bilir. Şimdi büyük bir geliştirici ekibiyle, her gün bu projelerin çoğunda değişiklikler olacak. Sürekli entegrasyon için her check-in'e koşu birimi testleri vb. Ekleyin ve daha da fazla ek yüke sahip olun. Konuşlandırılabilir birim (hizmet, web sitesi) başına tek bir çözüm bulun ve NuGet gibi bir paket yöneticisi kullanın.
Her Zaman

8

Amaçlanan kullanım budur.

Profesyonellerin / aleyhtarlarının her bir uygulama için ayrı çözümlere sahip olmak yerine tüm uygulamalarınızı tek bir çözüm haline getirmesi nedir?

  • Artıları:
    • projeler arasında daha kolay referanslar
    • daha kolay hata ayıklama / adım atma
    • süreçlere eklenmesi daha kolay (yani, paylaşılan kitaplık koduna atladığında bir Windows hizmetinden geçiyorsunuz ve sadece tüm semboller zaten yüklü ve hesaplanmış olduğu için çalışıyor)
    • IDE içinde kod araması daha iyi çalışır (aradığınız kodun hangi projede yer aldığını bilmeniz gerekmez)
    • projeler arası changelistlerin yönetimi daha kolaydır (örn. kütüphane kodunu değiştirdiniz, bu nedenle istemci kodunu aynı anda, 1 check-in ile güncellemelisiniz)
  • Eksileri:
    • inşa hızı: Eğer "yeniden inşa" alışkanlığı iseniz o zaman daha uzun sürer. Çok daha uzun ve artımlı yapılar bazen korkak davranışlara sahiptir.
    • ide hızı: sonrakine bak

20'den fazla projenin çözümü ile Visual Studio ne kadar hızlı?

20'den fazla projeyle ... o kadar da kötü olmayabilir. VS problemleri olmadan daha fazlasını gördüm. Oldukça kararlı / hızlı. ANCAK ... bir sorun varsa, hafifletilebilir: .csproj'u VS'de açın ve oradan çalışın. Tek bir çözümde her şeye sahip olmanın avantajlarını elde edemezsiniz, ancak sln'yi her zaman yeniden açıp ihtiyaç duyduğunuzda yalnızca .csproj'da çalışabilirsiniz (şimdi yaptığınız gibi).

Kaynak kontrollü eşzamanlı geliştirmeye sahip çözüm dosyası ne kadar kararlıdır?

Çözüm dosyası yalnızca proje veya çözüm düzeyi nesneleri eklediğinizde / kaldırdığınızda değişir, bu nedenle nadiren değişir. Bu xml, içinde ne olduğunu görebilirsiniz. Nadiren değişir.


Steve, "Bu amaçlanan kullanımdır" dedin . Bunun için bir referans verebilir misiniz? Teşekkürler!
yeniden düzenlendi
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.