Develop Reference

How do I set common values (abstract) for a C# solution in Visual Studio with multiple sub projects?

I have a solution with multiple projects each of which connects to the same DB and uses overlapping constant values that I would like to set somewhere instead of replicating manually. I have tried a variety of things online like making a custom class and linking projects to it, setting constants in a project config file (which doesn't exist like the guides claim), and so on. I've been unable to figure this out after more than an hour of searching and experimenting so if you have any ideas, let me know. The structure looks like this (the blue-underlined stuff are some of the projects in the list):

You can make another project under the solution to contain your class.
All the other projects can then reference that project, meaning the same functionality will be available in all the other projects without having to duplicate anything.

I will extend the previous correct answer with some more information.
Your solution structure is something to think very carefully as it is a combination of application design/architecture and leads to extensibillity, scalability and future maintainability.
Take for example the following article Common web application architectures.
You can see the Clean Architecture (AKA Hexagonal) which leads to specific projects withing a solution
You can see older designs where the DB access would go into a project called ..DAL
Simple projects can use the second one, more business rich ones the first or something in between.
Check this this article on shared code projects to see about net standard projects

So the above was helpful, but far more complicated than it needed to be. Apparently other answers I'd seen actually work, but it took reading a bunch of other pages to figure out the whole puzzle. The working steps are:
Create a class with public parameters for your constants
Place that class somewhere in your solution space. When I created it on the solution, it was placed in "Solution Items" in my tree (which is the root folder of the solution on the file system).
Right click each project and ADD>Existing Item and point to the class. The KEY (that was missing from most things I read) was that the "add" button" has a drop-down arrow that lets you change it to "Add as link"
In each project (after adding as link to the file), you can directly reference the values as NAMEOFCLASS.NAMEOFCONST but ONLY if you declared them as public const SOMETYPE SOMENAME. Without the const, it's not able to directly reference the value
Note that this fix is in the .sln file itself and needs to be part of the commit or it won't have any effect. It would be nice if you could use "include" or something to bring in a file a folder one level up, but here we are.

How to evaluate which DLL-Files/references are really used at runtime?

I have a bundle of helper-method packed into an own class library (i.e. Tools.dll). When I start a new project I almost everytime reference this library.
When Visual Studio compiles my new project I get a bunch of files in the bin\debug-folder. Of course there are "mynewproject.exe" and "Tools.dll" but since the helper-methods have own references I also find "HtmlAgilityPack.dll", "Scintilla.dll" etc. wheter I really used some of these functionalities or not.
My question is: Can I get rid of them?
If Visual Studio can filter them out themself, perfekt, if I have to do it manually at runtime, can you offer me an idea how to do that?
I did a lot of research but I can't find a method to analyse which dlls are used or to analyse at runtime which method calls which helper-method.
Thanks a lot!
Update to specify my idea:
My idea was to run a script every time the program is started which checks which dll-files are there and then runs recursive through all methods to look which files are really needed. Then I could delete the unused dll-files. If that script needs to long I could additionally add a flag so this script has only to run once after every compiling.
If anyone has a better idea I'm of course interested :)

You can use my Runtime Flow tool to get this information. In the Runtime Summary window you will see all assemblies, classes and methods used during the program execution. And for each method you will see how it was called.

Three gray dots under variable names in Visual Studio

What do these three gray dots mean? I recently updated to Visual Studio 2017, and I haven't ever seen them in other versions of VS.

They indicate suggestion from Visual Studio to refactor your code to be simpler, more readable and efficient.
See Quick Actions and Refactorings section of the Visual Studio 2017 (version 15.0) Release Notes.

Just to make doubly clear for newish programmers, these are not in any sense error messages. They are merely suggestions for more "readable and efficient" code as #Oleksander states.
Some may not be the best advice for your application, unlike warning or error messages, which almost 100% are in my case at least.
I had suggestion in a Unity game engine C# application to make a variable "readonly". I'm not sure in my case it makes practical difference whether this is readonly or not, as in this case I think fairly obvious in the context: a private variable which is serialized and can be set in game's editor program, nobody likely to create new method in this game scene manager class to alter/assign this variable. Likewise it gave a suggestion to create property for a class private field, which I think extra code overkill.
At the least these are low priority messages to action.
Suppressing 3 Dot Symbols in Visual Studio
If you right click and read through one of these suggestions, you can find there is option to suppress these messages in global project file, with various optional parameters. So eg in my case, now I don't want any readonly message suggestions for whole project (welcome correct me anyone more experienced if this is bad idea!), so in the root of project, same level as .sln solution file, .csproj files, .git file in my case for C# project, it saves file called "GlobalSuppressions.cs". Root location and this exact file name is presumably crucial.
I guess if you want stop future coders / future you from fretting or spending time on these 3 dot messages when you think waste of time, could be useful.
In my case, to get rid of all "readonly" keyword suggestions in this project, code is (comments are VS auto comments):
// This file is used by Code Analysis to maintain SuppressMessage
// attributes that are applied to this project.
// Project-level suppressions either have no target or are given
// a specific target and scoped to a namespace, type, member, etc.
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Style", "IDE0044:Add readonly modifier")]

Provide hint to IntelliSense that a partial class should not be modified

As of lately I'm using quite some code generation, usually in combination with partial classes. Basically the setup is as follows:
Partial class containing generated code. Some of this code will call partial methods. The code is re-generated a lot of time. The code generator is in some cases a custom tool.
Partial methods are manually implemented in a separate file.
The problem is that when I'm using Intellisense features like "generate method", they are for some reason generated in the file containing the generated code. Obviously I don't want that.
My question is: Is it possible to generate some hint that tells Intellisense it shouldn't touch certain 'cs' files (but instead the other partial class)?
Update
In retrospect I should have noted that I'm using a custom tool to generate the code. It's not a EF or a simple transformation; there's quite a bit of logic involved in the code generation. Also, it generates a complete namespace and class structure with partial classes. The 'root namespace' is found by extracting it from the csproj file and then using the folder structure to figure out the absolute namespace (it's similar to how Linq2sql does this).
The answer suggested by xanatos (thanks!) works: intellisense sorts its operation on the name, then alphabetically sorts on the name and then picks the first item in the list. This means that you can generate a zzzz.foo.cs which (albeit a bit ugly) will work just fine. I've just ran some experiments and found out that the feature find all references returns the order that VS appears to use. As it turns out, it works like this:
Say you have a custom tool that works on the filename foo.bar and transforms it into foo.cs. The custom tool will generate the content as string and pass it back to Visual studio (that's just how custom tools work...). The result will be in a file called foo.cs.
Now, I was quite surprised to found that Intellisense does not sort it as foo.cs but rather as foo.bar\foo.cs. In other words: regardless of how you name the 'cs' output in your custom tool, you have to rename the base file foo.bar to something like zoo.bar.
While that might be a workaround, I'm hesistant to accept it as the answer, because I would have to give files in my project strange names (names have meaning...). Also, some of my custom tools have dependencies on their filenames, so that will also get broken...
Therefore, I'm still open for suggestions on how to fix this properly.

From a simple test I've done in VS2013, it seems that Visual Studio 2013 adds the method to the "first" file he finds in the Solution Explorer. So you could simply add a .something.cs to your file-name, like MyClass.generated.cs vs MyClass.cs. Be aware that the VS2013 seems to be using the "full path", with path ordering based on name. So:
Z\MyClass.cs
comes after
MyClass.generated.cs
(and Intellisense will put code in MyClass.generated.cs) even while in the Solution Explorer all the folders are ordered first.
Full example:
A\MyClass.gen3.cs
MyClass.gen2.cs
Z\MyClass.gen1.cs
This should be the order as "seen" by the Intellisense, so it will put the new classes in A\MyClass.gen3.cs.

Assuming you're talking about the EF, I always change the template file (.tt) so the filename of the auto-generated file is [classname].model.cs. This means my partial file, which by convention is called [classname].cs is alphabetically first and always seems to get picked for auto-generation.
All you have to do is find/replace all the:
fileManager.StartNewFile(entity.Name + ".cs");
With:
fileManager.StartNewFile(entity.Name + ".model.cs");
There should be 3.
This has other benefits like auto-generated files are clearly marked in the filename.
I still have no idea why they didn't do this in the first place.
If you're not talking about the EF, the same trick of using the filename to order them should work.

Arranging solution files

My C# .NET solution files are a mess and I am trying to find a way of getting things in order.
I tried to put all close files together in the same folder I am creating for that purpose. For example, I put interfaces, abstract classes, and all their inherited classes at the same folder. By the way - when I do that, I need to write a "using" statement pointing to that folder so I can use those classes in other files (also a mess I guess).
Is there an elegant way of doing things more clean, and not a list of files that I find very confusing?
Is it a good idea to (let's say) open a abstract class file and add nested classes for all the classes derived from it?
Is there a way of telling the solution to automatically set the folder "using" statements above every class I create?

The best way is when your solution file system structure reflects your program architecture and not your code architecture.
For example: if you define an abstract class and after have entities that implement it: put them into the same "basket" (solution folder) if they make a part of the same software architectual unit.
In this case one by looking on your solution tree can see what is your architecture about (more or less) from very top view.
There are different ways to enforce the architecture vision, understanding and felling of the code file system. For example if you use some known frameworks, like NHibernate, or (say) ASP.NET MVC tend to call the things in the name the technolgy calls them, in this way one who is familiar with that technology can easily find itself in your architecture.
For example WPF force you define in code things in some way, but also you need to define byb the way Model, ModelView, View.. which you will do intuitively in seprate files. The technology enforcce you to define your file system in way it was thought.
By the way the topic you're asking for, is broad known dilema/question, not resolved, cuase the code is just characters sequence and nothing else.
Good luck.

It sounds like you're hitting the point where you actually need to break things up a bit, but you're resisting this because more files seems like more complexity. That's true to a point. But there's also a point where files just become big and unmanageable, which is where you might end up if you try to do nested classes.
Keeping code in different namespaces is actually a good thing--that's the "issue" you're running into with the folders and having to add using statements at the top of your files. Namespacing allows you to logically divide your code, and even occasionally reuse a class name, without stepping on other parts of your code base.
What version of Visual Studio are you using? One little known feature of Visual Studio is that it can automatically create the using directive when you type a class name. That would eliminate one pain point.
If I was in your shoes, I'd start looking for logical places to segment my code into different projects. You can definitely go overboard here as well, but it's pretty common to have:
A "core" project that contains your business logic and business objects.
UI projects for the different user interfaces you build, such as a website or Windows Forms app.
A datalayer project that handles all interactions with the database. Your business logic talks to the datalayer instead of directly to the database, which makes it easier to make changes to your database setup down the road.
As your code base grows, a tool like ReSharper starts to become really important. I work on a code base that has ~1 million lines and 10 or so projects in the solution, and I couldn't live without ReSharper's go-to-file navigation feature. It lets you hit a keyboard shortcut and start typing a file name and just jump to it when it finds a match. It's sort of like using Google to find information instead of trying to bookmark every interesting link you come across. Once I made this mental shift, navigating through the code base became so much easier.

Try using multiple projects in the same solution to bring order. Seperate projects for web, entity, data access, setup, testing, etc.
IF the files are in the same namespace you won't need a using statement. If you're breaking your code into multiple projects you'll need to reference the other projects with using statements.
Its up to you. Break things apart logically. Use subfolders where you deem necessary.
Not sure.
Yes, but you'll need to create a template. Search for tuturorials on that.

1) Your solution folders should match your namespace structure. Visual Studio is set up to work this way and will automatically create a matching namespace. Yes, this requires a using for stuff in the folders but that's what it's for.
So yes, group common stuff together under an appropriate namespace.
2) Yes, subclasses should probably live in the same namespace/folder as their abstract base, or a sub folder of it. I'm not sure if you mean all in the same file? If so I would say generally not unless they're very very simple. Different files, same folder.
3) Not that I'm aware of. If you right click the classname when you use it you can get Studio to automatically resolve it and add a using (Ctrl + . also does this)