Módulos, paquetes e importación en C# (.NET): guía detallada

Here is the translated HTML article in English:

What is it and why? (a real-life analogy)

Imagine you are assembling a huge LEGO set. You have a box with thousands of pieces. If all the pieces were thrown into one pile, you would spend hours trying to find the right red 2×4 brick. Now imagine the pieces are sorted into bags: one has wheels, another has windows, a third has minifigures. Assembling the model becomes much easier!

The same thing happens in programming. When a program becomes large (for example, 10,000 lines of code), storing everything in one file is a disaster. You will get confused, it will be hard to find bugs, and if a team of 5 people is working on the project, they will constantly interfere with each other.

Modules are like individual bags of LEGO pieces. Each module is responsible for its own task. For example, one module can work with a database, another can draw buttons on the screen, and a third can send emails.

Packages are boxes that contain several related modules. For example, a "Graphics" package might contain modules: "Line Drawing", "Color Fill", "Text Handling".

Import is when you take a ready-made module or package and use it in your program. It's like going to the kitchen, taking a package of pasta (importing it), cooking it, and adding it to your cutlet.

Important: In C#, modules are called namespaces, and packages are called assemblies. But for simplicity, we will use the terms "module" and "package", as they are universal across all programming languages.

Why is this needed? Imagine you are writing a game. You will need:

• A module for working with graphics (drawing characters)
• A module for physics (gravity, collisions)
• A module for sound (music, gunshots)
• A module for saving the game

If you write everything in one file, you'll get a 5000-line "mess". But if you split it into modules, each file will be 200-300 lines, easy to read, fix, and reuse in other projects.

Theory: how it works under the hood

Let's look "under the hood" of C# and see how modules and imports work at the .NET level.

Namespaces

Imagine you have two friends: one lives on Lenin Street, building 5, and the other on Lenin Street, building 10. If you just say "Lenin Street", it's unclear who to visit. You need the full address: "Lenin Street, building 5, apartment 12".

In C#, a namespace is like a last name or address for your classes and methods. It helps distinguish identical names in different parts of the program.

For example, in C# there is a class Console. But what if you want to create a class named Console yourself? Without a namespace, a conflict will arise — the compiler won't understand which Console you mean. With a namespace, it's simple: System.Console is the built-in class, and MyGame.Console is your own.

Assemblies

When you compile (translate) your C# code into machine code, you get a file with the extension .exe (executable) or .dll (library). This file is called an assembly.

An assembly is like a packaged box of LEGO pieces. Inside it, there can be dozens of classes, interfaces, and other elements, grouped into namespaces.

When you connect an external library (for example, for working with Excel), you add a reference to its assembly (.dll file) to your project. After that, you can import its namespaces and use the ready-made classes.

How import works

When you write using System; at the beginning of a file, you are telling the compiler: "Hey, I'm going to use classes from the System namespace. If I write Console, you should understand that this is System.Console."

Without using, you would have to write the full name every time: System.Console.WriteLine("Hello!");. With using, you can simply write: Console.WriteLine("Hello!");.

Important: The using directive only works within a single file. If you have 10 files, and each one needs System, you'll have to write using System; in each of them. This is normal — it keeps the code clear and independent.

Namespace hierarchy

Namespaces can be nested, like folders on a computer:

// Example of nested namespaces
namespace MyGame
{
    namespace Graphics
    {
        class Screen
        {
            // ...
        }
    }
    
    namespace Physics
    {
        class Gravity
        {
            // ...
        }
    }
}

To access the Screen class from another file, you need to write MyGame.Graphics.Screen. Or add using MyGame.Graphics; and just use Screen.

Syntax in C# (.NET): all forms and variants

Let's break down all the ways to work with modules and imports in C#. It's like a Swiss Army knife — each tool has its own purpose.

1. The using directive — basic import

The most common form. Added at the beginning of the file:

using System;                    // Import of the base namespace
using System.Collections.Generic; // Import for working with lists
using System.Linq;               // Import for working with collections (LINQ)

2. Import with an alias

If the namespace name is too long, or if there is a name conflict, you can give it a short name:

using MyAlias = System.Collections.Generic;