I just want to wrap my head around dotnet
Hi there, nooby here.
.NET, dotnet, ASP, CLR, it's all so utterly confusing. I am a person who only gets something once I have a lifecycle-like simulation of it in my head. I want to know what my C# project contains, what it does, and what it uses and goes through to get to the final executable file.
I really wanna get into this language, but every. damn. time. I even get close to it. I am bombarded with obfuscated toolchains behind walls of folders and names I can't begin to remember.
This is so much more painful than compiling C++ with MingW: C++ Source -> Mingw GCC.exe -> Compiled Binary Object -> Linker -> Compiled Executable. I get the jest of it, as I'm aware it's not perfect, but it's there!
My biggest pain point with C# is the obfuscation of its compiler, interpreter, and its strong association with the devil device named "NuGet" . I just don't get it. I tried searching for some tutorial that doesn't yank "Download Visual Studio and press these buttons to make a project," at me, but I got nothing. The reliance on hidden toolchains and Visual Studio have been nothing but cancer to the way I learn things.
If you got some article, video, or something that DEFINES the clear life cycle of a common C# project with relying on Visual Studio shortcuts, then please, forward them here.
196 Replies
c# as a managed language is simply not as straightforward as an unmanaged language like c or c++.
c# source code is compiled to IL, byte code that basically lowers your code to an already slightly optimized version. at runtime, this is then executed and further optimized by the just-in-time compiler, which makes changes to the assembly in tiers, depending on how important it believes these optimizations are (how often is this code run, for example).
very simplified and I'm sure others will elaborate
in terms of building stuff without vs, that's entirely possible.
the dotnet cli is fairly powerful and can do most of what you need to create, compile, and execute your c# project.
simple commands like
dotnet new console and dotnet run will be enough to create and run a Hello World app
debugging, of course, won't be possible without a proper ideI have some knowledge which does include the above, but what really burns me for no reason is the weird obfuscation of everything. A very basic example is in the way dotnet makes a project from a template. Where is this template stored originally? It's clearly downloading something when I ask it to make something new, where is it downloading? Why is not even telling me that it's downloading anything? Maybe this sounds like silly whining, but for some reason, this ticks me off to levels beyond what I can describe
It's absolutely not downloading anything. These templates are stored (somewhere) in the dotnet install directory
Nope, I tested with
mstest-playwright and its internet usage spiked up
Not a single line was written about these hundrads of megabytes are be thrown to, and not a single line to tell me, the end user, that this thing is clearly downloading somethingIf anything, that's telemetry. The dotnet cli doesn't need an internet connection
Then It might not be the template, but maybe some package that it requires?
I'm telling you, all of this is installed on your machine
NuGet doesn't really play a part in compiling or interpreting
NuGet is a package manager where people host their libraries for others to consume. Fetching a package does require an internet connection for obvious reasons. Once downloaded, the library is available to you, you can reference it in your code, and will be copied to the output directory once you compile your project
That is what I assumed at first, then I tried to compile something, then it complained about
The "ResolvePackageAssets" task failed unexpectedly. with many references to NuGet, then later, the error disappeared for no reason.
I mean, cool it works, but nothing passed through my head where which I understood anything. All I got is: NuGet error? Let me try to fix it. Oh, it got fixed before I had time to think about it and figure out the reason behind it.
And obviously, this or that aren't my main gripes, it's the combination of all of themThe dotnet ecosystem is pretty large and pretty old. Issues that are undocumented or unexplainable are bound to happen, just like in any other language
The resolving of packages happens during project evaluation, done by MSBuild and the dotnet sdk
There are a lot of parts to it
If you'd like a more detailed look into how msbuild evaluates projects and runs the necessary targets and tasks, you can run
dotnet build with the --bl flag, which will generate a binlog. You can view this binlog with the msbuild structured log viewer
Just a heads up, it's very complicated
And not usually something you need to or should care about
I get wanting to understand how the sausage is made, but this one might not be worth the effortYeah, it's a bit of painful reality
It requires incredibly deep knowledge of all of these systems
I can definitely see a programming ecosystem where which this is unnecessary, but it ain't got the same demand as this cursed language
That's a you opinion :p
That's true
I find everything that has to do with .net very impressive
Honestly I feel that c# is more straightforward than most languages I have used, though It can be hard to use if your not experienced with similar languages
That's in relation to the syntax or the toolchain?
Both
I am not expert, but having 10+
dotnet-named folders in the entirety of my system is not what I would call a "straightforward toolchain", at least, with my definitionbetter than a hundred cmake files
At least, they're in the same folder
that makes things worse
Though, I don't want to defend Cmake that hard 😂
I'm not sure where you see 10+
dotnet-named folders
Plus, if I may, you can compile c, c++, and zig with sorbet ;)
dotnet even
What is sorbet
dotnet
An icercream apparently
:resisting:
Kind of ice cream
Your instructions were not clear my man
Might be good to know where these are actually placed. Do you have multiple versions of the SDK and/or runtime installed?
I corrected myself, idk what more you wany
I am aware that the functionality of any
dotnet-named folder will differ and you can guess that simply by the path, but my point was about how this toolchain is just structured in a way that is not meant to be... touched? messed with? something like that.Normally it will not appear like that
But again, that's not how my brain functions ðŸ˜
I don't know what toolchain should ever be touched
That just seems like asking for trouble
The sdk is installed in places that you shouldn't manually edit for a reason
What I mean is meddled with in a way to understand how it works well enough to fix a decent amount of problems that would aries from you not having understood how it works
Is this sorbet we are talking about?
https://sorbet.org/
It was a misspelling of dotnet,can we please move on?
I actually legit thought it was a name of something, my bad
I feel like I'm either the only person who feels this way towards C# specifically, or I'm just in a very small minority because I see no one complaining about the same points I normally complain about
There's simply too much to understand, it's unreasonable for anyone to want to dive into the SDK to try and actually understand its inner workings
Yeah no I've never seen anyone be this concerned with how it works
My thoughts are. If it works, I don't need to worry about it
ðŸ˜
Besides the people working on it of course :p
In think if I have to be more and more specific, it's the fact that dotnet is scattered all over the system rather than in a single folder
I've worked with single-folder languages before, and regardless of how much it obfuscate, I don't have much problems with it
It's simply impossible (simply from a logistical standpoint) to clutter everything into one place
C# is the subject here or any toolchain?
Like I said, it would be important to know the actual directory paths of those dotnet folders
oh man, let me tell you all about windows software, if you think they are only installed in a single place, you are very mistaken.
And in fact, linux software too
Well, I don't need to know what my browser does and what folder it's in, but I need to know that for a toolchain
hmmm, no you don't
Also, I have a good idea of the general folders a program installs itself on in windows
you run dotnet build, it works
I'm aware, I'm not saying this from a literal standpoint, but an anecdotal one
As an anedoctal standpoint, I run dotnet build, it builds
Fair enough 😂 , I know I'm alone with this one
If you're still concerned about the scatteredness, please genuinely share the paths.
Otherwise, if you really care about the build process, do what I said with the binlog
I had to look up what anedoctal meant
Here's the full list
To be clear, there were more, but I hated them and deleted them (they were in the programfiles(x86) folder so I assumed it's needed when I make a 32bit application)
Well I mean most of them are analyzers
No, you shouldn't have x86 versions of the sdk installed
Unless you're on a x86 machine
It was just lying there
Which you're not
So, from my point of view, they are all children of the main dotnet folder found in programfiles
That is the main one
Mhm
dotnet.exe is where the compiler and other parts of the toolchain gets called
But not the compiler itself?
Where is roslyn
I forgor
Don't look at me, I don't use windows
lmao
I don't know if it's still csc.exe?
Should be
One in build tools (visual studio) and three more in whatever the heck that folder is
None of which are in the dotnet folder
Visual studio have the fabulous tendency of installing multiple versions of everything
For refernece
I have that thing UNINSTALLED
I have no clue why this is here
Windows comes with .net framework
Seemingly your actual problem is Visual Studio and not dotnet/c#
The bane of my existance ðŸ˜
and yes, windows comes with it
here's the entire list
just like linux, most of them, comes with python
I don't think it's csc.ece anymore chief
Ahahaha
I will do a simply test
Oh, you have Unity too
I will delete all of these and see if the c# project continues to compile
Yeah nuke your system!
If you struggle with that try jetbrains rider
careful, you might break your system, somehow
Who just deletes random files that they don't know if they're important lol
I do that
Find an uninstaller, run that
Use geek
Also, all the files seem to be used by a program? Can't delete them
Why don't you just use gentoo
gentoo?
Linux users suck, do you see me going around telling people to use Windows
I forgot rider does C#
Linux distribution where you can literally removes slices of the software trough the build system and package manager
you won't need to delete anything because you choose what to install to begin with
That would be rad
But linux is not rad
unfortunately
no offense
none taken, just mentioned because thought you would actually love it
gentoo
Will keep it in mind
ah
so it is nowhere near the dotnet folder
thanks microsoft
I don't think that's right
@333fred? What's the compiler's executable and its path?
Seems like that one is the one that comes with windows
:waiting:
It's the one that comes with framework
Alright
No. Bad. Do not use
(oh you'll love hearing about .net versioning)
You don't care about where
csc.exe is. All you care about is dotnet.exeSo it is just that
So it is the compiler?
It runs the compiler for you. A hello world has 150+ arguments to csc.exe
Don't concern yourself with it
...
lmfaooo
Fair enough
I get wanting to understand all the pieces in play
See that's the thing. The whole system is so massively complex, it's futile to want to try understanding it all in its entirety
Okay, not understand, what about know where it is
I give up understanding
Well what's "it"?
The abstraction that should really matter to you is that
dotnet.exe (or just dotnet on non-windows) wires up all the calls and arguments to csc.exe (or just csc), by transforming data from your .csproj filesBut first, we need to talk about msbuild.exe
Compiler, interpreter, standard assembly references, etc
Alright, at least that shifts my focus to the .csproj file
Oh yeah
It's like the cmake equiv for c#
That's selling it short by light-years
simplest explanation though
I suppose
It's a good description
I see no references to my
.cs project files so I'm definitely unsure of how it works
Fair enoughNowadays, the
.csproj does a few things for yousconsfile then?
Again, binlog :p
You used to have to list all your
.cs files, but that's painful
There's an implicit include for **/*.csI will check it out actually I'm interested, but what did you say were the tool needed to view these files?
All
.cs files in the folder hierarchy?Kirill has an avalonia version that runs on Linux as well, but you'll have to build from source for it
Yep, from the csproj root down
goit it
Now, this mess
It's a glob, ** means recusively all folders down
Oh god the intermediate output :ICANT:
I assume obj is similar to C++ making object binaries out of files before combining into an
.exe and bin is just that .exe with the needed librariesYes, though obj has a bit more than that
After a
dotnet restore, nuget will have written out all your package information, that's those json filesDo you check those stuff even when doing stuf in C/C++?
Check?
Or maybe rather, did you when you first started I guess
Yeah like did you care about the toolchains this much? Where the compiler lives and what it does? Whether it produces intermediate output?
Yes.
Only after I got that piece of information was I comfortable writing more C++ code
Horribly inefficient I feel like
Eh, some people learn best top-down, some people learn best bottom-up
It literally did nothing to my efficiency but it made my brain very happy
Bro is outing me in public ðŸ˜
I would definitely suggest that you try and ignore anything but the high-level details for things in
obj though. I work on the compiler, and I can't say that, other than package.assets.json, I've ever needed to look at anything in obj
It's all a more verbose and direct consequence of things in your project fileI will say working with the compiler sdk, with msbuild, knowing the cli and sdk a bit better definitely gave me a lot more appreciation for the systems at play and the people behind it
Reading this hurts so badly... But I can't but agree
Okay, how about this, is it possible to learn enough so one can be in no need to rely on visual studio?
in any way shape or form
Absolutely
Fred and I both don't use vs :3
As long as I get out of that hellhole, I can probably* manage
You guys are Linux, no?
Correct
I'm on Windows
Oh, but no vs alright
(I use tiny11 btw)
i just use visual studio code and have dotnet installed trough my package manager
The only times I need to open VS are when I need to do VB work that I can't just get done in a few lines
Yup, vscode for us as well
I do most of my stuff via the cli
Alright, going making this thread definitely gave me more confidence to deal with this language more. At least, I don't' have the same bitter pain as when I opened it. I will see what I can do for the time being to learn more C#, which brings me to another pain point. What's a good way to go forward without long tutorials or big files downloaded?
It's just quicker
Just one thing
If you are going to use Unity, you are never touching dotnet yourself
I plan to do more than Unity
Well, to learn the language, I say just use it
Think of something to do and do jt
pretty much
Alright, visual novel it is
You can write a visual novel in Avalonia!
Oh?
Looks pretty good
But if you really wanna learn unity, do that :p
Take a look at others code and try and understand it
I just think desktop dev is useful. Especially Avalonia can teach a lot of techniques
No, no, I really do wanna do more manual stuff as those things can easily transferred into any language + the benefit of learning a high-in-demand language such as C# more closely.
Also that, yeah
Maybe Avalonia isn't so good if you wanna do manual stuff. The appeal there is that the patterns you use allow you to simplify a lot of things away
Dependency injection, source generation
xaml interpretation
But it seems like a good starting point
Maybe a console app is better
Oh yeah, that's what I think of before a visual novel. The VN is more of a big goal with smaller, ladder-like goals behind it
Like a hangman game or tic tac toe or connect 4 or chess or poker
Or a text adventure!
that also works!
Anyhow, I took enough of you guys' time already
Thanks a bunch for the help
It is 3am!
It's 4:40 here!
A.M.
it's 10 pm
You also practice of hackerrank and solve different problems
8:44pm for me
Meh, some people will agree, some will vehemently disagree
I understand but honestly it's a lot easier than coming up with problems for yourself, and I only use it when I dont have a project idea
Things like leetcode are good to challenge you mentally and think about problem solving
But you won't gain actual coding skill
try to make a game engine, not as hard as you think if you a use a bunch of libraries, the fewest libraries you use, the exponentially harder it gets tho
it's fun
Okay I mean that's a bit much
But after some time it's a viable choice
Very very different problems to solve there as well
that would be the dream
Graphics, performance, ui/ux, physics
I think even just a library that solves a problem you haven't found someone else implement a solution for and putting that up on nuget is huge
that's why I said that it is not as hard if you use a bunch of libraries
Doesn't have to be fancy, just has to be useful