"Traktuj wszystkie ostrzeżenia jako błędy z wyjątkiem ..." w Visual Studio
W Visual Studio mogę wybrać opcję "traktuj ostrzeżenia jako błędy", aby zapobiec kompilacji 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 tłumienia ostrzeżeń, ale chcemy, aby pojawiały się jako ostrzeżenia, więc to nie zadziała.
Wygląda na to, że jedynym sposobem na uzyskanie pożądanego zachowania jest wprowadzenie listy każdego numeru ostrzeżenia W C# w polu tekstowym "konkretne Ostrzeżenia" , z wyjątkiem tych dwóch, które chcemy traktować jako ostrzeżenia.
Poza bólem głowy w utrzymaniu, największą wadą tego podejścia jest to, że kilka ostrzeżeń nie ma numerów, więc nie można ich wyraźnie odwołać. Na przykład, " Could not resolve this reference. Nie można zlokalizować danych assembly....'"
Czy ktoś zna lepszy sposób na to?
Wyjaśnienie dla tych, którzy nie widzą od razu, dlaczego jest to przydatne. Pomyśl, jak działa większość ostrzeżeń. Mówią ci coś jest trochę nie tak w kodzie, który właśnie napisałeś. Naprawa zajmuje około 10 sekund, a to sprawia, że baza kodu jest czystsza.
"przestarzałe" ostrzeżenie jest bardzo różne od tego. Czasami jego naprawa oznacza po prostu zużywanie nowej sygnatury metody. Ale jeśli cała klasa jest przestarzała i masz jej użycie rozproszone po setkach tysięcy linii kodu, naprawienie tego może zająć tygodnie lub więcej. Nie chcesz, aby konstrukcja była zepsuta tak długo, ale zdecydowanie chcesz zobacz Ostrzeżenie. To nie jest tylko hipotetyczna sprawa.to się przydarzyło nam.
Dosłowne Ostrzeżenia" #warning " są również unikalne. Często chcę, aby to sprawdzić, ale nie chcę łamać kompilacji.
8 answers
Możesz dodać WarningsNotAsErrors-tag w pliku projektu.
<PropertyGroup>
...
...
<WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>
Uwaga: 612 i 618 Oba ostrzeżenia są przestarzałe, nie znam różnicy, ale projekt, nad którym pracuję, zgłasza przestarzałe Ostrzeżenie 618.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-03-17 06:53:37
/ warnaserror / warnaserror -: 618
A dokładniej, w Twoim przypadku:
/ warnaserror / warnaserror -: 612,1030,1701,1702
To powinno traktować wszystkie ostrzeżenia jako błędy z wyjątkiem tych z listy rozdzielonych przecinkami
Dlaczego chcesz wciąż widzieć Ostrzeżenia, których nie traktujesz jako błędów? Jestem zdezorientowany, dlaczego jest to pożądane - albo je naprawiasz, albo nie.
Czy dwa różne pliki build/solution działają - lub skrypt do skopiowania jednego, a następnie zmodyfikowania poziomu ostrzeżeń/ostrzeżeń byłby odpowiedni. Wydaje się, że być może chcesz, aby niektóre egzekucje kompilatora squawk, ale inne chcesz kontynuować.
Więc różne przełączniki kompilatora wydają się dobrym rozwiązaniem. Ty można to zrobić z różnymi celami - jeden oznaczony jako debug lub release, a inne odpowiednio oznaczone ostrzeżeniami.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-06 02:21:25
Używam traktuj ostrzeżenia jako błędy.
W rzadkich przypadkach, gdy pojawia się jakieś akceptowalne Ostrzeżenie (np. odwołanie do przestarzałego elementu lub brakującej dokumentacji na klasach serializacji XML), to musi być jawnie tłumione z #pragma disable (opcjonalnie powód braku czystego kodu może być podany jako komentarz).
Obecność tej dyrektywy pozwala również dowiedzieć się, kto przyjął to Ostrzeżenie naruszenie (poprzez "obwinianie" działania Kontrola wersji) w razie pytań.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-22 06:31:36
Dlaczego po prostu nie mieć zasady mówiącej "kto sprawdza w kodzie z dowolnym ostrzeżeniem wewnątrz niego inne niż 612, 1030, 1701 lub 1702 w nim musi przejść do tablicy i napisać sto razy" Nie będę sprawdzać w kodzie z zakazanych ostrzeżeń ponownie.'"
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-30 16:45:46
Pragma warning (C# Reference)
Ostrzeżenie Pragma może być użyte do włączenia lub wyłączenia niektórych ostrzeżeń.
Http://msdn.microsoft.com/en-us/library/441722ys (VS.80). aspx
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-01-22 06:43:40
Wydaje mi się, że głównym problemem jest tak naprawdę połączenie Twojego traktowania ostrzeżeń jako błędów, kiedy wyraźnie nie są, i Twojej pozornej polityki zezwalania na kontrole, które naruszają to. Jak mówisz, chcesz być w stanie kontynuować pracę pomimo ostrzeżenia. Wspomniałeś tylko o kilku ostrzeżeniach, które chcesz zignorować, ale co, jeśli ktoś inny w zespole spowodował inne ostrzeżenia, które zajęłyby Ci tyle samo czasu, aby je naprawić? Czy nie chciałbyś być w stanie zignorować tego jako więc?
Logicznym rozwiązaniem byłoby albo 1) Wyłączenie checkIn ' ów, jeśli kod nie zostanie skompilowany (co oznacza, że ci, którzy stworzyli ostrzeżenia, będą musieli je naprawić, ponieważ w efekcie złamali kompilację), albo 2) traktowanie ostrzeżeń jako ostrzeżeń. Utwórz dwie konfiguracje build, jedną, która traktuje ostrzeżenia jako błędy, które mogą być uruchamiane regularnie, aby zapewnić, że kod jest wolny od ostrzeżeń, oraz drugą, która traktuje je tylko jako ostrzeżenia i pozwala na pracę nawet jeśli ktoś inny wprowadził Uwaga.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-10 18:22:31