C# y .NET desde cero para principiantes

C# es el lenguaje, .NET es la plataforma

La confusión más habitual de quien empieza con C# es tratar a C# y a .NET como si fueran sinónimos, o directamente el mismo producto con dos nombres. No lo son, y entender la diferencia desde el primer día evita malentendidos más adelante, sobre todo al leer documentación o tutoriales de distintas épocas.

C# (se pronuncia «C sharp») es un lenguaje de programación de propósito general, orientado a objetos y de tipado estático —es decir, el tipo de cada dato se fija y se verifica antes de ejecutar el programa—, creado por Microsoft. Es lo que vos escribís: la sintaxis, las clases, las variables, las condiciones, los bucles. .NET, en cambio, es la plataforma que ejecuta ese código: un entorno formado por un runtime (el programa que corre por debajo mientras tu aplicación funciona) llamado CLR (Common Language Runtime), y una gran biblioteca de clases base o BCL (Base Class Library), con funcionalidad ya resuelta para trabajar con archivos, colecciones, texto, fechas o conexiones de red, entre muchísimas otras cosas.

.NET Framework y .NET moderno: qué cambió

La palabra «.NET» aparece pegada a varios nombres distintos según la época del material que estés leyendo, y ahí aparece la segunda fuente de confusión. .NET Framework fue la implementación original de la plataforma, publicada en 2002: funcionaba solo en Windows, quedaba ligada a la versión del sistema operativo, y durante casi quince años fue prácticamente el único significado posible de «desarrollar en .NET». Hoy está en modo mantenimiento: su última versión es la 4.8.1 y no se planean versiones mayores nuevas.

En 2016 Microsoft presentó .NET Core, una reimplementación pensada desde cero para ser multiplataforma y de código abierto. En 2020, a partir de la versión que hubiera sido «.NET Core 4», Microsoft decidió unificar el nombre y lanzarla como «.NET 5», sacando la palabra «Core» y saltando deliberadamente el número 4 para que nadie la confundiera con las versiones 4.x de .NET Framework. Desde entonces la numeración es simple y continua: .NET 6, 7, 8, 9 y, al momento de escribir esta guía, .NET 10.

Lo importante para quien empieza hoy es esto: el .NET moderno (5 en adelante) corre igual en Windows, Linux y macOS. Podés escribir, compilar y ejecutar una aplicación de C# en cualquiera de los tres sistemas, con Visual Studio en Windows o con Visual Studio Code y la terminal en cualquiera de las tres plataformas. Esto es un cambio real frente a la fama que todavía arrastra C# en parte de la comunidad hispanohablante, donde se lo sigue asociando casi exclusivamente a Windows y a Visual Studio. Vale la pena decirlo de forma explícita: el material que hoy circula en el foro de Underc0de sobre C# —incluido un curso de terceros pensado para Visual Studio 2012, hoy desactualizado por la versión— está orientado a ese C# clásico sobre Windows, y no hay todavía ningún hilo dedicado a la CLI de dotnet ni al .NET moderno multiplataforma. Esta guía llena justamente ese hueco.

LTS y STS: qué versión instalar

Microsoft publica una versión nueva de .NET todos los años, en noviembre, y alterna el tipo de soporte según el número: las versiones con número par son LTS (Long Term Support, soporte a largo plazo) y las de número impar son STS (Standard Term Support, soporte estándar, con una ventana más corta). Esta distinción no es un detalle administrativo: decide qué versión conviene instalar según el proyecto.

Un dato que conviene tener presente ahora mismo: tanto .NET 8 como .NET 9 dejan de recibir soporte el 10 de noviembre de 2026, según la política de soporte que publica Microsoft. Si estás por empezar un proyecto que vas a mantener durante un tiempo, la recomendación práctica es instalar directamente la LTS vigente —hoy, .NET 10— en lugar de una versión que va a quedar sin parches de seguridad en pocos meses.

Instalar el SDK de .NET

Lo que instalás en tu máquina se llama SDK (Software Development Kit, kit de desarrollo de software): incluye el runtime necesario para ejecutar aplicaciones, el compilador, MSBuild (el sistema que orquesta la compilación) y la CLI de dotnet, la herramienta de línea de comandos con la que vas a crear, compilar y ejecutar proyectos. No hace falta instalar el runtime por separado: el SDK ya lo incluye.

• Windows: se puede descargar el instalador oficial desde la página de descargas de .NET, o instalarlo con winget, el gestor de paquetes que trae Windows.
• Linux (Ubuntu): Microsoft documenta apt-get install dotnet-sdk-10.0 como forma de instalación desde los repositorios oficiales.
• macOS: con el instalador .pkg oficial, o mediante Homebrew.

# Ubuntu: instalación desde los repositorios oficiales
sudo apt-get update
sudo apt-get install -y dotnet-sdk-10.0

# Si el paquete no está disponible en tu versión/región, usá el script oficial
curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
bash dotnet-install.sh --channel 10.0

# En cualquier sistema, así verificás que quedó instalado
dotnet --version

Sea cual sea el sistema operativo, terminá siempre con dotnet --version: si te devuelve un número como 10.0.1xx, el SDK quedó instalado y ya podés seguir con el resto de la guía.

Tu primer «Hola, mundo» sin proyecto

Antes de crear una carpeta, un archivo de proyecto y toda la estructura habitual, conviene aprovechar una novedad de .NET 10: la posibilidad de ejecutar un único archivo .cs suelto, sin generar un proyecto ni un archivo .csproj. Es la forma más directa de confirmar que el SDK quedó bien instalado y de ver un programa de C# corriendo por primera vez, sin ceremonias.

// hola.cs
Console.WriteLine("¡Hola, mundo!");

# Ejecuta el archivo suelto, sin crear ningún proyecto
dotnet hola.cs

Con eso alcanza: el SDK compila el archivo por detrás y ejecuta el resultado en el mismo paso, mostrando ¡Hola, mundo! en la terminal. Este atajo es ideal para probar un fragmento de código, seguir un ejemplo de la documentación o confirmar una sintaxis antes de entender qué es exactamente un proyecto, que es el tema de la próxima sección.

Crear y ejecutar un proyecto real

Un archivo suelto sirve para probar, pero cualquier aplicación real —con más de un archivo, con dependencias externas, con configuración propia— necesita un proyecto. En .NET, un proyecto es básicamente una carpeta con un archivo .csproj (un archivo XML que describe cómo compilar ese código) y el código fuente en archivos .cs.

1. Crear el proyectodotnet new console -o MiPrimeraApp genera una carpeta llamada MiPrimeraApp con un archivo MiPrimeraApp.csproj y un Program.cs con el clásico «Hola, mundo» ya escrito.
2. Entrar a la carpetacd MiPrimeraApp. A partir de acá, todos los comandos de dotnet se ejecutan dentro de esta carpeta, donde está el .csproj.
3. Ejecutarlodotnet run compila el proyecto (si hubo cambios) y lo ejecuta en un solo paso, mostrando la salida en la terminal.
4. Compilarlo sin ejecutardotnet build genera los archivos compilados en la carpeta bin/ sin correr el programa. Sirve para verificar que el código compila sin errores, o para preparar los binarios que otra herramienta va a ejecutar después.

La diferencia entre este camino y el del archivo suelto no es de lenguaje ni de sintaxis: es que acá hay una carpeta, un archivo de proyecto y, con el tiempo, la posibilidad de sumar más archivos .cs y paquetes externos. Cuando tu programa deja de ser un experimento de una línea, este es el camino que vas a necesitar.

Qué hace cada comando de la CLI

La CLI (interfaz de línea de comandos) de dotnet es la herramienta central para trabajar con .NET desde la terminal, la uses con Visual Studio Code, con otro editor o directamente sin editor. Estos son los comandos que ya usaste en esta guía, reunidos en una tabla de referencia rápida.

Un matiz que conviene recordar: dotnet run vuelve a compilar solo si detecta cambios desde la última compilación, así que ejecutarlo repetidas veces sin haber modificado nada no vuelve a compilar todo desde cero. Y dotnet build no borra ni reemplaza lo que genera dotnet run: son la misma compilación vista desde dos comandos distintos, uno que además ejecuta el resultado y otro que se queda solo con generarlo.

Tu primer programa, línea por línea

Cuando corrés dotnet new console, el archivo Program.cs que se genera hoy es mucho más corto de lo que era hace algunos años, y eso suele desconcertar a quien aprendió con tutoriales viejos (incluidos varios que circulan en el foro, pensados para versiones anteriores de C# y de Visual Studio). El contenido generado es, esencialmente, esta única línea:

// Program.cs
Console.WriteLine("Hello, World!");

Esto funciona gracias a las instrucciones de nivel superior (top-level statements), una característica del lenguaje C# que le permite al compilador generar automáticamente, por detrás, el punto de entrada del programa: una clase llamada Program con un método Main, que es tradicionalmente el primer código que se ejecuta en cualquier aplicación de C#. También por eso no hace falta escribir using System; al principio: el archivo de proyecto (.csproj) que genera dotnet new activa por defecto los usings implícitos, que agregan automáticamente las referencias más comunes, entre ellas la del espacio de nombres System, donde vive la clase Console.

Si veniste de un tutorial más antiguo, probablemente hayas visto la forma explícita equivalente, que sigue siendo perfectamente válida y compila igual:

using System;

namespace HolaMundo
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }
    }
}

Las dos versiones hacen exactamente lo mismo. La diferencia es que la primera es la que genera el SDK moderno por defecto —pensada para que el primer contacto con el lenguaje sea lo más simple posible— y la segunda es la forma explícita que vas a seguir encontrando en documentación, cursos y foros más antiguos, incluidos los de la comunidad. Entender que ambas son «lo mismo por dentro» evita la sensación de estar aprendiendo dos lenguajes distintos según qué material estés leyendo.

Errores frecuentes

• Confundir C# con .NET. Uno es el lenguaje que escribís; el otro, la plataforma que lo ejecuta. Podés cambiar de plataforma de despliegue sin cambiar de lenguaje, y viceversa.
• Creer que C# solo sirve para Windows y Visual Studio. El .NET moderno es multiplataforma: se desarrolla igual en Windows, Linux y macOS, con Visual Studio Code y la CLI.
• No distinguir LTS de STS al instalar. Instalar una versión STS para un proyecto de largo plazo significa tener que migrar antes de lo esperado.
• Crear un proyecto completo solo para probar tres líneas. Desde .NET 10, un archivo .cs suelto con dotnet archivo.cs alcanza para probar un fragmento.
• Asumir que el paquete de Linux siempre está disponible. El comando apt-get install dotnet-sdk-10.0 puede fallar según la versión o región; ahí entra el script dotnet-install.sh.
• Confundir dotnet build con dotnet run. El primero solo compila; el segundo compila (si hace falta) y además ejecuta el programa.

Preguntas frecuentes

Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 29 de julio de 2026.

Aportes de la comunidad Underc0de

1. Underc0de, foro. Curso básico introductorio de C#, por Rex, sección C# - VB.NET (8 de diciembre de 2019). Antecedente del interés de la comunidad por C#: anuncia un videocurso propio orientado a quienes se inician, sin código en el hilo. En el foro no hay, hasta la fecha de consulta, ningún hilo dedicado a la CLI de dotnet ni al .NET moderno multiplataforma; el resto del material disponible está orientado a C# clásico sobre Windows y Visual Studio.

Documentación oficial

2. Microsoft. Guía de C#. Referencia central del lenguaje.
3. Microsoft. .NET download 10.0. Instaladores oficiales del SDK por sistema operativo.
4. Microsoft. .NET support policy. Fechas de soporte de cada versión y política LTS/STS.
5. Microsoft. dotnet new (referencia de la CLI). Documentación del comando para crear proyectos.
6. Microsoft. Hello World — Tour of C#. Tutorial oficial del primer programa, incluidas las instrucciones de nivel superior.
7. Microsoft. Install .NET on Ubuntu. Instrucciones y salvedades de instalación en Linux.