Kuinka hallita ja kehittää .NET-sovelluksia: Parhaat käytännöt ja menetelmät

.NET-sovellusten kehittäminen tarjoaa monia mahdollisuuksia ja haasteita, erityisesti kun käsitellään monimutkaisempia asioita, kuten datan hallintaa, tietoturvaa ja sovelluksen optimointia. Yksi keskeisistä osa-alueista on sovelluksen ja sen osien tehokas hallinta, riippumatta siitä, käsitelläänkö pientä työpöytäsovellusta vai suurta pilvipohjaista alustaa. Tässä yhteydessä käsitellään tärkeitä käsitteitä, kuten tietokannan hallinta, salausmenetelmät, ja käyttöliittymien dynaaminen lataaminen, jotka ovat olennaisia osia .NET-ympäristössä.

Tietokannan hallinta on keskeinen osa suurten sovellusten kehittämistä. .NET tarjoaa erinomaisia työkaluja, kuten Entity Framework Core (EF Core), joka mahdollistaa tehokkaan tiedon hallinnan. EF Core:n avulla voidaan helposti määritellä tietomalleja, hallita niiden päivityksiä ja tehdä kyselyitä SQL-tietokannoissa. Sen tarjoamat konventiot ja Fluent API -lähestymistapa mahdollistavat myös monimutkaisempien tietomallien ja perintöhierarkioiden luomisen. Tämän lisäksi EF Core tukee useita strategioita, kuten tauluperhieraarkian (TPH) ja tauluper-tyypin (TPT) käytön, joita voidaan soveltaa erilaisten liiketoimintalogiikoiden mukaisesti.

Sovellusten tietoturva on toinen olennainen osa-alue. Tämä kattaa sekä tietojen salauksen että sen, kuinka tieto suojataan salasanan tai muilla todennustavoilla. Esimerkiksi JSON Web Token (JWT) -autentikointi on yleinen tapa varmistaa käyttäjän tunnistautuminen sovelluksissa. JWT tarjoaa turvallisen ja kevyen tavan käsitellä käyttäjäistuntoja, ja sen avulla voidaan varmistaa, että vain valtuutetut käyttäjät pääsevät käsiksi arkaluontoisiin tietoihin. Salauksen osalta on tärkeää ymmärtää, kuinka varmistetaan avainten ja salausalgoritmien turvallisuus, sekä kuinka käytetään salauksen eri menetelmiä kuten elliptinen kaarisalaus (ECDSA).

Tietoturvaan liittyen, salaus ja salaustekniikat, kuten AES (Advanced Encryption Standard) ja elliptiset kaarit, ovat keskeisiä, kun käsitellään arkaluontoisia tietoja kuten käyttäjätunnuksia, maksutietoja ja muita luottamuksellisia tietoja. Tietojen salaaminen ja salaustekniikoiden implementointi oikein on avainasemassa, jotta sovellus ei altistu hyökkäyksille, kuten DDoS- tai DoS-hyökkäyksille, jotka voivat lamauttaa palvelun. Tähän liittyen, palvelimen rajoittaminen pyynnöille ja dynaaminen virheenkäsittely ovat tärkeitä keinoja suojautua tällaisia hyökkäyksiä vastaan.

Kun puhutaan ohjelmistokehityksestä, erityisesti dynaamisista käyttöliittymistä, ei voida unohtaa myöskään modernien web-teknologioiden hyödyntämistä. Dynaaminen HTML (DHTML) tarjoaa mahdollisuuden luoda interaktiivisia ja reaktiivisia käyttöliittymiä ilman, että koko sivu tarvitsee ladata uudelleen. Tämä parantaa käyttäjäkokemusta, erityisesti silloin, kun käyttäjäinteraktiot, kuten lomakkeet tai tiedon syöttäminen, vaativat välitöntä päivitystä.

Erityisesti pilvipohjaisissa sovelluksissa tulee ottaa huomioon myös tehokas tiedonvälimuisti. .NET Core tarjoaa työkaluja, kuten hajautetut välimuistit ja välimuistin hallinta Azure-pilvessä, mikä parantaa sovelluksen suorituskykyä ja reagointikykyä. Samalla on tärkeää ymmärtää, että suuri määrä samanaikaisia käyttäjiä voi vaikuttaa sovelluksen suoritukseen, mikä tekee optimoinnista ja kuormituksen hallinnasta kriittistä. Tämä tarkoittaa sitä, että sovelluksia tulee suunnitella ja testata skaalautuviksi, jotta ne pystyvät käsittelemään suuria käyttäjämääriä ilman, että suorituskyky kärsii.

Kaikkia näitä asioita yhdistää se, että onnistunut sovelluskehitys vaatii syvällistä ymmärrystä alustan tarjoamista työkaluista, mutta myös oikeanlaisten turvallisuuskäytäntöjen ja optimointitekniikoiden soveltamista. Kun ymmärretään ja hyödynnetään oikein .NETin tarjoamia kehyksiä, kuten Entity Frameworkia, .NET MAUI:ta ja GraphQL:ää, voidaan luoda kestäviä, tehokkaita ja turvallisia sovelluksia.

Miten dynaamisesti ladataan kokoelma ja suoritetaan menetelmiä .NET:ssä?

Esimerkkinä tarkastellaan seuraavaa tilannetta. Kuvitellaan, että sinulla on luokka Animal.cs, jossa on metodi Speak. Kun haluat korvata vanhan metodin uudella, voit käyttää [Obsolete]-attribuuttia, joka varoittaa vanhentuneen koodin käytöstä ja ohjaa sen tilalle uuteen SpeakBetter-metodiin:

csharp
Copy code
[Coder("Mark Price", "22 August 2022")]

[Coder("Johnni Rasmussen", "13 September 2022")]
[Obsolete($"use {nameof(SpeakBetter)} instead.")]
public void Speak()
{
    WriteLine("Woof...");
}
public void SpeakBetter()
{
    WriteLine("Wooooooooof...");
}

Tämä merkitsee sen, että jos ohjelma kutsuu vanhentunutta Speak()-metodia, se saa tiedon siitä, että on suositeltavaa käyttää SpeakBetter-metodia. Tämän lisäksi ohjelma voi myös tarkistaa koodin jäsenet ja raportoitavat vanhentuneet metodit käyttämällä reflektiota:

csharp
Copy code
foreach (MemberInfo member in members)

{
    ObsoleteAttribute? obsolete = member.GetCustomAttribute<ObsoleteAttribute>();
    WriteLine("{0}: {1} ({2}) {3}",
        member.MemberType, member.Name, 
        member.DeclaringType?.Name, 
        obsolete is null ? "" : $"Obsolete! {obsolete.Message}");
}

Tämän koodin avulla voidaan dynaamisesti tarkastella ohjelman jäseniä ja ilmoittaa käyttäjälle, jos he käyttävät vanhentuneita metodeja.

Toinen tärkeä tekijä on dynaaminen kokoonpanojen lataaminen ajon aikana. Normaalisti, kun .NET-projekti tarvitsee käyttää toista kokoonpanoa, se lisätään projektiin ja käännetään, jolloin kääntäjä tietää, mitkä kokoonpanot ladataan muistissa ohjelman käynnistyessä. Kuitenkin on tilanteita, joissa kokoonpanon lataaminen voi tapahtua vasta ajon aikana, mikä on erityisen hyödyllistä, kun ohjelmalla on laajennettavissa olevia ominaisuuksia, kuten liitännäisiä.

Otetaan esimerkiksi ohjelma, joka tukee liitännäisten lataamista dynaamisesti. Tässä tapauksessa ohjelma voi ladata kokoonpanon muistissa vain, kun liitännäinen aktivoidaan. Tämä vähentää muistinkäyttöä ja parantaa ohjelman tehokkuutta.

Seuraavaksi tarkastellaan esimerkkiä, jossa luodaan dynaaminen kokoonpano ja suoritetaan siihen liittyvät metodit:

1. Luo uusi Class Library -projekti nimeltä DynamicLoadAndExecute.Library.

2. Lisää projektiin koodeja, jotka määrittelevät luokan Dog ja sen Speak-metodin, joka kirjoittaa konsoliin viestin, joka sisältää parametrina annetun koiran nimen.

3. Luo uusi konsoli-sovellusprojekti nimeltä DynamicLoadAndExecute.Console, jossa käytetään reflektiota ja dynaamista lataamista.

Esimerkiksi, seuraavassa esimerkissä luodaan ja ladataan kokoonpano ajon aikana:

csharp
Copy code
Assembly? thisAssembly = Assembly.GetEntryAssembly();
if (thisAssembly is null)
{
    WriteLine("Could not get the entry assembly.");
    return;
}
OutputAssemblyInfo(thisAssembly);
WriteLine("Creating load context for:\n  {0}\n", Path.GetFileName(thisAssembly.Location));
DemoAssemblyLoadContext loadContext = new(thisAssembly.Location);

string assemblyPath = Path.Combine(Path.GetDirectoryName(thisAssembly.Location) ?? "", "DynamicLoadAndExecute.Library.dll");

WriteLine("Loading:\n  {0}\n", Path.GetFileName(assemblyPath));
Assembly dogAssembly = loadContext.LoadFromAssemblyPath(assemblyPath);
OutputAssemblyInfo(dogAssembly);

Tässä koodissa käytämme DemoAssemblyLoadContext-luokkaa, joka lataa kokoonpanon ajon aikana. Kun kokoonpano on ladattu, se luo dynaamisesti Dog-luokan instanssin ja kutsuu sen Speak-metodia:

csharp
Copy code
Type? dogType = dogAssembly.GetType("DynamicLoadAndExecute.Library.Dog");
if (dogType is null)
{
    WriteLine("Could not get the Dog type.");
    return;
}
MethodInfo? method = dogType.GetMethod("Speak");
if (method != null)
{
    object? dog = Activator.CreateInstance(dogType);
    for (int i = 0; i < 10; i++)
    {
        method.Invoke(dog, new object[] { "Fido" });
    }
}

Tässä vaiheessa voimme suorittaa metodin ja dynaamisesti luoda ja käyttää koiraobjektia ilman, että tarvitsemme suoraa riippuvuutta kokoonpanosta ennakkoon.

Tämän lähestymistavan etuna on se, että se mahdollistaa ohjelman muistinkäytön optimoinnin ja joustavan laajennettavuuden. Lisäksi, kuten mainittiin, .NET 7 tuo merkittäviä parannuksia reflektiivisten operaatioiden suorituskyvyn suhteen, jolloin dynaaminen koodin suorittaminen on entistä nopeampaa ja tehokkaampaa. Tällaiset tekniikat tekevät mahdolliseksi kehittää laajennettavia sovelluksia, joissa lisätoiminnot voidaan ladata ja suorittaa vain tarvittaessa.

Mikä aiheuttaa CORS-virheitä ja miten niitä voidaan ratkaista web-sovelluksissa?

Web-sovellusten kehittäminen ja integrointi eri palveluiden välillä on monivaiheinen prosessi, jossa haasteet eivät ole harvinaisia. Yksi yleisimmistä ongelmista, johon kehittäjät törmäävät, on niin sanottu CORS (Cross-Origin Resource Sharing) -virhe, joka voi estää resurssien käytön toiselta palvelimelta. Tämä virhe ilmenee erityisesti silloin, kun selain yrittää käyttää resurssia toiselta palvelimelta eri portissa tai eri alkuperässä kuin se, josta se on ladattu. Seuraavassa käsitellään tilannetta, jossa CORS-virhe esiintyy JavaScript-asiakasohjelmassa, joka yrittää käyttää REST API:ta.

Esimerkki liittyy web-sovellukseen, joka on rakennettu ASP.NET Core -alustalla. Sovelluksessa käytetään kahta eri porttia: yksi web-palvelimen puolella ja toinen, jossa JavaScript-asiakasohjelma tekee pyyntöjä. Kun asiakasohjelma yrittää tehdä HTTP GET -pyynnön toiseen porttiin (jossa API on, esimerkiksi localhost:5091), selain estää pyynnön ja ilmoittaa CORS-virheestä, koska alkuperä (origin) on eri kuin API:n palvelimen alkuperä. Tällöin selain ei salli resurssien jakamista näiden kahden eri alkuperän välillä.

Virheen ilmeneminen on merkki siitä, että selain havaitsee kaksi ongelmaa: eri alkuperät ja puuttuvan CORS-päätteen. Esimerkiksi seuraava virheilmoitus voi ilmetä:

Access to XMLHttpRequest at 'https://localhost:5091/api/products/man' from origin 'https://localhost:5092' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Tämä virhe johtuu siitä, että palvelin, joka toimii portissa 5091, ei ole määritellyt CORS-otsikkoa salliakseen pyynnöt eri alkuperästä (localhost:5092). Tällöin selain hylkää pyynnön ennen kuin se ehtii edes lähteä palvelimelle.

Ratkaisu CORS-virheeseen

CORS-virheen ratkaisemiseksi palvelimen puolelle täytyy lisätä tuki CORS-pyyntöjen käsittelylle. ASP.NET Core -alustalla tämä voidaan tehdä helposti määrittelemällä CORS-palvelu ja lisäämällä se middleware-ketjuun. Esimerkiksi seuraavat vaiheet voivat auttaa:

1. CORS-palvelun määrittäminen palvelinpuolella: ASP.NET Core -projektissa tulee lisätä CORS-middleware, joka sallii pyynnöt määritellyistä alkuperistä. Tämä voidaan määrittää Startup.cs-tiedostossa tai Program.cs-tiedostossa:

csharp
Copy code
public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(options =>
    {
        options.AddPolicy("AllowSpecificOrigin", builder =>
        {
            builder.WithOrigins("https://localhost:5092")  // Hyväksytään pyyntöjä localhost:5092:sta
                   .AllowAnyMethod()
                   .AllowAnyHeader();
        });
    });
}

2. Middleware-lisäys: Palvelimen konfiguraatiossa täytyy lisätä CORS-middleware, joka käsittelee pyyntöjen alkuperän tarkistuksen.

csharp
Copy code
public void Configure(IApplicationBuilder app)

{
    app.UseCors("AllowSpecificOrigin");  // Lisää CORS-tuki ennen muita middleware-komentoja
    app.UseRouting();
}

Tämän jälkeen palvelin sallii pyynnöt määritellyistä alkuperistä ja poistaa CORS-virheen. On kuitenkin tärkeää huomata, että jos alkuperä ei ole määritelty tai on määritelty väärin, pyyntöjä ei sallita.

JavaScript-asiakasohjelman virheilmoitusten tarkastelu

Kehittäjälle on tärkeää ymmärtää, että vaikka palvelin palauttaisi pyynnön ja datan (esimerkiksi JSON-objektin), selain ei palauta tietoja JavaScriptille, jos CORS-ongelma estää sen. Tässä tapauksessa palvelin voi jopa suoritettavan kyselyn ja palauttaa tietoja, mutta koska CORS-otsikkoa ei ole lisätty, selain estää JavaScriptin pääsyn näihin tietoihin. Tämä korostaa selain- ja palvelinpuolen yhteistyön merkitystä ja sitä, kuinka virheitä voi ilmetä ilman oikeaa kokoonpanoa.

Miksi tämä on tärkeää

On välttämätöntä, että kehittäjä ymmärtää CORS-virheiden taustalla olevan turvallisuusriskin ja oikean tavan käsitellä niitä. Virheiden ilmeneminen ei tarkoita pelkästään sitä, että jotain on mennyt pieleen, vaan se voi olla merkki laajemmasta infrastruktuuriongelmasta, joka vaikuttaa siihen, miten tiedot jaetaan ja suojataan web-sovelluksessa. Tämä on erityisen tärkeää, jos sovelluksia kehitetään ja otetaan käyttöön eri ympäristöissä, joissa voi olla eroja CORS-määrityksissä.

Kun CORS-konfiguraatiot tehdään oikein, käyttäjät voivat olla varmoja, että heidän tietonsa ovat turvassa, ja että sovellukset voivat kommunikoida turvallisesti muiden palveluiden kanssa.

Miten hallita ja suojata web-palveluita ASP.NET Corella: Rate limiting -toiminto

ASP.NET Core 7:ssä esitelty rate limiting -toiminto mahdollistaa API-pyyntöjen rajoittamisen, mikä suojaa palveluita liiallisilta pyyntömääriltä ja parantaa palvelun käytettävyyttä. Yksi keskeisistä tekijöistä tässä prosessissa on pyyntöjen määrän hallinta eri asiakkaille ja se, miten palvelu reagoi, kun asiakas ylittää rajoitetun määrän pyyntöjä tietyn ajan sisällä.

Rate limiting -mekanismilla voidaan määrittää kuinka monta pyyntöä asiakas voi tehdä tietyn aikarajan sisällä, esimerkiksi kaksi pyyntöä kymmenessä sekunnissa. Tämä voi estää palvelun ylikuormittumisen ja varmistaa, että palvelu on käytettävissä myös muille asiakkaille.

Esimerkki koodista ja käytöstä

Tässä esitetään esimerkki koodista, jossa asiakas tekee pyyntöjä API-palveluun. Asiakkaan pyyntöihin liittyy X-Client-Id -otsikko, joka yksilöi asiakkaan ja mahdollistaa sen, että rajoituksia voidaan asettaa asiakaskohtaisesti.

csharp
Copy code
client.DefaultRequestHeaders.Accept.Add(new("application/json")); 
client.DefaultRequestHeaders.Add("X-Client-Id", clientName);
ConsoleColor previousColor;
while (true) {
    previousColor = ForegroundColor;
    ForegroundColor = ConsoleColor.DarkGreen;
    Write("{0:hh:mm:ss}: ", DateTime.UtcNow);
    ForegroundColor = previousColor;
    int waitFor = 1; // sekuntia
    try {
        HttpResponseMessage response = await client.GetAsync("api/products");
        if (response.IsSuccessStatusCode) {
            Product[]? products = await response.Content.ReadFromJsonAsync<Product[]>();
            if (products != null) {
                foreach (Product product in products) {
                    Write(product.ProductName);
                    Write(", ");
                }
                WriteLine();
            }
        } else {
            previousColor = ForegroundColor;
            ForegroundColor = ConsoleColor.DarkRed;

            WriteLine($"{(int)response.StatusCode}: {await response.Content.ReadAsStringAsync()}");

            ForegroundColor = previousColor;
        }
    } catch (Exception ex) {
        WriteLine(ex.Message);
    }
    await Task.Delay(TimeSpan.FromSeconds(waitFor));
}

Tässä koodissa pyydetään tuotteita API:sta, mutta jos asiakas ylittää sallitun pyynnön määrän, hän saa 429-virhekoodin ja palvelu antaa ohjeen odottaa ennen seuraavaa pyyntöä.

Suorituskyvyn optimointi ja asiakaskohtaiset rajoitukset

ASP.NET Core tarjoaa myös mahdollisuuden määritellä rajoituksia asiakaskohtaisesti, ja se tukee monenlaista ratkaisua eri käyttötarkoituksiin. Esimerkiksi, jos asiakas ylittää sallitun määrän pyyntöjä, palvelu voi ilmoittaa asiakkaalle, kuinka monta sekuntia hänen tulee odottaa ennen uuden pyynnön lähettämistä. Tämä voidaan tehdä lukemalla HTTP-otsikko "Retry-After" vastauksesta ja säätämällä asiakaspalvelua odottamaan määritelty aikaraja ennen seuraavaa pyyntöä.

Tässä koodiesimerkissä lisätään odotusajan käsittely:

csharp
Copy code
string retryAfter = response.Headers.GetValues("Retry-After").ToArray()[0];
if (int.TryParse(retryAfter, out waitFor)) {
    WriteLine($"Retry after {waitFor} seconds.");
}

Tämä koodi mahdollistaa sen, että asiakas ei yritä lähettää pyyntöjä liian nopeasti, ja se noudattaa palvelun ehdottamaa odotusaikaa ennen uuden pyynnön tekemistä.

Erityistapaukset ja joustavuus

HTTP-virheiden ja lokitietojen tarkastelu

Kun rate limiting -toiminto aktivoituu ja asiakas ylittää rajan, palvelu palauttaa virheen. Tämä virhe kirjataan palvelun lokitietoihin, ja se voi näyttää esimerkiksi seuraavanlaisen merkinnän:

vbnet
Copy code
info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[1] Request: 
Protocol: HTTP/1.1 Method: GET Path: /api/products X-Client-Id: console-client-d54c61ba-66bb-4e39-9c1a-7af6e2bf647e 

info: AspNetCoreRateLimit.ClientRateLimitMiddleware[0] Request get:/api/products from ClientId console-client-d54c61ba-66bb-4e39-9c1a-7af6e2bf647e has been blocked, quota 2/10s exceeded by 3.

Blocked by rule *, TraceIdentifier 0HMIKGNJQEK5P:0000000E. MonitorMode: False

info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[2] Response: StatusCode: 429 Retry-After: 6

Tässä lokimerkinnässä näkyy, että asiakas on ylittänyt sallitun määrän pyyntöjä ja palvelu on estänyt lisäpyynnöt. Lokitiedot antavat myös tarkempia tietoja siitä, kuinka kauan asiakkaan on odotettava ennen seuraavaa pyyntöä.

Rate limitingin tärkeys ja hyödyt

Rate limitingin tärkein etu on se, että se suojaa palveluja ja varmistaa niiden skaalautuvuuden. Ilman tällaisia rajoituksia yksittäiset käyttäjät tai skriptit voisivat ylikuormittaa palvelun, jolloin se ei olisi käytettävissä muille asiakkaille. Lisäksi se mahdollistaa palvelun suorituskyvyn hallinnan, mikä on erityisen tärkeää monimutkaisissa tai kuormitetuissa ympäristöissä.

Ymmärtämällä rate limitingin perusperiaatteet ja sen käyttöönoton mahdollisuudet, voidaan huomattavasti parantaa web-palveluiden turvallisuutta ja käytettävyyttä.

Miksi projektien oikea rakenne ja nimeäminen on tärkeää .NET:ssä?

Yksi tärkeä syy projektille rakenteen ja nimien suunnitteluun on helpottaa komponenttien etsimistä ja ylläpitoa. Hyvin valittu rakenne ja selkeät nimeämiskäytännöt tekevät kehittäjien työstä sujuvampaa, erityisesti silloin, kun työskennellään tiimissä. Oikeanlaisen nimeämiskäytännön avulla kehittäjä voi heti tunnistaa, mitä kukin projekti tekee, ilman että täytyy perehtyä syvällisesti sen koodiin.

Projektien nimeämiseen ja rakenteen suunnitteluun ei ole olemassa yhtä oikeaa tapaa, mutta yksi tehokas menetelmä on käyttää hakemistorakennetta ja nimeämiskäytäntöjä. Jos työskentelet tiimissä, on tärkeää tietää, kuinka tiimisi on määrittänyt rakenteet ja nimet. Hyvin jäsennelty projekti auttaa paitsi koodin ymmärtämisessä myös sen laajentamisessa ja ylläpidossa.

Yksi suosituimmista tavoista nimeämiseen on projektityypin käyttäminen nimen osana. Esimerkiksi, jos kyseessä on luokkakirjasto, konsolisovellus tai verkkosivusto, projektin nimi voi sisältää tämän tiedon. Esimerkkinä käytämme seuraavia nimityksiä:

• Northwind.Common: Luokkakirjasto, joka sisältää yleisiä tyyppejä, kuten rajapintoja, luokkia ja tietorakenteita, joita käytetään useissa projekteissa.

• Northwind.Common.EntityModels: Yhteinen EF Core -entiteettimallien projekti, joka voi olla käytössä sekä palvelin- että asiakaspuolella.

• Northwind.Mvc: ASP.NET Core -projekti, joka hyödyntää MVC-mallia ja mahdollistaa yksikkötestauksen.

• Northwind.WebApi.Service: ASP.NET Core -projekti HTTP API -palvelulle, joka on helppo integroida JavaScript-kirjastojen tai Blazor-sovellusten kanssa.

• Northwind.gRPC.Service: gRPC-palvelun projekti, joka hyödyntää ASP.NET Core -teknologiaa.

Näiden lisäksi on tärkeää varmistaa, että käytetyt porttinumeroiden asetukset eivät mene päällekkäin, erityisesti jos käynnistetään useita projekteja samanaikaisesti. Yksi yleisesti käytetty käytäntö on käyttää porttinumeroita seuraavassa muodossa:

• https://localhost:5[chapter number]1/

• http://localhost:5[chapter number]2/

Vihjeenä on myös, että kääntäjähälytyksiä ei tule jättää huomiotta. Ne voivat aluksi vaikuttaa vähäpätöisiltä, mutta ne osoittavat mahdollisia ongelmia koodissa, jotka voivat vaikuttaa ohjelman vakauteen ja laajennettavuuteen. Jos jätämme ne huomiotta, kehityskäytännöistä tulee huonoja ja ohjelma voi olla altis virheille. .NET tarjoaa asetuksia, joilla voidaan käsitellä hälytykset virheinä, pakottaen näin kehittäjän ratkaisemaan ne ennen ohjelman kääntämistä.

Mikäli ohjelmassa tulee eteen varoitus, kuten tyyppinimien kirjoittaminen pienillä kirjaimilla (esimerkiksi "person" luokan määrittely), on tärkeää olla tarkkana, sillä tämä voi aiheuttaa yhteensopivuusongelmia tulevissa C#-versioissa. Tulevaisuudessa C# saattaa lisätä varattuja avainsanoja, jotka saattavat olla ristiriidassa nykyisten tyyppien nimien kanssa, mikä voi johtaa käännösvirheisiin.

Ohjelmoijan hyvä käytäntö on aina käsitellä varoitukset virheinä. Tämä ei ainoastaan paranna koodin laatua, mutta se estää myös mahdollisia ongelmia, joita voi ilmetä laajemmassa kehitystyössä.

.NET tarjoaa laajan valikoiman työkaluja sovellusten ja palvelujen rakentamiseen. ASP.NET Core on yksi tärkeimmistä teknologioista verkkosivustojen ja sovellusten kehittämisessä. ASP.NET Core mahdollistaa verkkosivujen dynaamisen luomisen ja käsittelee URL-osoitteiden kautta saapuvia pyyntöjä (GET, POST, PUT, DELETE). ASP.NET Core:n tarjoamat Razor Pages- ja MVC-mallit auttavat rakentamaan sekä yksinkertaisia että monimutkaisempia verkkosivustoja ja sovelluksia, joissa suuri osa käsittelystä tapahtuu palvelimella.