We Keep Coding

Trying to better understand Shared Projects and using them in different solutions

Even though Shared Projects have been around since Visual Studio 2015 (maybe as early as VS 2013 update2), I've only recently learned about them. Today I spent time trying to learn how to use them following a tutorial I found Shared Project: An Impressive Feature of Visual Studio 2015 Preview. However, the one thing the author did in that tutorial, which won't work for us, is he created the Shared Project and 3 other projects, all within the same solution. Of course, you can do that, but in practice we're likely to want to create a Shared Project in some solution, and then as time goes by, include that Shared Project in other solutions.
So what I did is instead of putting the Windows Forms application into the same solution as the author of that C# Corner post did, I created a new solution with a Windows Forms project in it, then I tried to add the Shared Project from the first solution. First, I tried adding the .sln file. That failed miserably. Then I tried adding the .shproj file to the second solution. That failed miserably as well.
Next I shared here on SO for ways of addressing this. I found 2 posts: Adding references in a shared (.shproj) project and How do I add a reference to a Shared Code project (.shproj) from another project. The second one gave me an idea. I decided I would simply add the Shared Project, from the first solution, to the second solution by clicking on the second solution within Solution Explorer, then doing a "Add Existing Project". That worked.
But I wonder, is that the way you're supposed to use Shared Projects? If so, it seems to me as though I could just as well created a simple class library in the first solution and then added that class library project to the second solution. Is there something about Shared Projects that make them inherently better to use, if you add the Shared Project to a different solution, instead of just adding a regular class library project to a solution?

A class library compiles into its own DLL and your original project references that DLL, whereas a project using a Shared Project will compile into a single assembly. One scenario I could think of with shared projects is that you can have single code base but has platform specific code sections marked by directives.

There is a good video on this subject even though it's being explained in the context of xamarin they do a good job i think.
https://www.youtube.com/watch?v=G5ov0gLZWgQ
Personally I I would always go with PCL (portable class lib) rather than SAP (shared project). I use shared code projects as documentation container in my projects. The project green icon stands out really well. I keep everything there from markeddown doc files to stored procedures and etc.

Is there a way to reference a c++ project from a c# project in the same solution?

In my solution we have projects both in c#, that controls some GUI and networking work, and c++, that manages some hardware interactions. In my c# project I have the proper PInvokes and am able to use the c++ output dll with no issue but in order to do it, I have to manually copy the output dll to the build directory or create a build script that manages the copy.
My issue with this method is that the solution, in reality, has many many projects, something like 150 at the moment, covering c++, c, c#, and vb.net. We create and delete projects all the time and managing the copy scripts is becoming a major pain. Especially since not all of the projects rely on each other and we have like 20 different build configurations.
Is it possible to simply have the c# project reference the c++ project and automatically copy the project output the same way it does with other managed projects without using post build scripts?

Well, the way I do it and have always done it is by obviously using Visual Studio, and assuming this C++ projects are VS projects you can easily create a VS Solution containing multiple projects that you can organize with "Solution Folders". The organization of your projects inside the solution is really up to how you want to organize it. It resembles a file system with nested folders. Needless to say that you can host projects in different languages such as C++, C#, VB...I'm not too sure if you can include a C project or not, that's out of my expertise.
See a screenshot below of a solution I created to demonstrate this...
Notice that "Business" has a nested solution folder (Utils) which contains a C++ project (ERM.CPPLibraries) and a VB project (ERM.VBLibraries). Then if you reference projects within the solution (Right click -> Add Reference), you will not need to copy the output assemblies everytime you compile your solution (or project(s)) VS is smart enough to resolve all dependencies, resolve them and update them.
Hope it gives you an idea
Edit based on comment
In simple words...No, it's not possible to reference a unmanaged project from a managed project in a VS solution. You can reference DLLs but not projects itself

Build every Microsoft Visual C# 2012 file in separate .dll

I'm making mods for some game that are created through C# .dll files. I started a C# .dll project in my Microsoft Visual C# 2012. However, I want to make several .dll files - specifically one per .cs file.
How would I do that? I want to avoid making too many projects while every project contains just one file.

What purpose of this? To easily decompile and replace some class? I don't see any profit from this.
Use .cs-files and dynamic (re-)compilation and (re-)loading when needed. Several projects do this. It's quite comfortable way. But not troubleless...
Or make some API that will define what MOD must do and what MOD can do. Most projects that use mod's do this.

Creating a dll containing many namespaces

Suppose I have a bunch of namespaces:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Each namespace has its own project and each project creates its own dll file:
SuperNamespace.namespace1.dll
SuperNamespace.namespace2.dll
SuperNamespace.namespace3.dll
SuperNamespace.namespace4.dll
...
SuperNamespace.namespaceN.dll
I like this design because it allows developers to use only the code that they need. Sometimes having a bunch of dll's can be a bit cumbersome and annoying. I would like to create a SuperNamespace.dll which contains all of the namespaces. That way, a developer has the option to use what he/she needs or just take the big dll file, i.e. SuperNamespace.dll containing all libraries:
SuperNamespace.namespace1
SuperNamespace.namespace2
SuperNamespace.namespace3
SuperNamespace.namespace4
...
SuperNamespace.namespaceN
Is there a way to do this in a C# Visual Studio 2010 solution?

I would simply create one large project with all sources unless there are other reasons to keep separate assemblies.
In later case I'd still create one project that includes everythin in addition to small projects before going ILMerge route as Mith Wheat suggested. You can easily create new project from a lot of files using File->New project from source (may need higher version of Visual Studio for that, defintely not Express ones).
There is no restrictions how many C# namespaces can be used in in one assembly (DLL). You can find many examples in .Net framework itself - i.e. many of System.* namespaces come from the same assembly.
Opposite is true also - same namespace can come from multiple assemblies.
Note that in compiled code there is no such thing as "namespace" - it becomes part of class/struct/enum name.

How To Include Classes From Another Namespace In Assembly Instead of Writing Them Into A Separate DLL File?

I have a C# project with two namespaces. A GUI (Stoff3GUI as namespace) with the GUI xaml and .cs files, marked as starting object and a Library (Stoff3Lib as namespace) with all the classes doing the actual work.
Now, when I compile my code, I will receive a .exe file Stoff3GUI.exe and a .dll Stoff3Lib.dll. In Visual Studio, both namespaces are part of the same Project.
How can I compile the classes from the Stoff3Lib into the .exe file without producing a separated .dll file?
Edit:
Changed the xxx to my project name Stoff3 for better understanding.

If both namespaces are part of the same project, you should already only end up getting a single assembly.
This can differ with web project setups (various different flavours of web projects create assemblies in times and manners I've never understood) but for standalone executable projects, it really is "one project produces one assembly" in all cases as far as I'm aware. Double-check that you really only have one project - for example, you shouldn't have any references in the project to an xxxLib assembly.

I'm not entirely sure what you are doing here. It sounds like you might have a single 'Solution' with two projects My immediate thought is just to move the classes you want into the the GUI start project and delete the other project.

I believe what you really have is 1 Visual Studio solution with 2 projects.
Since a picture is worth 1000 words, and just to clear up terminology, here's what that looks like in VS2012:
The output of this solution is exactly what you describe:
TwoProjects\Stoff3GUI\bin\Debug\Stoff3GUI.exe
TwoProjects\Stoff3Lib\bin\Debug\Stoff3Lib.dll
The easiest way to accomplish what you want is to have a single VS project that contains 2 different namespaces. It's good practice to add folders that match your intended namespace structure, in your case Stoff3GUI and Stoff3Lib:
When you compile this solution, the output will be a single EXE, but you still maintain the separation of model and view namespaces very clearly in your folder/file structure:
OneProject\bin\Debug\OneProject.exe