DEV Community

loading...

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

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 • Edited

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