Aplicații dintr-un fișier: dotnet run app.cs

Subiect din roadmap-ul C# și .NET · parte din „Introducere în C# și .NET”

În dezvoltarea profesională, executarea directă a unui singur fișier sursă prin dotnet run app.cs este adesea considerată o „scapătură” rapidă pentru prototipare sau teste rapide, dar nu reflectă structura standard a proiectelor enterprise. În practică, majoritatea aplicațiilor .NET sunt organizate în soluții (.sln) cu mai multe proiecte, iar compilatorul are nevoie de contextul complet al referințelor și al configurației. Totuși, această comandă este utilă pentru a înțelege fluxul de bază: compilare și execuție instantanee, fără pașii intermediari de creare a fișierului .csproj. Este ideală pentru scripturi mici, exerciții de sintaxă sau validarea rapidă a unor concepte izolate, economisind timp în faza de învățare.

Concepte cheie

  • Execuție fără proiect explicit: Comanda detectează automat fișierul sursă și generează un proiect temporar în memorie, eliminând necesitatea unui fișier .csproj fizic pentru scenarii simple.
  • Compilare JIT/AOT: .NET compilează codul C# în IL (Intermediate Language), iar runtime-ul (.NET Runtime) se ocupă de transformarea acestuia în cod mașină nativ la execuție.
  • Gestionarea dependențelor: Pentru biblioteci externe (nucl. System.*), nu ai nevoie de gestionari de pachete precum NuGet în acest mod simplu, deoarece doar API-ul de bază este inclus implicit.
  • Fluxul de execuție: Programul începe întotdeauna în metoda statică Main, care acționează ca punctul de intrare (entry point) al aplicației.
  • Ieșiri standard: Rezultatele afișate în consolă sunt trimise către stdout, permițând redirecționarea ușoară a ieșirii către alte procese sau fișiere în sistemul de operare.
  • Modul de debug vs. Release: Deși dotnet run pornește aplicația, comportamentul poate varia ușor în funcție de variabilele de mediu, deși pentru un singur fișier diferența este minimă.
  • Limitări de scalabilitate: Această abordare nu suportă ușor dependințe complexe, resurse embeddate sau configurări avansate de build, fiind destinată exclusiv scenarilor micro.

Exemplu practic

Să presupunem că vrei să testezi rapid o funcție de calculare a factorialului fără a crea un proiect nou. Creezi fișierul app.cs:

using System;

class Program
{
    static void Main()
    {
        int n = 5;
        Console.WriteLine($"Factorial de {n} este: {Factorial(n)}");
    }

    static long Factorial(int number)
    {
        if (number <= 1) return 1;
        return number * Factorial(number - 1);
    }
}

Rulând dotnet run app.cs în terminal, vei vedea imediat rezultatul. Acest lucru demonstrează cum codul este citit, compilat și executat secvențial, oferind feedback instantaneu asupra logicii implementate.

Greșeli frecvente

  • Confuzia cu numele clasei: Dacă fișierul se numește app.cs, clasa principală trebuie să fie Program sau să conțină un Main static accesibil public. Uneori, utilizatorii definesc clase private care nu pot fi instanțiate corect de runtime.
  • Ignorarea spațiilor de nume: Uitări de a include using System; duc la erori de compilare când se încearcă utilizarea tipurilor de bază precum Console sau String.
  • Dependențe lipsă: Încercarea de a folosi biblioteci terțe (ex: Newtonsoft.Json) direct cu această comandă va eșua, deoarece acestea nu sunt incluse în setul implicit de referințe.
  • Codul nu este salvat: Un error comun este rularea comenzii înainte de a salva modificările în editorul de text, ducând la execuția unei versiuni vechi a fișierului.

Întrebări de interviu

De ce nu ar trebui să folosești dotnet run <fisier>.cs în producție? Pentru că nu oferă control asupra versiunilor de dependințe, nu permite optimizări avansate de build și nu este scalabil pentru echipe mari sau proiecte complexe cu multiple module.

Care este diferența dintre dotnet run și dotnet build? dotnet build compilează codul și generează fișierele binare (DLL/EXE) fără a le executa, fiind util pentru verificarea erorilor de sintaxă. dotnet run face ambele lucruri: construiește și lansează aplicația imediat.

Cum gestionezi excepțiile într-un script executat direct? Deși nu ai un fișier de configurare complex, poți folosi blocuri try-catch standard în metoda Main pentru a prinde erori de runtime și a afișa mesaje clare în consolă, asigurând o ieșire curată.

Exercițiu

Creează un fișier calculator.cs care să conțină o clasă Calculator cu metode statice pentru adunare, scădere, înmulțire și împărțire. În metoda Main, apelează aceste metode cu doi operanzi introduși de la tastatură (Console.ReadLine()). Transformă inputul în numere folosind int.TryParse pentru a gestiona erorile de format. Rulă codul cu dotnet run calculator.cs și testează-l cu valori valide și invalide (ex: litere). Timp estimat: 45 minute.

Resurse gratuite

Alte subiecte din „Introducere în C# și .NET”