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.
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.
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)?
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.
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.
Doing
dotnet new consolecreates a new “console” project in the current directory.It creates two files - a
.csprojand aProgram.csfile. TheProgram.csfile contains your code (you can add as many extra cs files as you want). The.csprojfile 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. Theobj/folder can be ignored.In that project directory, you can use the command
dotnet runto run your project. Alternatively, you can dodotnet buildto compile it, and then you can manually click the exe in thebinfolder.It is worth installing visual studio, as it provides a nice interface to manage all this stuff.
The
dotnettool is a wrapper for several other tools such as the nuget package manager and msbuild build system.The first command,
dotnet new consoletells the tool to create a newcsproj(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 runchecks the current directory for acsprojfile, and if there is exactly one of them, then the project is compiled using the new Roslyn compiler using theDebugconfiguration andAnyCPUprocessor 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 standardexe) 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
csprojfile 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.So, how do I actually use any of that shit?
Primarily;
What happens if I don't make/have a
csprojfile?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)?
I just generated whatever this bullshit is.
LIKE, WHAT EVEN THE FUCK DOES THAT MEAN!?!?
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 Worldto01001000 01100101 01101100 01101100 01101111 00100000 01010111 01101111 01110010 01101100 01100100which 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.
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.
Can you send me a tutorial on how to use this?
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.
docs.microsoft.com/en-us/dotnet/co...