I understand the struggle but may not be able to offer an exact solution. People usually expect you to just throw something together without structure, but if you don't have preliminary experience with doing
anything similar at all, you are stuck with a blank piece of paper and no ideas, and it
feels absolutely terrible.
I don't know what works for you, but what worked for me was finding open-source projects in a domain I'm looking to write an application or a library in and using them as a reference. With time, you become able to determine which ones are of high quality and are a good example, and which ones are not. You could also ask Claude/ChatGPT for references to starting point.
On C# specifically, I can recommend looking at https://github.com/bitwarden/server which is more "traditional" style but does not have much nonsense/bloat you would usually see in an enterprise codebase. That's what I always reference as a style and project layout guide for newcomers that don't already know how they want the project to look. And then as you go through the code, you can always dump the snippets into a chatbot and then cross-reference the replies with documentation if needed. Chatbots also great at quickly sketching up project structure - it can be a terrible one but it's easier to do "hey, I don't like this, let's change it to X" than trying to come up with everything from the scratch.
If you already have experience with writing TS-based applications with e.g. React components, base router, etc., you can more or less translate this onto structuring an ASP.NET Core application with controller/api handlers, model classes, services, ORM layer and similar. There really is no true right or wrong singular way of doing it, and people who claim there is are dogmatics from a cargo cult.
In general, a lot of C# code out there that you will encounter will take more steps to solve its task than strictly necessary, as the generational trauma of ungodly horrors of 666-layer "Clean" architecture DDD-done-badly monoliths still haunts many, manifesting in a milder form of "write a small three file microservice as a 40-file three-project solution". It is highly useful to approach new patterns and anything that seems ceremoneous with "is this abstraction strictly required or can this piece be removed and done in a few lines of code or maybe a method?".
On tooling - can strongly recommend using .NET CLI which will be very familiar after using NPM and co.:
Create new projects/solutions with 'dotnet new {template name}' (e.g. console, classlib, sln, gitignore).
Add/remove projects to/from a solution with dotnet sln add/remove
Add dependencies with 'dotnet add package PackageName' or 'dotnet add reference path/to/project' if you want to combine multiple projects.
Run projects with 'dotnet run' (-C release). Hot-reload for most scenarios is possible with 'dotnet watch'. Publish into a final complete application with 'dotnet publish -o {path}'. There are many ways to do the last one, but for simple back-ends doing the default output and then copying it to a "runtime" image in a dockerfile will suffice.