„Traktuj wszystkie ostrzeżenia jako błędy z wyjątkiem…” w programie Visual Studio

W programie Visual Studio mogę wybrać opcję „Traktuj ostrzeżenia jako błędy”, aby zapobiec kompilacji mojego kodu, jeśli są jakieś ostrzeżenia. Nasz zespół korzysta z tej opcji, ale są dwa ostrzeżenia, które chcielibyśmy zachować jako ostrzeżenia.

Istnieje opcja pomijania ostrzeżeń, ale chcemy, aby były one wyświetlane jako ostrzeżenia, więc to nie zadziała.

Wydaje się, że jedynym sposobem uzyskania pożądanego zachowania jest wprowadzenie listy wszystkich numerów ostrzeżeń C # w polu tekstowym „Specyficzne ostrzeżenia”, z wyjątkiem dwóch, które chcemy traktować jako ostrzeżenia.

Oprócz bólu głowy związanego z konserwacją, największą wadą tego podejścia jest to, że kilka ostrzeżeń nie ma liczb, więc nie można do nich odwoływać się bezpośrednio. Na przykład „Nie można rozwiązać tego odwołania. Nie można zlokalizować zestawu 'Dane ....'”

Czy ktoś zna lepszy sposób na zrobienie tego?

Wyjaśnienie tym, którzy nie widzą od razu, dlaczego jest to przydatne. Pomyśl, jak działa większość ostrzeżeń. Mówią ci, że coś jest trochę nie tak w kodzie, który właśnie napisałeś. Naprawienie ich zajmuje około 10 sekund, a to sprawia, że ​​baza kodu jest czystsza.

Ostrzeżenie „Przestarzałe” bardzo różni się od tego. Czasami naprawienie tego oznacza po prostu użycie nowej sygnatury metody. Ale jeśli cała klasa jest przestarzała, a używasz jej rozproszonego w setkach tysięcy linii kodu, naprawa może zająć tygodnie lub dłużej. Nie chcesz, aby kompilacja była zepsuta przez tak długi czas, ale na pewno chcesz zobaczyć ostrzeżenie o tym. To nie jest tylko hipotetyczny przypadek - to nam się przydarzyło.

Dosłowne ostrzeżenia „#warning” są również unikalne. Często chcę to sprawdzić, ale nie chcę zepsuć kompilacji.

Możesz dodać WarningsNotAsErrors-tag w pliku projektu.

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

Uwaga: 612i 618to zarówno ostrzeżenia o przestarzały, nie wiem różnicę ale projekt pracuję nad donosi Przestarzałe z ostrzeżeniem 618.

/ warnaserror / warnaserror-: 618

a dokładniej w twoim przypadku:

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

powinno to traktować wszystkie ostrzeżenia jako błędy, z wyjątkiem tych na liście oddzielonej przecinkami

Dlaczego chcesz nadal widzieć ostrzeżenia, których nie traktujesz jako błędów? Nie wiem, dlaczego jest to pożądane - albo je naprawisz, albo nie.

Czy zadziałałyby dwa różne pliki kompilacji / rozwiązania - czy skrypt kopiujący jeden, a następnie odpowiednio zmodyfikowany poziom ostrzeżeń / ostrzeżeń. Wygląda na to, że być może chcesz, aby niektóre wykonania kompilatora krzyczały, ale inne chcesz kontynuować.

Dlatego różne przełączniki kompilatora wydają się dobrym rozwiązaniem. Można to zrobić z różnymi celami - jeden oznaczony jako debug lub release, a drugi odpowiednio oznaczony ostrzeżeniami.

Używam traktuj ostrzeżenia jako błędy.

W rzadkich przypadkach, gdy pojawia się jakieś akceptowalne ostrzeżenie (np. Odwołuje się do przestarzałego elementu członkowskiego lub brakuje dokumentacji na temat klas serializacji XML), należy je jawnie wyłączyć za pomocą #pragma disable (i opcjonalnie można podać przyczynę braku czystego kodu jako komentarz).

Obecność tej dyrektywy pozwala również dowiedzieć się, kto przyjął to ostrzeżenie o naruszeniu (poprzez działanie „winy” kontroli wersji) w przypadku pojawienia się pytań.

Dlaczego nie zastosować reguły mówiącej: „Ktokolwiek sprawdza kod z jakimkolwiek ostrzeżeniem w środku innym niż 612, 1030, 1701 lub 1702, musi podejść do tablicy i napisać sto razy:„ Nie sprawdzę ponownie kodu z niedozwolonymi ostrzeżeniami. „”

ostrzeżenie pragma (odwołanie w C #)

Ostrzeżenie pragma może służyć do włączania lub wyłączania niektórych ostrzeżeń.

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

Wydaje mi się, że głównym problemem jest tak naprawdę połączenie twojego traktowania ostrzeżeń jako błędów, kiedy wyraźnie ich nie ma, oraz twojej widocznej polityki zezwalania na meldowanie się, które to naruszają. Jak mówisz, chcesz móc kontynuować pracę pomimo ostrzeżenia. Wspomniałeś tylko o kilku ostrzeżeniach, które chcesz móc zignorować, ale co by było, gdyby ktoś inny z zespołu spowodował inne ostrzeżenia, których naprawienie zajęłoby Ci równie dużo czasu? Czy nie chciałbyś też móc to zignorować?

Logicznym rozwiązaniem byłoby albo 1) zablokowanie sprawdzania, jeśli kod się nie kompiluje (co oznacza, że ​​ci, którzy utworzyli ostrzeżenia, będą musieli je naprawić, ponieważ w efekcie zepsuli kompilację) lub 2) traktują ostrzeżenia jako ostrzeżenia. Utwórz dwie konfiguracje kompilacji, jedną, która traktuje ostrzeżenia jako błędy, które mogą być uruchamiane regularnie, aby zapewnić, że kod nie zawiera ostrzeżeń, i drugą, która traktuje je tylko jako ostrzeżenia i pozwala pracować, nawet jeśli ktoś wprowadził ostrzeżenie.