DEV Community

loading...

Discussion on: How to update my .NET C# compiler (csc)?

mileswatson profile image
Miles Watson

Doing dotnet new console creates a new “console” project in the current directory.

It creates two files - a .csproj and a Program.cs file. The Program.cs file contains your code (you can add as many extra cs files as you want). The .csproj file contains information that helps the compiler understand how to build (aka compile) your project. For example, what libraries to use, what framework to build it for, whether to ignore certain warnings etc. The obj/ folder can be ignored.

In that project directory, you can use the command dotnet run to run your project. Alternatively, you can do dotnet build to compile it, and then you can manually click the exe in the bin folder.

It is worth installing visual studio, as it provides a nice interface to manage all this stuff.

Thread Thread
sharpninja profile image
The Sharp Ninja

The dotnet tool is a wrapper for several other tools such as the nuget package manager and msbuild build system.

The first command, dotnet new console tells the tool to create a new csproj (aka C# Project) file in the current directory, named the same as the current directory. The project file is used by the Roslyn compiler to make decisions about how to compile and link the results.

The second command, dotnet run checks the current directory for a csproj file, and if there is exactly one of them, then the project is compiled using the new Roslyn compiler using the Debug configuration and AnyCPU processor target. Assuming the compiler was successful at compiling the code to a shared DLL, it then gets the output type from the project file (in this case a standard exe) and then links the dll with a bootstrapper for the host OS and outputs the executable binary using the default linker profile for the target.

The csproj file is vital to creating an executable file that you can actually run. Since Dotnet Core and .Net 5.0 are cross-platform, many more pieces of information must be fed to the compiler to create usable binary code.

Thread Thread
baenencalin profile image
Calin Baenen Author

So, how do I actually use any of that shit?

Primarily;
What happens if I don't make/have a csproj file?
Do I have to do anything with the file when it's generated?
Why the fuck is it always more complicated than just a language and the compiler/interpreter, why is all this bullshit here, when I just want to do something simple (similar concept applies to Java)?

Thread Thread
baenencalin profile image
Calin Baenen Author

I just generated whatever this bullshit is.

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net5.0</TargetFramework>
    </PropertyGroup>

</Project>
Enter fullscreen mode Exit fullscreen mode

LIKE, WHAT EVEN THE FUCK DOES THAT MEAN!?!?

Thread Thread
sharpninja profile image
The Sharp Ninja

In the early days of .Net Framework, the target was always known: The output would be MSIL, would be executed in the CLR, and would run on Windows. Now, none of these things are a hard fact. The Dotnet tool chain, including the Roslyn compiler and .Net Native linker, is capable of spitting out a CPU specific binary with any combination of platform headers, garbage collectors or executable formats that you can think of.

So, 20 years ago, csc.exe was endowed with what is known as "opinions". These opinions assumed that the C# it was ingesting was going to run on the Microsoft built CLR (with complete access to all its resources) in Windows.

But times have changed. Microsoft is actively developing and supporting C# and F# running on WASM, Windows, Linux, MacOS, iOS, Android and Tiezen. It is actively developing and supporting code generators for x86, AMD64, ARM, ARM64 and WASM. This means that the compiler has to accept many choices to put together a strategy to go from Hello World to 01001000 01100101 01101100 01101100 01101111 00100000 01010111 01101111 01110010 01101100 01100100 which makes being opinionated bad.

To reign in the dizzying array of options , Microsoft introduced a new, simpler project file format with Dotnet Core that would allow the easy configuration of one or multiple build scenarios from a single file format. The default project file specifies the default SDK to use for base libraries, what output format (dll, exe, windows exe, WASM), and what version of ,Net the application will run under. By adding more properties you can further specialize the build of your application

Without the csproj file you would have to feed these options to the compiler on each build.

Thread Thread
baenencalin profile image
Calin Baenen Author

Why is it built to look like XML, though? Tgat shit is fucking confusing to understand, or remember.

It would have been btter if they made it look like, or be INI/JSON.

Thread Thread
baenencalin profile image
Calin Baenen Author

Can you send me a tutorial on how to use this?

Thread Thread
sharpninja profile image
The Sharp Ninja

The csproj file has actually been around as long as C# has, and it has always been an XML file. When they reworked the project file for Dotnet Core they actually did make it JSON at first, but they decided to stick with XML. I'm sure the fact that the project file is actually a valid MSBuild script had a lot to do with that decision. You can define MSBuild tasks and use them right in the csproj file to do things like move resources around before or after compiling code.

Thread Thread
sharpninja profile image