Visual Studio'da "... dışındaki tüm uyarıları hata olarak değerlendir"

Visual Studio'da, herhangi bir uyarı varsa kodumun derlenmesini önlemek için "Uyarıları hata olarak değerlendir" seçeneğini belirleyebilirim. Ekibimiz bu seçeneği kullanıyor, ancak uyarı olarak tutmak istediğimiz iki uyarı var.

Uyarıları bastırma seçeneği vardır, ancak bunların işe yaramaması için uyarılar olarak görünmelerini İSTİYORUZ.

Görünüşe göre, istediğimiz davranışı elde etmenin tek yolu, uyarı olarak işlem görmesini istediğimiz ikisi dışında her C # uyarı numarasının bir listesini "Belirli uyarılar" metin kutusuna girmek.

Bakım baş ağrısının yanı sıra, bu yaklaşımın en büyük dezavantajı, birkaç uyarının rakamlara sahip olmaması, dolayısıyla bunlara açıkça referans verilememesidir. Örneğin, "Bu başvuru çözülemedi. 'Veri ....' derlemesi bulunamadı."

Bunu yapmanın daha iyi bir yolunu bilen var mı?

Bunun neden yararlı olduğunu hemen anlamayanlar için açıklama. Çoğu uyarının nasıl çalıştığını düşünün. Size yazdığınız kodda biraz yanlış olduğunu söylüyorlar. Onları düzeltmek yaklaşık 10 saniye sürer ve bu, kod tabanını daha temiz tutar.

"Eski" uyarısı bundan çok farklıdır. Bazen düzeltmek, yalnızca yeni bir yöntem imzası tüketmek anlamına gelir. Ancak, tüm bir sınıfın modası geçmişse ve onu yüz binlerce kod satırına dağılmış olarak kullanıyorsanız, düzeltilmesi haftalar veya daha uzun sürebilir. Yapının bu kadar uzun süre bozulmasını istemezsiniz, ancak kesinlikle bunun hakkında bir uyarı görmek İSTERSİNİZ. Bu sadece varsayımsal bir durum değil - bu bizim başımıza geldi.

Birebir "#warning" uyarıları da benzersizdir. Sık sık istiyorum bunu kontrol etmek, ama yapı kırmak istemiyoruz.

WarningsNotAsErrorsProje dosyasına bir -tag ekleyebilirsiniz .

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Not: 612ve 618ikisi de Eski ile ilgili uyarılardır, farkı bilmiyorum ama üzerinde çalıştığım proje 618 uyarısıyla Eski olarak bildiriyor.

/ warnaserror / warnaserror-: 618

veya daha spesifik olarak, sizin durumunuzda:

/ warnaserror / warnaserror-: 612,1030,1701,1702

bu, virgülle ayrılmış listenizdekiler dışındaki tüm uyarıları hata olarak değerlendirmelidir

Neden hata olarak görmediğiniz uyarıları görmeye devam etmek istiyorsunuz? Bunun neden arzu edildiği konusunda kafam karıştı - ya onları düzeltirsin ya da yapmazsın.

İki farklı yapı / çözüm dosyası çalışır mı - veya birini kopyalamak için bir komut dosyası ve daha sonra uyarıları / uyarı düzeyini uygun şekilde değiştirin. Görünüşe göre derleyicinin bazı uygulamalarının ciyaklamasını istiyorsunuz, ancak diğerlerinin devam etmesini istiyorsunuz.

Dolayısıyla farklı derleyici anahtarları, gitmek için iyi bir yol gibi görünüyor. Bunu farklı hedeflerle yapabilirsiniz - biri hata ayıklama veya yayınlama ve diğerleri uyarılar hakkında uygun şekilde etiketlenmiş.

Uyarıları hata olarak değerlendir kullanıyorum.

Nadir durumlarda, bazı kabul edilebilir uyarılar göründüğünde (yani, eski üyeye başvurma veya XML serileştirme sınıflarında eksik belgeler), #pragma devre dışı bırakma ile açıkça bastırılmalıdır. (ve isteğe bağlı olarak temiz bir koda sahip olmama nedeni sağlanabilir) birlikte bir yorum olarak).

Bu direktifin varlığı , bazı soruların olması durumunda bu uyarı ihlalini kimin kabul ettiğini (sürüm kontrolünün "suçlama" eylemiyle) bulmaya da olanak tanır .

Neden basitçe "İçinde 612, 1030, 1701 veya 1702 dışında herhangi bir uyarı olan kodu kontrol eden kişi, beyaz tahtaya gitmeli ve yüz kez yazmalı" diye bir kural olmasın ki, tekrar izin verilmeyen uyarılarla kod girmeyeceğim. '"

pragma uyarısı (C # Referansı)

pragma uyarısı, belirli uyarıları etkinleştirmek veya devre dışı bırakmak için kullanılabilir.

http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx

Bana öyle geliyor ki temel sorun, uyarıları açıkça hata olarak ele almanın ve bunu ihlal eden check-in'lere izin verme şeklindeki görünür politikanızın bir birleşimidir. Dediğiniz gibi, bir uyarıya rağmen çalışmaya devam edebilmek istiyorsunuz. Sadece görmezden gelmek istediğiniz birkaç uyarıdan bahsettiniz, ancak ya takımdaki başka biri başka türden bir uyarıya neden olursa, hangisini düzeltmeniz eşit derecede uzun sürerdi? Bunu da görmezden gelmek istemez miydin?

Mantıksal çözüm, ya 1) Eğer kod derlenmezse check-in'lere izin vermemek (yani uyarıları oluşturanların, yapıyı bozdukları için düzeltmeleri gerekeceği anlamına gelir) ya da 2) uyarıları uyarı olarak ele almak olacaktır. Biri uyarıları hata olarak değerlendiren, kodun uyarı içermediğinden emin olmak için düzenli olarak çalıştırılabilen ve bunları yalnızca uyarı olarak değerlendiren ve başkası bir uyarı verse bile çalışmanıza izin veren iki yapı yapılandırması oluşturun.