C# is really bad about this. They seem to be heavy into the Magical Boilerplate coding style in which your "empty" project consists of thousands of lines of duplicated/generated code which you then make slight edits to. My opinion is that if some piece of code is so common that it needs to be inserted into every project - then it should be a library call. Apparently that's a minority opinion though..
This isn't my experience with C# (an empty project starts with a `Class1.cs` file if it's a library or `Program.cs` if it's an application), so you might be using something on top of C# that needs all of that boilerplate.
Sounds like project templates in Visual Studio - which can populate your project with vast amounts of stuff. This can good or bad depending on the context.
No. There are two files, Program.cs and Startup.cs. Program.cs is 26 lines long, Startup.cs is 35 lines long. Project file is 15 lines long.
Of course, there is whole web server Kestrel referenced somewhere, using NuGet and DLLs full of MSIL. Formulating "depending on compiled library code" like "contains _ lines of code" is, especially in the context of the conversation, arguably dishonest.
No. Just looked, and the only large file generated is the dependency cache (~7000 lines of json) which you never touch and can always be regenerated with dotnet restore.
The rest is ~100-150 lines code+configuration and a readme file (~180 lines).
Look- I get that a lot of this stuff (jquery..) is libraries, and some of it is the visual studio solutions file, but if it's libraries, then why was it copied into my project directory?
That's not an empty .net core project; that's a sample project that you can run and see a whole website which itself is documentation on creating .net core site.
However, I'm not sure Visual Studio gives you any way to avoid this when you use the GUI to start a new core project. It is however possible to create a non-Core ASP.NET project with literally nothing in it.
project.assets.json (and everything in /obj) is a build artifact, not source code. Would you include .o files in the weight of a sample C project ?
applicationhost.config (and everything in .vs) is local configuration for your editor (Visual Studio 15, it appears), not source code. Would you include .emacs.d in the weight of a sample project ?
Every folder in /wwwroot/lib/ that contains a .bower.json file is a local package cache, not source code. You don't have to commit it, just run bower when building your solution (if it's not done automatically for you) to restore them. If those were .dll or .pdb files instead of .min.js and .map, would you count them ?
The remaining two hundred lines of code are the contents of the "Sample" project, written to illustrate ASP.NET Core.
I never built the project. So I don't see how any of this stuff can be build artifacts. There should definitely not be copies of any "package caches" in my project folder. Why would I want a separate copy of jquery for every new project? It all shows up as part of the project when in fact that stuff is a logically separate library. Only code that is unique to my project should be in the project folder. Nor should editor config appear in the project folder. Including Jquery should be just one line of source code:
Using jquery;
I really don't care why VS put that stuff in my project- but as far as I'm concerned, if it's code of any kind, and it's in my project, and I didn't write it, then it's boilerplate. If it looks like a duck, and it quacks like a duck, then it's a duck.
I mean if I'm introduced to some other programmers project I now have to wade through this rats nest of package caches and auto generated classes and other trash trying to figure out which little bits are actually unique to the project itself. I really shouldn't have to do that.
