Visual Studio'da (2008) büyük çözümler için en iyi uygulamalar [kapalı]

Çoğu C # olmak üzere yaklaşık 100'den fazla projeyle bir çözümümüz var. Doğal olarak, hem açmak hem de inşa etmek uzun zaman alıyor, bu yüzden bu tür canavarlar için en iyi uygulamaları arıyorum. Cevap almayı umduğum sorular arasında şunlar yer alıyor:

• projeler arasındaki referansları en iyi nasıl ele alırsınız
  • "yerel kopyala" açık mı yoksa kapalı mı olmalı?

• her proje kendi klasöründe mi oluşturulmalı yoksa hepsi aynı çıktı klasörüne mi oluşturulmalıdır (hepsi aynı uygulamanın parçasıdır)

• Çözümlerin klasörleri işleri organize etmenin iyi bir yolu mu?

Çözümü birden fazla küçük çözüme bölmenin bir seçenek olduğunu biliyorum, ancak bu, kendi yeniden düzenleme ve oluşturma baş ağrılarıyla birlikte gelir, bu yüzden belki de bunu ayrı bir konu için kaydedebiliriz :-)

Yazdığım bu iki MSBuild makalesi ilginizi çekebilir.

MSBuild: Güvenilir Yapılar Oluşturmak İçin En İyi Uygulamalar, Bölüm 1

MSBuild: Güvenilir Yapılar Oluşturmak İçin En İyi Uygulamalar, Bölüm 2

Kısım 2'de özellikle bakmak isteyebileceğiniz büyük kaynak ağaçları inşa eden bir bölüm var .

Yine de sorularınızı kısaca yanıtlamak için:

• CopyLocal? Elbette bunu kapat
• Bir veya daha fazla çıktı klasörü oluşturmak mı istiyorsunuz? Tek bir çıktı klasörü oluşturun
• Çözüm klasörleri? Bu bir zevk meselesi.

İbrahim Haşimi

My Book: Microsoft Build Engine'in İçinde: MSBuild ve Team Foundation Build Kullanımı

Eşyaların düzenlenmesine yardımcı olmak için çözüm klasörlerinin tasarruflu kullanımı için +1 .

Kendi klasörüne proje oluşturmak için +1. Başlangıçta ortak bir çıktı klasörü denedik ve bu, güncel olmayan referansları bulmak için ince ve zahmetli olabilir.

FWIW, çözümler için proje referanslarını kullanıyoruz ve bugünlerde nuget muhtemelen daha iyi bir seçim olsa da svn: externals'in hem 3. taraf hem de (çerçeve türü) şirket içi montajlar için iyi çalıştığını gördük. Svn: externals'e atıfta bulunurken HEAD yerine belirli bir revizyon numarası kullanma alışkanlığı edinin (suçlu olduğu gibi suçlu :)

Sık kullanmadığınız projeleri kaldırın ve bir SSD satın alın. SSD, derleme süresini iyileştirmez, ancak Visual Studio'nun açma / kapama / derleme işlemleri iki kat daha hızlı hale gelir.

Çözmemiz gereken 109 ayrı projemiz olduğu için benzer bir sorunumuz var. Deneyimlerimize dayanarak orijinal soruları cevaplamak için:

1. Projeler arasındaki referansları en iyi nasıl ele alırsınız

'Referans ekle' bağlam menüsü seçeneğini kullanıyoruz. 'Proje' seçilirse, bağımlılık varsayılan olarak tek, global çözüm dosyamıza eklenir.

2. "Yerel kopyala" açık mı yoksa kapalı mı olmalı?

Deneyimlerimizde kapalı. Fazladan kopyalama sadece inşa sürelerine katkıda bulunur.

3. Her proje kendi klasöründe mi oluşturulmalı yoksa hepsi aynı çıktı klasörüne mi oluşturulmalı (hepsi aynı uygulamanın parçasıdır)

Çıktımızın tamamı 'bin' adlı tek bir klasöre yerleştirilir. Bu klasörün, yazılımın konuşlandırıldığı zamankiyle aynı olması fikri. Bu, geliştirici kurulumu dağıtım kurulumundan farklı olduğunda ortaya çıkan sorunları önlemeye yardımcı olur.

4. Çözüm klasörleri işleri organize etmenin iyi bir yolu mu?

Deneyimlerimize göre hayır. Bir kişinin klasör yapısı diğerinin kabusu. Derinlemesine iç içe geçmiş klasörler, herhangi bir şeyi bulmak için gereken süreyi artırır. Tamamen düz bir yapıya sahibiz ancak proje dosyalarımıza, derlemelerimize ve ad alanlarımıza aynı adı veriyoruz.

Projeleri yapılandırma şeklimiz tek bir çözüm dosyasına dayanmaktadır. Projelerin kendisi değişmemiş olsa bile, bunu inşa etmek uzun zaman alıyor. Buna yardımcı olmak için, genellikle başka bir 'geçerli çalışma kümesi' çözüm dosyası oluştururuz. Üzerinde çalıştığımız tüm projeler buna eklenir. Derleme süreleri büyük ölçüde iyileştirilmiştir, ancak gördüğümüz bir sorun Intellisense'in mevcut kümede olmayan projelerde tanımlanan türler için başarısız olmasıdır.

Çözüm düzenimizin kısmi bir örneği:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

Burada benzer büyük bir proje üzerinde çalışıyoruz. Çözüm klasörleri, işleri organize etmenin iyi bir yolu olduğunu kanıtladı ve biz sadece yerel kopyayı true olarak bırakma eğilimindeyiz. Her proje kendi klasörüne kurulur ve sonra oradaki her konuşlandırılabilir proje için ikililerin doğru alt kümesine sahip olduğumuzu biliyoruz.

Zaman açma ve zaman oluşturma konusuna gelince, bunu daha küçük çözümlere ayrılmadan düzeltmek zor olacak. Burada hızı artırmak için yapıyı paralel hale getirmeyi (bunu yapmanın ve UI ile entegre etmenin bir yolu için google "Parallel MS Build") inceleyebilirsiniz. Ayrıca, tasarıma bakın ve projelerinizden bazılarını genel olarak daha az sonuç verecek şekilde yeniden düzenlemenin yardımcı olup olmayacağına bakın.

Bina ağrısını hafifletme açısından, belirli projelerin oluşturulmasını etkinleştirmek veya devre dışı bırakmak için yapılar için "Configuration Manager ..." seçeneğini kullanabilirsiniz. Belirli projeleri hariç tutabilecek ve belirli projeleri hedeflerken bunu kullanabilecek bir "Proje [n] Yapına" sahip olabilirsiniz.

100'den fazla proje söz konusu olduğunda, çözüm boyutunu azaltmanın faydaları hakkında bu soruya takılıp kalmak istemediğinizi biliyorum, ancak iş yükleme süresini hızlandırmaya gelince başka seçeneğiniz olmadığını düşünüyorum (ve bellek kullanımı) / devenv.

Bununla tipik olarak ne yapacağım, biraz "hata ayıklama" işleminin gerçekte nasıl gerçekleştiğine bağlıdır. Genelde, yerel kopyayı doğru olarak ayarlamamama rağmen. Her projeyi istenen son noktaya çıkarmak için her proje için derleme dizinini kuruyorum.

Bu nedenle, her derlemeden sonra tüm dll'lerin ve herhangi bir windows / web uygulamasının bulunduğu bir klasörüm var ve tüm öğeler uygun konumda. En sonunda dll doğru yere geleceği için yerel kopyaya gerek yoktu.

Not

Yukarıdakiler, genellikle web uygulamaları olan çözümlerim için işe yarar ve referanslarla ilgili herhangi bir sorun yaşamadım, ancak bu mümkün olabilir!

Benzer bir sorunumuz var. Daha küçük çözümler kullanarak çözüyoruz. Her şeyi açan ana bir çözümümüz var. Ama mükemmel. bu kötü. Bu nedenle, daha küçük çözümleri geliştirici türüne göre segmentlere ayırıyoruz. Dolayısıyla, DB geliştiricilerinin ilgilendikleri projeleri, hizmet geliştiricileri ve UI geliştiricileri aynı şeyi yükleyen bir çözümü vardır. Birisinin günlük olarak ihtiyaç duydukları şeyi elde etmek için tüm çözümü açması nadirdir. Bu her derde deva değil - iyi ve kötü yanları var. Bu makaledeki "çoklu çözüm modeli" bölümüne bakın bölümüne (VSS kullanımıyla ilgili bölümü dikkate almayın :)

Bence bu büyüklükteki çözümlerde en iyi uygulama onları ayırmak olmalıdır. "Çözümü", bir soruna çözüm bulmak için gerekli projeleri ve belki başka parçaları bir araya getirme yeri olarak düşünebilirsiniz. 100'den fazla projeyi, genel problemin sadece bir kısmı için çözümler geliştirmek üzere uzmanlaşmış birden fazla çözüme bölerek, gerekli projelerle etkileşimlerinizi hızlandırarak ve problem alanını basitleştirerek belirli bir zamanda daha azıyla başa çıkabilirsiniz.

Her çözüm sorumlu olduğu çıktıyı üretecektir. Bu çıktı, otomatik bir işlemde ayarlanabilen sürüm bilgisine sahip olmalıdır. Çıktı kararlı olduğunda, en son dahili dağıtımla bağımlı projelerdeki ve çözümlerdeki referansları güncelleyebilirsiniz. Yine de koda adım atmak ve kaynağa erişmek istiyorsanız, bunu aslında Visual Studio'nun başvurulan derlemelere girmenize ve hatta kaynak kodunu getirmenize izin vermek için kullanabileceği Microsoft simge sunucusuyla yapabilirsiniz.

Eşzamanlı geliştirme, arayüzleri önceden belirleyerek ve geliştirilmekte olan montajları alay ederek, tam olmayan ancak geliştirmek istediğiniz bağımlılıkları beklerken yapılabilir.

Bunu en iyi uygulama olarak görüyorum çünkü fiziksel olarak bu şekilde parçalara ayırdığınızda genel çabanın ne kadar karmaşık hale gelebileceğinin bir sınırı yok. Tüm projeleri tek bir çözüme yerleştirmek, sonunda bir üst limite ulaşacaktır.

Umarım bu bilgiler yardımcı olur.

Yaklaşık 60'tan fazla projemiz var ve çözüm dosyalarını kullanmıyoruz. C # ve VB.Net projelerinin bir karışımına sahibiz. Performans her zaman bir sorundu. Tüm projeler üzerinde aynı anda çalışmıyoruz. Her geliştirici, üzerinde çalıştıkları projelere göre kendi çözüm dosyalarını oluşturur. Çözüm dosyaları, kaynak kontrolümüze kaydedilmez.

Tüm Sınıf kitaplığı projeleri, kaynak dizinin kökündeki bir CommonBin klasöründe oluşturulur. Yürütülebilir / Web Projeleri kendi klasörlerinde oluşturulur.

CommonBin klasöründen dosya tabanlı referans yerine proje referanslarını kullanmıyoruz. Projeleri inceleyecek ve yapı sırasını belirleyecek özel bir MSBuild Görevi yazdım.

Bunu birkaç yıldır kullanıyoruz ve herhangi bir şikayetimiz yok.

Her şey sizin tanımınız ve bir çözüm ve projenin ne olduğuna dair görüşünüzle ilgilidir. Aklımda bir çözüm, çok özel bir gereksinimi çözen mantıksal bir proje grubu. Geniş bir Intranet uygulaması geliştiriyoruz. Bu Intranet'teki her uygulamanın kendi çözümü vardır ve bu çözüm ayrıca exes veya Windows hizmetleri için projeler içerebilir. Ve sonra, temel sınıflar ve yardımcılar ve httpmodüller gibi şeyler içeren merkezi bir çerçeveye sahibiz. Temel çerçeve oldukça geniştir ve tüm uygulamalar tarafından kullanılır. Pek çok çözümü bu şekilde bölerek, birçoğunun birbiriyle hiçbir ilgisi olmadığı için, bir çözümün gerektirdiği proje miktarını azaltırsınız.

Bir çözümde bu kadar çok projeye sahip olmak kötü bir tasarımdır. Bir çözüm altında bu kadar çok projenin olması için hiçbir sebep olmamalı. Gördüğüm diğer sorun, proje referanslarında, özellikle çözümünüzü daha küçük çözümlere bölmek istiyorsanız, sonunda sizi gerçekten mahvedebilirler.

Benim tavsiyem, bunu yapmak ve merkezi bir çerçeve geliştirmektir (isterseniz kendi Kurumsal Kitaplığı uygulamanız). Paylaşmak için GAC yapabilir veya merkezi bir mağazanız olması için doğrudan dosya konumuna başvurabilirsiniz. Aynı taktiği merkezi iş nesneleri için de kullanabilirsiniz.

DLL'ye doğrudan başvurmak istiyorsanız, onu projenizde copy local false (c: \ mycompany \ bin \ mycompany.dll gibi bir yerde) ile başvurmak isteyeceksiniz. Bir çalışma zamanı, GAC veya çalışma zamanı bölmesinde olmayan bir dosyaya başvurmasını sağlamak için app.config veya web.config dosyanıza bazı ayarlar eklemeniz gerekir. Gerçekte, yerel kopya olup olmaması veya dll'nin çöp kutusunda bitmesi veya GAC'de olması önemli değildir, çünkü yapılandırma her ikisini de geçersiz kılacaktır. Yerel kopyalamanın ve dağınık bir sisteme sahip olmanın kötü bir uygulama olduğunu düşünüyorum. Yine de bu derlemelerden birinde hata ayıklamanız gerekirse, büyük olasılıkla yerel olarak geçici olarak kopyalamanız gerekecektir.

GAC olmadan global olarak bir DLL'nin nasıl kullanılacağı hakkındaki makalemi okuyabilirsiniz. GAC'den gerçekten hoşlanmıyorum çünkü xcopy dağıtımını engelliyor ve uygulamalarda otomatik yeniden başlatmayı tetiklemiyor.

http://nbaked.wordpress.com/2010/03/28/gac-alternative/

CopyLocal = false değerini ayarlamak, derleme süresini azaltır, ancak dağıtım sırasında farklı sorunlara neden olabilir.

Yerel Kopyala'yı Doğru'ya bırakmanız gerektiğinde birçok senaryo vardır, örneğin Üst düzey projeler, İkinci düzey bağımlılıklar, yansıma ile çağrılan DLL'ler.

CopyLocal = false ayarlamayla ilgili deneyimim başarılı değildi. "Altlıkları anlamadıkça" "Yerel Kopyala" proje referanslarını yanlış olarak değiştirmeyin. " Blog yazımda profesyonellerin ve eksilerin özetine bakın .