When you write or edit C# code, you are working with source code.
Before the application can run, Visual Studio needs to build the project. During a build, the C# compiler reads the source files, checks whether the code follows the rules it needs to understand, and produces the compiled output used by .NET.
That means these are related but different actions:
Edit the source → Build the solution → Run the application
A successful build tells you that the compiler was able to translate the current source.
It does not automatically tell you that the program behaves the way you intended.
Imagine a small soccer application that contains this code:
Player player1 = new Player();
player1.name = "Jordan";
player1.jerseyNumber = 7;
If the code follows the structure expected by the supplied project, the compiler can translate it.
Now imagine a required semicolon is accidentally removed:
Player player1 = new Player()
player1.name = "Jordan";
The intended idea may still be obvious to a person, but the compiler needs valid C# syntax.
The application cannot run normally from this source until the build problem is corrected.
This is why building is an important development step: it gives you evidence about whether the current source can be compiled.
Open the course-provided solution in Visual Studio.
Use Visual Studio's Build Solution command.
Visual Studio will process the projects that belong to the solution and report whether the build completed successfully.
At this stage, focus on two possible results.
A successful build means the compiler was able to produce the expected build output from the current source.
You can continue to running or debugging the program.
A failed build means Visual Studio encountered a problem that prevented the current source from being compiled successfully.
Read the message Visual Studio provides.
Do not begin changing unrelated code.
The first goal is to understand what the compiler is pointing to.
Compiler messages often identify:
Treat that information as evidence, not as a punishment.
For example, if a message points to a statement near:
player1.jerseyNumber = 7;
inspect that statement and the nearby source.
Sometimes the real problem is on the line immediately before the one highlighted.
A missing brace, quotation mark, parenthesis, or semicolon can change how the compiler interprets the statements that follow.
Suppose the build fails after you make one small edit.
A good recovery process is:
Avoid rewriting large sections of working code because of one compiler message.
Small, evidence-based changes are easier to understand and easier to reverse.
A build answers:
Can the current source be compiled?
Running the application answers:
What does the compiled program actually do?
Those are not the same question.
A program can build successfully and still behave incorrectly.
For example:
Player player1 = new Player();
player1.name = "Jordan";
player1.jerseyNumber = 17;
If the intended jersey number is 7, the code can still build.
The compiler does not know the soccer requirement.
You need requirements, program output, debugger observations, or other evidence to decide whether the value is correct.
When you change source code, rebuild before assuming the change is usable.
This keeps the development cycle clear:
Make a focused change → Save → Build → Continue only after the build result is understood
If the build fails, deal with that evidence first.
If the build succeeds, you can move on to runtime observation.
Building is not the final goal.
It is one gate in the development process.
A useful mental model is:
The next activity focuses on that last step.