Develop Reference

How to share cs code among multiple solutions?

I'm using VS 2017 and I have a number of Utility class files (NetworkLib.cs, ImageLib.cs, etc) that I find myself constantly having to duplicate over and over again when creating new solutions.
Normally, I would just end up creating a dedicated separate solution, NetworkLib.csproj, compiling these into DLL files, and then adding a DLL reference whenever I need them in a new solution, but this isn't ideal for me.
I want to be able to use these in a shared library sense across multiple solution files but also when debugging if I step-into some function NetworkLib.Post() the debugger should step into the appropriate CS files. Additionally, if I make some changes to NetworkLib.cs from Solution1, all other solutions should pick it up on rebuilding.
I've given thought to creating a standalone Utility solution with a NetworkLib csproj, and then adding the project csproj as an existing project to each solution, but not sure if that's a good approach.
I also just read about the "Shared Project" but when I created it (in its own standalone solution) I can't seem to import it into other solutions. When I look in "Shared Projects" tab it just states "No Items Found".

Normally, I would just end up creating a dedicated separate solution,
NetworkLib.csproj, compiling these into DLL files, and then adding a
DLL reference whenever I need them in a new solution
That's the solution. You should publish your shared DLLs into a "shared" folder, somewhere on your desktop/server/network/... and reference these DLLs in your solutions. If you rebuild the shared library, every solution referencing it will automatically use the new version.
To debug external libs, you will need the .pdb file generated alongside with the .dll file. Look here for complete answer : How to debug external class library projects in visual studio?

Use "Linked items" - where the .csproj project has a soft reference to a *.cs file (or other file type) located anywhere in the filesystem, including outside of your source-control workspace or even a network share - just so long as the file exists your project will build. Use this technique judiciously because it's easy to break CI/CD systems for obvious reasons.
"How to: Add Existing Items to a Project": https://msdn.microsoft.com/en-us/library/9f4t9t92(v=vs.100).aspx

Localizable strings in Visual Studio's Shared Project

I'm trying to utilize a Shared Project concept to share the client application logic between WPF project and Android (Xamarin.Forms). In both projects I want to use the same localizable texts, therefore, it looks logical for me to move resource file (with texts) to the shared project.
The following sample is from WPF project, but the faced problem is related to shared projects, not WPF.
In my WPF project in XAML based views I access the string values as follows:
<TextBlock Text="{x:Static i18n:Strings.WelcomeMessage}" />
The file Strings.resx and its translation are located in the folder I18N, ie. they are not placed in the project's root. Therefore the generated public class Strings is placed to the namespace TestApp.I18N. When the I18N folder belongs to WPF project directly, everything works great, but if I move I18N to the shared project, the WPF application crashes with the exception:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "TestApp.I18N.Strings.resources" was correctly embedded or linked into assembly WPF at compile time, or that all the satellite assemblies required are loadable and fully signed.
If I look into compiled assembly using some disassembly tool I can see the difference between both compilations:
In the compilation where I18N folder belongs to the shared project I see the resource named TestApp.Strings.resources
In the compilation where I18N folder belongs to the WPF project I see the resource named TestApp.I18N.Strings.resources
It actually explains good why in the first case the app crashes. And it is clear what workaround can be used (I can put Strings.resx and related to the project root). But I can feeling that having resources in shared project isn't good idea, because lack of proper support. Can someone share own experience in that direction? Why resource files from shared project are interpreted a bit differently by the compiler?

what will happen to images in the Resources directory once the app is packed and how safe are those images for the app?

the Resources folder typically contains all the app images (those 16 X16) that we use to look our apps good. I haven't dealt with installation and resources folder before therefore :
When application needs to be deployed, what would happen to those images in that Resource folder?
I haven't tried this before so when I install the application where would that resource folder be saved?
If the installation creates another resource folder to keep those images, then what if a user manually deletes that folder? App would crash? what is the solution to overcome this?
I've heard some place the images in a .dll file, is this a common practice?
thanks

When you build your application, Visual Studio invokes the resgen.exe tool to convert your application resources into an internal class called Resources. This class is contained in the Resources.Designer.cs file which is nested under the Resources.resx file in Solution Explorer. The Resources class encapsulates all your project resources into static readonly get properties as a way of providing strongly-typed resources at run-time. When you build through the Visual C# IDE, all the encapsulated resource data, including both the resources that were embedded into the .resx file and the linked files, is compiled directly into the application assembly (the .exe or .dll file). In other words, the Visual C# IDE always uses the /resource compiler option. If you build from the command line, you can specify the /linkresource compiler option that will enable you to deploy resources in a separate file from the main application assembly. This is an advanced scenario and is only necessary in certain rare situations. A more common scenario for deploying resources separately from the main application assembly is to use satellite assemblies as discussed below.
All your queries is answered above
i.e.
When application needs to be deployed, what would happen to those images in that Resource folder?
I haven't tried this before so when I install the application where would that resource folder be saved?
If the installation creates another resource folder to keep those images, then what if a user manually deletes that folder? App would crash? what is the solution to overcome this?
I've heard some place the images in a .dll file, is this a common practice?
For More information
http://msdn.microsoft.com/en-us/library/7k989cfy(v=vs.80).aspx

Why my WPF program cannot run without Visual Studio?

I made a WPF program which uses SQLite. And by using Visual Studio 2012, it generates both Debug and Release version exe file. When I go to Debug or Release directory and run my exe file, e.g. MultiStart.exe, it can run normally.
But if I copy the MultiStart.exe to my Desktop and try to run it, it failed.
By several tests, I found that I also need to copy files MultiStart.exe.config and System.Data.SQLite.dll to my Desktop. And then it can run now.
But why? Do we have better solution so that I can make it run without addition files?
Thanks!

Why my WPF program cannot run without Visual Studio?
The question title is not really accurate since it's not really related Visual Studio. MultiStart.exe is dependent on configuration (MultiStart.exe.config) as well as other assemblies (System.Data.SQLite.dll). Without these dependencies the application cannot run (because that is how .NET works).
WPF doesn't necessarily need a config file to run so the question is what is in your config file that the application needs. It might be possible to move this configuration information into the code (e.g. connection string) and remove the app.config but then the values will be hard coded in the application.
In terms of dependent assemblies, instead of deploying them it is possible to embed them as resources and then use the AppDomain.AssemblyResolve Event to read the assembly from a resource (see Embedding assemblies inside another assembly for an example).
Another approach instead of embedding assemblies as resources is to merge them into one assembly. ILMerge is a popular choice for merging assemblies but I read that it can have issues with WPF assemblies (not sure if that applies to you). See Merging dlls into a single .exe with wpf for some other ideas for merging assemblies with WPF.
Note that setting PATH variables does not work because .NET does not use the PATH for resolving assemblies -- see How the Runtime Locates Assemblies for the details.
Another, option instead of copying the MultiStart.exe to the desktop is to use a shortcut on the desktop that links to the appropriate directory. Perhaps that is a simpler solution

You can also use ILMerge to merge all dependencies into single .exe file to simplify distributiuon of your application.
More detaiils on ILMerge can be found here: ILMerge on CodeProject
Example of usage: ilmerge /target:winexe /out:YourDestinationApp.exe
YourCurrentProgram.exe System.Data.SQLite.dll

Better solution that i used to do with my windows form apps is, Copy the entire folder, which contains supporting files. place it where you want. then create a shortcut of your .exe on your desktop. That always worked for me.

Because you are missing some dependency. You can open your config file and set the dependency...but I wouldn't recommend you to change config file manually.
You can also copy the dependent dll in system32 folder. ..but its only a trick because exe first search dlls in current folder than system 32 folder.

Because you're missing things from your PATH. Visual Studio is probably set to copy DLLs to the target directory on build.
You're almost certainly pulling in external libraries. Some of these are part of .NET, while others are packaged in libraries in specific folders. When you start your exe, it looks in your PATH and the current folder for everything (which includes all DLLs Visual Studio copied).
When you moved the exe to the desktop, suddenly it had no idea where those DLLs are. You haven't specifically added them to your PATH, and they are no longer in the current folder. This is why copying those DLLs to your desktop magically made them work.
Unless you stop use SQLite, there is not a way for you to not need that DLL (there are lots of ways to package/reference it though).

Why does VS2010 allow for the concept of "include in project"?

I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?

A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.

No, you don't want random files that happen to be in the project directory included in source control.

We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).

Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.

When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.

If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.

One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.