We Keep Coding

Using multiple programs in one solution

I've been writing a game for not so long now, but the code is already getting incredibly messy, because the full game is one program in my solution. Is there a way for me to split my game into multiple programs, like subroutines, but every program has its own tab within the solution? (I'm working in Visual Studio) If there indeed is a way to do that, how would I do that? I'm still a beginner, so it would be a great help if you would explain it a bit more thoroughly than usual. Thank you in advance!

Need to think the difference between solution and project.
Solution is the entire code that solves the problem you have.
Project is a part of a solution.
Segment out your code into projects. UI in one project, 'Common' stuff in another, Back-end in another, etc.
You can have the projects reference the other projects they need to get the job done (just can't have Circular references, ie. A->B->A).

Git, Two Repositories in One Solution

We have two projects written with c# on Visiual Studio, let's name them A and B. Both of these can be used as seperate products. Bu B can be integrated to A or to other products as a module. We were using SVN but now we are switching to Git with VSTS(azure devops).
We mostly develop B project while we develop A project, in the same solution.
Is there any way to set these repos seperately and commit changes of both projects in same branch with out switching solutions?
What is the right strategy we should use to manage this situation?

We solve this using git submodules. A submodule is a separate git repository inside another git repository. You commit separately in both repositorys, and the parent repository "remembers" which commit of the submodule repository it currently points to.
You can find plenty of documentation about submodules, e.g. in the pro git book. There are some pitfalls, but if you once get the workflow, it's a good approach for your problem.
Git Subtrees might be an alternative.

As an alternative to the submodules approach, you might want to consider a monorepo approach; in other words, keeping both projects in the same git repository.
There is nothing in Git (or Visual Studio, for that matter) that requires you to use the repository's root folder as your working directory when working with the code in the repo, so your current developer workflow within each individual project could probably work just fine. You also get the benefit that working on B and A in the same solution will feel very natural.
Depending on your team structure, etc, there are of course drawbacks as well (for example, without good discipline it can be cumbersome to be very many people working in the same repository), so don't see this as a "silver bullet" - see it as one of many possible solutions to your problem; evaluate them and pick one based on what seems like it would work for you (and switch again if it didn't work out).

How to share c# source between Unity projects?

We have two projects underway and want to share some classes between them. The shared source must be in a single location so when a programmer on Project1 updates the code those changes are immediately seen in Project2.
The important part is that we do not want to maintain multiple copies of the same code. i think we would agree that its simply bad practise to do so.
The only option appears to be putting the code in a class library and load it as a plugin into each project. But I don't believe this works when referencing Unity types like GameObject or transform.
In C/C++ land we could put the source in a directory and include it into any solution we wanted - doesn't seem to be so easy in Unity-land. Is their a better way to share code between unity projects?
EDIT: All projects, including the shared code, are already under source control. This is not a Source Control question, its a framework issue. (And obviously I need to write better questions!)
Lets say the directory structure looks like this...
C:\
Project1\
Assets\
CodeForProject1\
StandardAssets\
Library\
C:\
Project2\
Assets\
CodeForProject2\
Resources\
Library\
D:\
UsefulCode\
PlayerClass\
WeaponsClass\
DataAccessClass\
Can Unity reference code from other projects? Can Unity reference code outside of its own Assets folder? If so, how?

I understand exactly what you're facing, we faced the same problem here some time ago.
The idea of our shared code is to be sort of a middleware, so it is natural that it will evolve through. Our solution was to create a git module for the shared code. I know you said that it's not a source control question, but at least here in my company, create a dll was not a good solution since we are changing the shared code constantly (we tried soft-links too, but it was very painful to maintain in all machines).
Here we created two projects: one for the middleware and another just for the tests. The last one have only the gitmodule to the middleware and a bunch of unit tests. We did it to ensure that there is no dependency to other projects. Both are in the source control. So when someone wants to implement a new feature inside the middleware, he/she make it inside the tests project, and when it's done commits to both projects.
Oh! And you can make a dll with Unity types and use them normally.

How to maintain base code in separate Git repository?

Firstly, I'm new to VSTS and Git, so apologies if my terminology gets muddled!
PROBLEM
My situation is that I have a VS/C# Project (called "PluginBase") that is, essentially, "starting template" code for a plugin. Historically, I've would just copy that PluginBase project code every time I wanted to create a new "tailored/derived" build for a particular customer.
What I would like to be able to do is, as and when bug fixes are resolved and features are added to the PluginBase project, I'd like the option to migrate these changes to one or more of the "tailored/derived" builds. Likewise, if the bug was first found while developing a "tailored/derived" build, I'd like to migrate that back to the PluginBase plugin.
IDEAS
From my research, I've come across a few "possible" ways of achieving my goal, but I'm not sure which (if any) of these approaches are suitable.
Branches
Seems the common approach, perhaps the "best", but...
Means all code must be in the same repository? (otherwise can't "cherry pick" across) - which I'd prefer to avoid as this may not always be possible
Git Submodules
Seems more intended when projects are sharing a common "library" (not deriving from same code-base)
Also not sure Visual Studio fully supports this feature
Cherry Pick
Doesn't seem possible to do this from one repository to another?
Git Patch
Doesn't seem Visual Studio supports this feature yet?
So, if anyone has any advice, guidance or new suggestions for approaches I could (or should) be using, I'd really appreciate your input.
Many thanks! :)

Git Branches are definitely the way to go. The code indeed has to be in the same repository, git stores change sets and in order for a change set to be applied git has to know what happened since the code-paths split or it can not replace the correct lines of code.
Make a branch for each time you roll out a version to a customer, you can then cherry-pick across the different branches.

Build tool and project configuration. How to?

Good day experts!
I am about to start a new project and I would like to have a build script for my code. It will be a .NET project developed with VS2010.
Unfortunatelly, I have no idea how to start. What should the build script do? What are the best practices? How should I configure the projects/solutions?
Is there a how to guide for this? I was thinking about using msbuild.
Thanks

Depending on how big your product will be I would suggest using a Version Control System like TFS and when having that in place you could/should also use a build engine like TeamBuild. May look like overkill but my bet is that it is even easier than trying to figure out how MSBuild works...

Some good practices:
Aim for a "one click build" approach. Try to put all your projects for an app under a single solution. That way, you can build the whole stuff with a single command. Plus, with projects like SharePoint ones, you can create all packages during build (this requires customizing the .csproj files, but it's worthy), I have to try it but this may work
<PostBuildEventDependsOn>
$(PostBuildEventDependsOn);
CreatePackage;
</PostBuildEventDependsOn>
This also helps you in searching across "Entire Solution", so all devs can be in sync without ambiguities.
Make sure to have some good naming convention. For ex. a solution like MyApp containing projects like MyApp.Model, MyApp.View and MyApp.Presenter if you are following an MVP pattern, etc.
Which brings us to another point: aim for a layered organization of your code. A project for utilities, another for your business model, another for presenters, yet another for your UI, etc. That facilitates testing, reusability, etc.
Either case, just try with different approaches and evaluate by yourself pros and cons.