Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Chociaż kompilator nie ma oddzielnego preprocesora, dyrektywy opisane w tej sekcji są przetwarzane tak, jakby istniały. Są one używane do pomocy w kompilacji warunkowej. W przeciwieństwie do dyrektyw C i C++ nie można używać tych dyrektyw do tworzenia makr. Dyrektywa preprocesora musi być jedyną instrukcją w wierszu.
Aplikacje oparte na plikach
Aplikacje oparte na plikach to programy, które są kompilowane i uruchamiane przy użyciu dotnet run Program.cs (lub dowolnego *.cs pliku). Kompilator języka C# ignoruje te dyrektywy preprocesora, ale system kompilacji analizuje je w celu wygenerowania danych wyjściowych. Te dyrektywy generują ostrzeżenia w przypadku napotkania w kompilacji opartej na projekcie.
Kompilator języka C# ignoruje dowolną dyrektywę preprocesora rozpoczynającą się od #: lub #!.
Dyrektywa #! preprocesora umożliwia powłokom Unix bezpośrednie wykonywanie pliku C# przy użyciu dotnet run. Na przykład:
#!/usr/bin/env dotnet run
Console.WriteLine("Hello");
Powyższy fragment kodu informuje powłokę systemu Unix o wykonaniu pliku przy użyciu polecenia dotnet run. Polecenie /usr/bin/env lokalizuje dotnet plik wykonywalny w ścieżce, dzięki czemu takie podejście jest przenośne w różnych dystrybucjach systemów Unix i macOS. Wiersz #! musi być pierwszym wierszem w pliku, a następujące tokeny stanowią program do uruchomienia. Musisz włączyć uprawnienie do wykonywania (x) w pliku C# dla tej funkcji.
Dyrektywy #: , które są używane w aplikacjach opartych na plikach, obejmują:
#:sdk:Pierwsze wystąpienie określa wartość węzła
<Project Sdk="value" />. Kolejne wystąpienia określają<Sdk Name="value" Version="version" />węzeł. Wersję można pominąć (np. w przypadku określenia w global.json lub dołączonej do zestawu SDK platformy .NET). Na przykład:#:sdk Microsoft.NET.Sdk.Web #:sdk Aspire.AppHost.Sdk@9.4.1Dwa poprzednie preprocesory są tłumaczone na:
<Project Sdk="Microsoft.NET.Sdk.Web" /> <Sdk Name="Aspire.AppHost.Sdk" Version="9.4.1" />#:property:Wystąpienia elementu
#:propertysą tłumaczone na elementy właściwości za pomocą<PropertyGroup>. Token formularzaName=valuemusi być zgodny z tokenemproperty. Następujące przykładowe dyrektywy są prawidłowymipropertytokenami:#:property TargetFramework=net11.0 #:property LangVersion=previewPoprzednie dwie właściwości są tłumaczone na:
<TargetFramework>net11.0</TargetFramework> <LangVersion>preview</LangVersion>#:package:Wystąpienia elementu
#:packagesą przekształcane na elementyPackageReference, aby uwzględnić pakiety NuGet z określoną wersją w twoim pliku. Na przykład:#:package System.CommandLine@2.0.0-*Poprzedni token preprocesora jest tłumaczony na:
<PackageReference Include="System.CommandLine" Version="2.0.0-*">#:project:Wystąpienia elementu
#:projectsą tłumaczone naProjectReferenceelementy w celu uwzględnienia projektu z określoną ścieżką do projektu. Na przykład:#:project ../Path/To.ExamplePoprzedni token preprocesora jest tłumaczony na:
<ProjectReference Include="../Path/To.Example/To.Example.csproj" />
Narzędzia mogą dodawać nowe tokeny zgodnie z konwencją #: .
Kontekst dopuszczany do wartości null
Dyrektywa preprocesora
Oba konteksty można określić na poziomie projektu (poza kodem źródłowym języka C#), dodając Nullable element do PropertyGroup elementu. Dyrektywa #nullable kontroluje adnotację i flagi ostrzegawcze i ma pierwszeństwo przed ustawieniami na poziomie projektu. Dyrektywa ustawia flagę, którą kontroluje, dopóki inna dyrektywa nie zastąpi jej, lub do końca pliku źródłowego.
Efekt dyrektyw jest następujący:
-
#nullable disable: ustawia kontekst anulowalności wyłączony. -
#nullable enable: ustawia kontekst dopuszczalny do wartości null . -
#nullable restore: przywraca kontekst dopuszczalny do wartości null do ustawień projektu. -
#nullable disable annotations: ustawia flagę adnotacji w kontekście dopuszczającym wartość null na wyłączoną. -
#nullable enable annotations: ustawia flagę adnotacji w kontekście dopuszczającym wartości null, aby było włączone. -
#nullable restore annotations: przywraca flagę adnotacji w kontekście dopuszczalności wartości null do ustawień projektu. -
#nullable disable warnings: ustawia flagę ostrzegawczą w kontekście dopuszczania wartości null na wyłączoną. -
#nullable enable warnings: ustawia flagę ostrzeżenia w kontekście obsługującym null, aby był włączony. -
#nullable restore warnings: przywraca flagę ostrzegawczą w kontekście nullable do ustawień projektu.
Kompilacja warunkowa
Do kontrolowania kompilacji warunkowej używa się czterech dyrektyw preprocesora:
-
#if: Otwiera kompilację warunkową, w której kod jest kompilowany tylko wtedy, gdy określony symbol jest zdefiniowany. -
#elif: zamyka poprzednią kompilację warunkową i otwiera nową kompilację warunkową na podstawie tego, czy określony symbol jest zdefiniowany. -
#else: zamyka poprzednią kompilację warunkową i otwiera nową kompilację warunkową, jeśli poprzedni określony symbol nie jest zdefiniowany. -
#endif: zamyka poprzednią kompilację warunkową.
System kompilacji jest również świadomy wstępnie zdefiniowanych symboli preprocesora reprezentujących różne platformy docelowe w projektach w stylu zestawu SDK. Są one przydatne podczas tworzenia aplikacji, które mogą być przeznaczone dla więcej niż jednej wersji platformy .NET.
| Platformy docelowe | Symbole | Dodatkowe symbole (dostępne w zestawach .NET 5+ SDK) |
Symbole platformy (dostępne tylko podczas określania programu TFM specyficznego dla systemu operacyjnego) |
|---|---|---|---|
| .NET Framework |
NETFRAMEWORK, NET481, , , NET48NET472NET471NET47NET462NET461NET46NET452NET451NET45NET40NET35NET20 |
NET48_OR_GREATER, NET472_OR_GREATER, , , NET471_OR_GREATERNET47_OR_GREATERNET462_OR_GREATERNET461_OR_GREATERNET46_OR_GREATERNET452_OR_GREATERNET451_OR_GREATERNET45_OR_GREATERNET40_OR_GREATERNET35_OR_GREATERNET20_OR_GREATER |
|
| .NET Standard |
NETSTANDARD, NETSTANDARD2_1, , , NETSTANDARD2_0NETSTANDARD1_6NETSTANDARD1_5NETSTANDARD1_4NETSTANDARD1_3NETSTANDARD1_2NETSTANDARD1_1NETSTANDARD1_0 |
NETSTANDARD2_1_OR_GREATER, NETSTANDARD2_0_OR_GREATER, , NETSTANDARD1_6_OR_GREATER, NETSTANDARD1_5_OR_GREATERNETSTANDARD1_4_OR_GREATER, NETSTANDARD1_3_OR_GREATER, , NETSTANDARD1_2_OR_GREATERNETSTANDARD1_1_OR_GREATERNETSTANDARD1_0_OR_GREATER |
|
| .NET 5+ (i .NET Core) |
NET, NET10_0, , , NET9_0NET8_0NET7_0NET6_0NET5_0NETCOREAPPNETCOREAPP3_1NETCOREAPP3_0NETCOREAPP2_2NETCOREAPP2_1NETCOREAPP2_0NETCOREAPP1_1NETCOREAPP1_0 |
NET10_0_OR_GREATER, NET9_0_OR_GREATER, , , NET8_0_OR_GREATERNET7_0_OR_GREATERNET6_0_OR_GREATERNET5_0_OR_GREATERNETCOREAPP3_1_OR_GREATERNETCOREAPP3_0_OR_GREATERNETCOREAPP2_2_OR_GREATERNETCOREAPP2_1_OR_GREATERNETCOREAPP2_0_OR_GREATERNETCOREAPP1_1_OR_GREATERNETCOREAPP1_0_OR_GREATER |
ANDROID, BROWSER, , IOS, MACCATALYSTMACOS, , TVOS, , WINDOWS[OS][version] (na przykład IOS15_1),[OS][version]_OR_GREATER (na przykład IOS15_1_OR_GREATER) |
Uwaga
- Symbole bez wersji są definiowane niezależnie od docelowej wersji.
- Symbole specyficzne dla wersji są definiowane tylko dla docelowej wersji.
- Symbole
<framework>_OR_GREATERsą definiowane dla docelowej wersji i wszystkich wcześniejszych wersji. Jeśli na przykład używasz platformy .NET Framework 2.0, zdefiniowane są następujące symbole:NET20, ,NET20_OR_GREATERNET11_OR_GREATERiNET10_OR_GREATER. - Symbole
NETSTANDARD<x>_<y>_OR_GREATERsą definiowane tylko dla obiektów docelowych platformy .NET Standard, a nie dla obiektów docelowych implementujących platformę .NET Standard, takich jak .NET Core i .NET Framework. - Różnią się one od obiektów docelowych monikers (TFMs) używanych przez
TargetFrameworkMSBuild i NuGet.
Uwaga
W przypadku tradycyjnych projektów innych niż zestaw SDK należy ręcznie skonfigurować symbole kompilacji warunkowej dla różnych platform docelowych w programie Visual Studio za pośrednictwem stron właściwości projektu.
Inne wstępnie zdefiniowane symbole obejmują DEBUG stałe i .TRACE Możesz zastąpić wartości ustawione dla projektu przy użyciu polecenia #define. Na przykład symbol DEBUG jest automatycznie ustawiany w zależności od właściwości konfiguracji kompilacji ("Debugowanie" lub "Wydanie").
Kompilator języka C# kompiluje kod między dyrektywą #if a #endif dyrektywą tylko wtedy, gdy określony symbol jest zdefiniowany, lub nie jest zdefiniowany, gdy ! nie jest używany operator. W przeciwieństwie do języka C i C++, nie można przypisać wartości liczbowej do symbolu. Wyrażenie #if w języku C# jest logiczne i sprawdza tylko, czy symbol jest zdefiniowany. Na przykład następujący kod jest kompilowany, gdy DEBUG jest zdefiniowany:
#if DEBUG
Console.WriteLine("Debug version");
#endif
Poniższy kod jest kompilowany, gdy MYTEST nie jest zdefiniowany:
#if !MYTEST
Console.WriteLine("MYTEST is not defined");
#endif
Możesz użyć operatorów == (równości) i != (nierówności), aby przetestować bool wartości true lub false.
true oznacza, że symbol jest zdefiniowany. Instrukcja #if DEBUG ma takie samo znaczenie jak #if (DEBUG == true). Możesz użyć operatorów && (i), || (lub)i ! (nie), aby ocenić, czy zdefiniowano wiele symboli. Można również grupować symbole i operatory za pomocą nawiasów.
Poniższy przykład przedstawia złożoną dyrektywę, która umożliwia kodowi korzystanie z nowszych funkcji platformy .NET przy zachowaniu zgodności z poprzednimi wersjami. Załóżmy na przykład, że używasz pakietu NuGet w kodzie, ale pakiet obsługuje tylko platformę .NET 6 i w górę, a także program .NET Standard 2.0 i nowszy:
#if (NET6_0_OR_GREATER || NETSTANDARD2_0_OR_GREATER)
Console.WriteLine("Using .NET 6+ or .NET Standard 2+ code.");
#else
Console.WriteLine("Using older code that doesn't support the above .NET versions.");
#endif
#if, wraz z dyrektywami #else, #elif, #endif, #definei #undef umożliwia dołączanie lub wykluczanie kodu na podstawie istnienia co najmniej jednego symbolu. Kompilacja warunkowa może być przydatna podczas kompilowania kodu kompilacji debugowania lub kompilowania dla określonej konfiguracji.
#elif umożliwia utworzenie złożonej dyrektywy warunkowej. Wyrażenie #elif jest oceniane, jeśli ani poprzednie wyrażenie dyrektywy #if, ani poprzednie, opcjonalne wyrażenie dyrektywy #elif nie równa się true.
#elif Jeśli wyrażenie zwróci wartość true, kompilator oblicza cały kod między #elif i następną dyrektywą warunkową. Na przykład:
#define VC7
//...
#if DEBUG
Console.WriteLine("Debug build");
#elif VC7
Console.WriteLine("Visual Studio 7");
#endif
#else pozwala utworzyć złożoną dyrektywę warunkową, tak aby, jeśli żadne z wyrażeń w poprzednich #if lub (opcjonalnych) #elif dyrektywach daje wartość true, kompilator oceni cały kod między #else i następnym #endif.
#endif(#endif) musi być następną dyrektywą preprocesora po #else.
#endif określa koniec dyrektywy warunkowej, która rozpoczęła się od #if dyrektywy.
W poniższym przykładzie pokazano, jak zdefiniować MYTEST symbol w pliku, a następnie przetestować wartości MYTEST symboli i DEBUG . Dane wyjściowe tego przykładu zależą od tego, czy projekt został utworzony w trybie konfiguracji debugowania , czy wydania .
#define MYTEST
using System;
public class MyClass
{
static void Main()
{
#if (DEBUG && !MYTEST)
Console.WriteLine("DEBUG is defined");
#elif (!DEBUG && MYTEST)
Console.WriteLine("MYTEST is defined");
#elif (DEBUG && MYTEST)
Console.WriteLine("DEBUG and MYTEST are defined");
#else
Console.WriteLine("DEBUG and MYTEST are not defined");
#endif
}
}
W poniższym przykładzie pokazano, jak przetestować różne platformy docelowe, aby w miarę możliwości używać nowszych interfejsów API:
public class MyClass
{
static void Main()
{
#if NET40
WebClient _client = new WebClient();
#else
HttpClient _client = new HttpClient();
#endif
}
//...
}
Definiowanie symboli
Do definiowania lub niezdefiniowania symboli kompilacji warunkowej są używane następujące dwie dyrektywy preprocesora:
-
#define: Zdefiniuj symbol. -
#undef: Niezdefiniuj symbol.
#define Służy do definiowania symbolu. Jeśli używasz symbolu jako wyrażenia przekazanego do dyrektywy #if, wyrażenie zwraca wartość true, jak pokazano w poniższym przykładzie:
#define VERBOSE
#if VERBOSE
Console.WriteLine("Verbose output version");
#endif
Uwaga
W języku C# stałe pierwotne powinny być definiowane przy użyciu słowa kluczowego const . Deklaracja const tworzy element członkowski static , którego nie można modyfikować w czasie wykonywania. Dyrektywy #define nie można używać do deklarowania wartości stałych, ponieważ zwykle odbywa się w językach C i C++. Jeśli masz kilka takich stałych, rozważ utworzenie oddzielnej klasy "Stałe", aby je przechowywać.
Symbole mogą służyć do określania warunków kompilacji. Możesz przetestować symbol za pomocą symbolu #if lub #elif. Można również użyć polecenia ConditionalAttribute , aby wykonać kompilację warunkową. Można zdefiniować symbol, ale nie można przypisać wartości do symbolu. Dyrektywa #define musi pojawić się w pliku przed użyciem instrukcji, które nie są również dyrektywami preprocesora. Możesz również zdefiniować symbol za pomocą opcji kompilatora DefineConstants . Możesz usunąć definicję symbolu za pomocą #undefpolecenia .
Definiowanie regionów
Regiony kodu, które można zwinąć w konspekcie, można zdefiniować przy użyciu następujących dwóch dyrektyw preprocesora:
-
#region: Uruchom region. -
#endregion: Kończ region.
#region Umożliwia określenie bloku kodu, który można rozwinąć lub zwinąć podczas korzystania z funkcji tworzenia konspektowania edytora kodu. W dłuższych plikach kodu wygodne jest zwinięcie lub ukrycie jednego lub większej liczby regionów, dzięki czemu można skupić się na części aktualnie działającego pliku. W poniższym przykładzie pokazano, jak zdefiniować region:
#region MyClass definition
public class MyClass
{
static void Main()
{
}
}
#endregion
Blok #region musi zostać zakończony dyrektywą #endregion . Blok #region nie może nakładać się na #if blok.
#region Blok można jednak zagnieżdżać w #if bloku, a #if blok można zagnieżdżać w #region bloku.
Informacje o błędach i ostrzeżeniach
Poinstruuj kompilator, aby wygenerował błędy i ostrzeżenia kompilatora zdefiniowanego przez użytkownika oraz informacje o wierszu sterowania przy użyciu następujących dyrektyw:
-
#error: Wygeneruj błąd kompilatora z określonym komunikatem. -
#warning: Wygeneruj ostrzeżenie kompilatora z określonym komunikatem. -
#line: Zmień numer wiersza wydrukowany za pomocą komunikatów kompilatora.
#error Umożliwia wygenerowanie błędu zdefiniowanego przez użytkownika CS1029 z określonej lokalizacji w kodzie. Na przykład:
#error Deprecated code in this method.
Uwaga
Kompilator traktuje #error version w specjalny sposób i zgłasza błąd kompilatora CS8304 z komunikatem zawierającym używany kompilator i wersje językowe.
#warning umożliwia wygenerowanie ostrzeżenia kompilatora na poziomie CS1030 z określonej lokalizacji w kodzie. Na przykład:
#warning Deprecated code in this method.
#line Umożliwia zmodyfikowanie numerowania wiersza kompilatora i (opcjonalnie) danych wyjściowych nazwy pliku pod kątem błędów i ostrzeżeń.
W poniższym przykładzie pokazano, jak zgłosić dwa ostrzeżenia skojarzone z numerami wierszy. Dyrektywa #line 200 ustala numer następnej linii na 200 (chociaż wartość domyślna to #6), a do następnej dyrektywy #line nazwa pliku będzie raportowana jako "Special". Dyrektywa #line default przywraca numerację linii do ustawień domyślnych, które uwzględniają linie ponownie numerowane przez poprzednią dyrektywę.
class MainClass
{
static void Main()
{
#line 200 "Special"
int i;
int j;
#line default
char c;
float f;
#line hidden // numbering not affected
string s;
double d;
}
}
Kompilacja generuje następujące dane wyjściowe:
Special(200,13): warning CS0168: The variable 'i' is declared but never used
Special(201,13): warning CS0168: The variable 'j' is declared but never used
MainClass.cs(9,14): warning CS0168: The variable 'c' is declared but never used
MainClass.cs(10,15): warning CS0168: The variable 'f' is declared but never used
MainClass.cs(12,16): warning CS0168: The variable 's' is declared but never used
MainClass.cs(13,16): warning CS0168: The variable 'd' is declared but never used
Dyrektywa #line może być używana w zautomatyzowanym, pośrednim kroku procesu kompilacji. Jeśli na przykład wiersze zostały usunięte z oryginalnego pliku kodu źródłowego, ale nadal chcesz, aby kompilator wygenerował dane wyjściowe na podstawie oryginalnego numerowania wiersza w pliku, można usunąć wiersze, a następnie zasymulować oryginalne numerowanie wierszy za pomocą #linepolecenia .
Dyrektywa #line hidden ukrywa kolejne wiersze z debugera, tak aby po przejściu przez dewelopera przez kod wszelkie wiersze między dyrektywą a #line hidden następną #line (zakładając, że nie jest to inna #line hidden dyrektywa) zostaną zastąpione. Tej opcji można również użyć, aby umożliwić ASP.NET rozróżnianie kodu zdefiniowanego przez użytkownika i wygenerowanego przez maszynę. Chociaż ASP.NET jest głównym odbiorcą tej funkcji, prawdopodobnie więcej generatorów źródeł korzysta z niej.
#line hidden Dyrektywa nie ma wpływu na nazwy plików ani numery wierszy w raportowaniu błędów. Oznacza to, że jeśli kompilator znajdzie błąd w ukrytym bloku, kompilator zgłasza bieżącą nazwę pliku i numer wiersza błędu.
Dyrektywa #line filename określa nazwę pliku, którą chcesz wyświetlić w danych wyjściowych kompilatora. Domyślnie jest używana rzeczywista nazwa pliku kodu źródłowego. Nazwa pliku musi być w podwójnym cudzysłowie ("") i musi być zgodna z numerem wiersza.
Możesz użyć nowej formy dyrektywy #line:
#line (1, 1) - (5, 60) 10 "partial-class.cs"
/*34567*/int b = 0;
Składniki tego formularza to:
-
(1, 1): Linia początkowa i kolumna pierwszego znaku w linii następującej po dyrektywie. W tym przykładzie następny wiersz zostanie zgłoszony jako wiersz 1, kolumna 1. -
(5, 60): wiersz końcowy i kolumna dla oznaczonego regionu. -
10: przesunięcie kolumny dla#linedyrektywy, która ma obowiązywać. W tym przykładzie 10 kolumna zostanie zgłoszona jako kolumna pierwsza. Deklaracjaint b = 0;zaczyna się od tej kolumny. To pole jest opcjonalne. W przypadku pominięcia dyrektywa ma wpływ na pierwszą kolumnę. -
"partial-class.cs": nazwa pliku wyjściowego.
Powyższy przykład wygenerowałby następujące ostrzeżenie:
partial-class.cs(1,5,1,6): warning CS0219: The variable 'b' is assigned but its value is never used
Po ponownym mapowania zmiennej b, znajduje się w pierwszym wierszu, w znaku sześciu znaków pliku partial-class.cs.
Języki specyficzne dla domeny (DSL) zwykle używają tego formatu, aby zapewnić lepsze mapowanie z pliku źródłowego do wygenerowanych danych wyjściowych języka C#. Najczęstszym zastosowaniem tej rozszerzonej dyrektywy #line jest ponowne mapowanie ostrzeżeń lub błędów, które pojawiają się w wygenerowanym pliku do oryginalnego źródła. Rozważmy na przykład tę stronę razor:
@page "/"
Time: @DateTime.NowAndThen
Właściwość DateTime.Now została wpisana niepoprawnie jako DateTime.NowAndThen. Wygenerowany kod C# dla tego fragmentu kodu razor wygląda następująco:page.g.cs
_builder.Add("Time: ");
#line (2, 6) - (2, 27) 15 "page.razor"
_builder.Add(DateTime.NowAndThen);
Dane wyjściowe kompilatora dla poprzedniego fragmentu kodu to:
page.razor(2, 2, 2, 27)error CS0117: 'DateTime' does not contain a definition for 'NowAndThen'
Wiersz 2, kolumna 6 w page.razor to miejsce, w którym rozpoczyna się tekst @DateTime.NowAndThen, oznaczany przez (2, 6) w dyrektywie. Zakres @DateTime.NowAndThen kończy się w wierszu 2, w kolumnie 27, co jest zaznaczone przez (2, 27) w dyrektywie. Tekst dla DateTime.NowAndThen zaczyna się w kolumnie 15 na page.g.cs, co jest zaznaczone przez 15 w dyrektywie. Kompilator zgłasza błąd w lokalizacji w page.razor. Deweloper może przejść bezpośrednio do błędu w kodzie źródłowym, a nie do wygenerowanego źródła.
Aby wyświetlić więcej przykładów tego formatu, zobacz specyfikację funkcji w sekcji dotyczącej przykładów.
Pragma — dyrektywy
#pragma udostępnia kompilatorowi specjalne instrukcje dotyczące kompilacji pliku, w którym się pojawia. Kompilator musi obsługiwać używane pragmas. Innymi słowy, nie można użyć #pragma polecenia do tworzenia niestandardowych instrukcji przetwarzania wstępnego.
-
#pragma warning: Włącza lub wyłącza ostrzeżenia. -
#pragma checksum: Generuj sumę kontrolną.
#pragma pragma-name pragma-arguments
Gdzie pragma-name jest nazwą rozpoznanej pragma i pragma-arguments jest argumentami specyficznymi dla pragma.
ostrzeżenie #pragma
#pragma warning może włączać lub wyłączać niektóre ostrzeżenia.
#pragma warning disable format i #pragma warning enable format kontrolują formatowanie bloków kodu w programie Visual Studio.
#pragma warning disable warning-list
#pragma warning restore warning-list
Gdzie warning-list to rozdzielona przecinkami lista numerów ostrzeżeń, takich jak 414, CS3021. Prefiks "CS" jest opcjonalny. Jeśli nie określono żadnych numerów ostrzeżeń, disable wyłącza wszystkie ostrzeżenia i restore włącza wszystkie ostrzeżenia.
Uwaga
Aby znaleźć numery ostrzeżeń w programie Visual Studio, skompiluj projekt, a następnie poszukaj numerów ostrzeżeń w oknie Dane wyjściowe .
Element disable zaczyna się od następnego wiersza pliku źródłowego. Ostrzeżenie zostanie przywrócone w wierszu po .restore Jeśli nie restore ma w pliku, ostrzeżenia zostaną przywrócone do stanu domyślnego w pierwszym wierszu wszystkich późniejszych plików w tej samej kompilacji.
// pragma_warning.cs
using System;
#pragma warning disable 414, CS3021
[CLSCompliant(false)]
public class C
{
int i = 1;
static void Main()
{
}
}
#pragma warning restore CS3021
[CLSCompliant(false)] // CS3021
public class D
{
int i = 1;
public static void F()
{
}
}
Inna forma warning pragma wyłącza lub przywraca polecenia formatowania programu Visual Studio w blokach kodu:
#pragma warning disable format
#pragma warning restore format
Polecenia formatu programu Visual Studio nie modyfikują tekstu w blokach kodu, w których działa disable format. Polecenia formatowania, takie jak Ctrl+Ki Ctrl+D, nie modyfikują tych regionów kodu. Ta pragma zapewnia precyzyjną kontrolę nad wizualną prezentacją kodu.
suma kontrolna #pragma
Generuje sumy kontrolne dla plików źródłowych, aby ułatwić debugowanie ASP.NET stron.
#pragma checksum "filename" "{guid}" "checksum bytes"
Gdzie "filename" jest nazwą pliku, który wymaga monitorowania zmian lub aktualizacji, "{guid}" jest globalnie unikatowy identyfikator (GUID) algorytmu skrótu i "checksum_bytes" jest ciągiem cyfr szesnastkowych reprezentujących bajty sumy kontrolnej. Musi być parzystą liczbą cyfr szesnastkowej. Liczba nieparzysta cyfr powoduje wyświetlenie ostrzeżenia w czasie kompilacji, a dyrektywa jest ignorowana.
Debuger programu Visual Studio używa sumy kontrolnej, aby upewnić się, że zawsze znajduje odpowiednie źródło. Kompilator oblicza sumę kontrolną dla pliku źródłowego, a następnie emituje dane wyjściowe do pliku bazy danych programu (PDB). Debuger następnie używa pdB do porównania z sumą kontrolną, którą oblicza dla pliku źródłowego.
To rozwiązanie nie działa w przypadku projektów ASP.NET, ponieważ obliczona suma kontrolna dotyczy wygenerowanego pliku źródłowego, a nie pliku .aspx. Aby rozwiązać ten problem, #pragma checksum zapewnia obsługę sumy kontrolnej dla stron ASP.NET.
Podczas tworzenia projektu ASP.NET w języku Visual C# wygenerowany plik źródłowy zawiera sumę kontrolną dla pliku .aspx, z którego jest generowane źródło. Kompilator zapisuje te informacje w pliku PDB.
Jeśli kompilator nie znajdzie dyrektywy w pliku, oblicza sumę kontrolną #pragma checksum i zapisuje wartość w pliku PDB.
class TestClass
{
static int Main()
{
#pragma checksum "file.cs" "{406EA660-64CF-4C82-B6F0-42D48172A799}" "ab007f1d23d9" // New checksum
}
}