The “Bare Minimum” Philosophy

For this Introduction, we are intentionally avoiding “Heavy” software. We are using a Lightweight stack so that you can see exactly how code travels from your keyboard to the CPU without the magic of a massive IDE hiding the process

The Minimum Essentials:

  1. A Text Editor ( VS Code): just a place to write code.
  2. A Translator ( .NET SDK): The tool that turns those code into instructions.
  3. A Terminal : The direct line of communication with computer.

Installing the .NET SDK

The software development kit (SDK) is the only strictly “required” item to make C# work. It contains the Roslyn Compiler(To translate your code) and the Runtime (to run it).

  • Download dotnet
  • The Verification: Once installed, we need to verify it.
dotnet --version
// if you see a number the .net is ready to use.

Setup Vs Code

while we could write C# in Notepad, Visual studio code provides the “Bridge” feature like syntax highlighting (color the text). that make learning much less frustrating.

  • Install vs code
  • The “Bridge” Extension: Search for the C# Dev kit in the extensions tab. Why? this extension acts as a translator between vs code and the sdk you installed

First Manual Build

To stay “bare minimum” we won’t use any “Play” buttons, we will use the command line to build our app from scratch.

  • Create project: dotnet new console -n HelloWorld
  • Run project dotnet run
  • type code inside program.cs
Console.WriteLine("Hello World!");
  • dotnet run

Project Scaffolding and the .NET File System

When you run the command dotnet new console -n HelloWorld, the .NET SDK acts like a Project Generator. It creates a folder and fills it with the basic “ingredients” needed to run C#.

dotnet new console -n HelloWorld

The command breakdown

  • dotnet: This is the primary command that activates the .NET toolset. It tells the operating system to pass the following instructions to the .NET SDK
  • new : This is a sub-command that tells the SDK we want to initialize a new project based on a pre-defined template.
  • console : This specifies the type of project. “Console” template is the most basic form of program. it runs in a text-based terminal rather than a windowed graphical interface (GUI)
  • -n HelloWorld : The -n is a flag ( short for name) It tell the SDK. create a specific directory (folder) named HelloWorld and place the project inside it
/HelloWorld 
	/bin
	/obj
		HelloWorld.csproj.nuget.dgspec.json
		HelloWorld.csproj.nuget.g.props
		HelloWorld.csproj.nuget.g.targets
		project.assets.json
		project.nuget.cache
		/Debug
			/ref
			/refint
			HelloWorld.Assemblyinfo.cs
			HelloWorld.AssemblyInfoInputs.cache
			HelloWorld.assets.cache
			..
			..
HelloWorld.csproj
Program.cs

The Root Files

  • program.cs (The Source Code) plain test file contain your C# code, it’s where we write instructions for the computer.

  • helloWorld.csproj (The project Configuration) An XML-based file that acts as a manger of the project , It defines the Target Framework( eg .NET 10.0) and lists any extra tools or libraries your project needs to run.

The obj Folder

The obj folder stands for object. This is the computer’s internal scratchpad.

  • What it does: When you type dotnet build, the computer doesn’t translate the whole project at once. It breaks it into small pieces(objects) and stores them here.
  • The “Secret” Feature (incremental Builds): if you have 100 files and you only change one, the .NET SDK looks in the obj folder, sees the other 99 are already finished, and only translates the one you changed.
  • Student Nots: This is the staging area. it is where the computer organizes its thoughts and checks your .csproj instructions before making the final app.

The obj folder is full of JSON and configuration files. Never edit these manually , This folder is the scratchpad for the .NET SDK. Before the computer turns your code into a finish program. it need to organize.

  • project.assets.json This is a map of every library and dependency your project uses. It helps the compiler find the exact code it needs to pull from the .NET SDK.

  • .nuget.g.props and .nuget.g.targets These are technical “hook” files. They tell the compiler how to handle external packages (NuGet) that you might add later.

  • project.nuget.cache A small file that keeps track of the “Restore” state, making sure the computer doesn’t have to re-download or re-check libraries every single time you click run.

The bin Folder

The bin folder stands for Binary. This is the Finished Goods Warehouse.

When you click “Build” or “Run”, the compiler translates your human-readable C# code into machine-readable files. These live in the bin Folder.

  1. HelloWorld (The core) , This is the most important file. It stands for Dynamic Link Library. In Modern .NET, your actual compiled code lives here. However, it isn’t a standalone “app” that a computer can run by itself it needs the .NET Runtime to execute it.

  2. helloWorld.exe (The Launcher) On Windows, this is the Executable. while .dll contains the logic, the .exe is the “wrapper” or “host” that starts the .NET runtime and tells it to run your DLL. This is what the user double-click to start the program.

  3. HelloWorld.pdb (The Map) PDB stands for Program Database. Think of this as a map that connects the compiled code back to your source code. - Why it’s there: It allows you to use “Breakpoints” and see exactly which line of code is running during debugging. - Note: You don’t’ include this file when you send the final app to the customer.

  4. helloWorld.runtimeconfig.json ( The Manual) This file tells the computer which version of .NET is required to run the app (eg .NET 8.0). Without this, the computer wouldn’t know “engine” to start your code.

  5. helloWorld.deps.json (The shopping List) “Deps” is short for Dependencies. if your project uses outside libraries (Like NuGet packages), this file lists them all so the program knows exactly where to find the extra pieces it needs to function.

if your vs code acts ‘weird’ or gives you strange errors, delete both the obj and bin folders and run dotnet run again. This forces the computer to clean its kitchen and start a fresh build from scratch.

Life Cycle of C# Code

In C#, your code isn’t just “run” it is managed It goes through a transformation from human-readable text to a global language, and finally to machine instructions.

Stage-1 The Source Before a single line is compiled, the .NET SDK must understand the “project context”.

  • The .csproj (Manifest): This isn’t just a settings file. it defines the Target Framework Moniker It tells the compiler which set of “building blocks”(APIs) are allowed to be used.
  • Program.cs: High-level c# code. this is unmanaged text.

Stage-2 The staging Area When you trigger dontnet build, the Restore phase begins.

  • Dependency Resolution The SDK creates project.assets.json. This file is a massive map that links your 1 line of code to the thousands of lines in the .NET Standard Library.
  • Incremental Check: The SDK generates .props and .targets files. It compares the “Last Modified” timestamp of your program.cs with these files.
    • Technical Details: If the timestamps match, the compiler stops to save power and time. This is why the second time you run code, it feels instant.

Stage-3 The Factory (The Roslyn Compilation) Now, the Roslyn compiler performs a two-pass scan of your code:

  1. syntax Analysis: It turns your text into a Syntax Tree. If you forgot a ; the tree breaks, and you get an error.
  2. IL Generation: It translates the Syntax Tree into CIL (Common Intermediate Language)
    1. The Details: CIL is an object-oriented instruction set. It describes intent(e.g, “Call the WriteLine method”) rather than physical CPU actions (e.g, “Move this bit to Registry A”)

Stage-4 The Managed Assembly (Inside the bin folder) The compiler outputs an Assembly(the .dll or .exe).

  • Metadata: The file in the bin folder contains a “Table of Contents” listing every class and method you wrote.
  • Wrapper: On Windows, the .exe is actually a small piece of “Native” code that acts as a Launcher. Its only job is to find the NET Runtime on the computer and hand over the IL code.

Stage-5 The Runtime & The JIT (The Bridge) This is the most critical stage. When he user run the app:

  1. Loading : The Common Language Runtime(CLR) loads the IL from the bin folder into RAM.
  2. Verification : The CLR checks the IL code to ensure it’s safe (Type Safety). It makes sure the code isn’t trying to access unauthorized memory.
  3. JIT Compilation : The Just-In-Time Compiler looks at the specific CPU(Intel, AMD, or ARM). It translates the “Global” IL into Native Machine Code specifically optimized for the exact processor.
  4. Execution: The CPU finally executes the os and 1s.

The “Bare Minimum” Reality Check. If you delete the .NET Runtime from the computer, the file in your bin folder becomes useless paper. It has the instructions, but the ‘Engine’ that understands those instructions is gone. This is why C# is more powerful than C++for cross-platform work, The Engine handles the hard work of talking to different computers for you.