We Keep Coding

Having a library as a submodule in combination with a Unity game engine project

I have created a library, with its own git repo. I want to include it in a Unity3D project, but I also want to be able to adjust the library from within the working solution.
Context
Unity
Unity automatically (re-)creates its .sln and .csproj files, so
I can't set the library .csproj as a reference there. In order to use a DLL with Unity, it has to be put in a special "Plugins" folder and will then be included in the auto-generated files.
it's impractical to use Unity's auto-generated .sln for... well, anything other than the Unity project itself.
Library
The library has its own git repo, included as a git submodule. I understand that I can change the output path of mylib.csproj to point to that Unity "Plugins" folder, but then that would be saved in the library git repo - which would make the whole repo moot by having it only work for this project.
Current State
I put the library and Unity project inside a "master solution" and currently have the following structure for that:
-mylib (solution folder, but also a file system folder containing the git submodule)
-mylib.csproj
-unittests.csproj (for mylib)
-Unity (solution folder, but also a file system folder containing the Unity project)
-Assembly-CSharp.csproj
-etc., all the auto-(re-)generated files
-unittests.csproj (for the Unity project)
Goal
What I want to achieve is being able to build mylib.csproj and have its DLL automatically be put into that "Plugins" folder in the Unity project. Given the restrictions mentioned in the "Context" part, is this possible?
I am currently using Visual Studio Community 2017 to set this up, but it has to be possible to work on the end product with other IDEs, especially JetBrains Rider.

Avoid library and Unity .csproj
I now found a solution, much less involved than I thought it would be.
I added a new, empty project to the master solution - I ended up literally calling it BuildToUpdateLibraries - and then did the following things:
set the output type to "Class library"
This way, the project doesn't need a main method, so we can build without actually having any code at all - a build will just create an empty BuildToUpdateLibraries.dll.
added the mylib project as a reference
This will copy the mylib.dll to the BuildToUpdateLibraries output folder.*
Now we can freely edit the BuildToUpdateLibraries.csproj file and will neither make the libraries unusable elsewhere nor have Unity overwrite it on every rebuild.
Copying to the plugins folder
Now, the one last issue here is that when building, we get more than we want.
There is the useless BuildToUpdateLibraries.dll, but also every .dll mylib depends on*. You might actually need (some of) these, but in my case it was the UnityEngine.dll. That .dll is part of Unity and importing it again probably only leads to problems.
Thus, setting the output folder of BuildToUpdateLibraries to the Unity Plugins folder is not an optimal solution. However, as we can now freely edit the BuildToUpdateLibraries .csproj, we can just add post-build events. I added the following line in the post-build events to copy the file:
xcopy "$(TargetDir)mylib.dll" "$(SolutionDir)Unity\Assets\Plugins\MyLib"
Now when I build BuildToUpdateLibraries, it will first build mylib and then build BuildToUpdateLibraries with the mylib.dll included. Finally, it will copy the file to the Unity plugins folder.
*There is an option to not include a .dll in the output folder, but default behaviour is to copy and you would have to do that for every file.

configuring dll from bin folder in existing project

I got a c# solution developed by other developers.
This solution contains 30 projects and there is also git folder.
Every project has its bin/ folder. I have web site and class libraries. All the code has poor quality: eg bin e obj folder are included in git.
I'm refactoring the code and reconfiguring also git. I don't want to include bin/ folder in git, so I have created a dll folder in the root of every project containing libraries in the bin/ folder. In this way also references in visual studio have not any warning.
Is it right? Are there other methods?
Second question: if I have a dll in the bin folder not present in the references, would I link that too? Or can I not consider it?
EDIT:
EG: in a class library (not in umbraco project):
- bin/umbraco.dll
- bin/umbraco.provider.dll
- bin/umbraco.core.dll
- bin/lucene.net.dll
In visual studio is referenced only:
- umbraco.dll
So three ways:
Include bin folder in git and if i need to edit this project i will
understand ho configure it;
Add a dll folder in the root (and in git), copy umbraco.dll in it. So references in
visual studio are ok. But only umbraco.dll will be copied in bin
folder. And the Others? Will i need them?
Add a dll folder in the root (and in git), copy all dll files in it.
So references in visual studio are ok. And i take Others for future
uses.
I choosed 3rd solution.

I don't want to include bin folder in git
Simply make sure you have a .gitignore which declares what you don't want:
bin/
That way, you don't even have to create a dll folder. Or if you do, you can ignore bin/dll/ in that same .gitignore file (note the trailing '/' for ignoring folders in a .gitignore).
For CSharp projects, gitignore.io proposes this .gitignore file.
If I ignore bin folder and you pull, the project will not compile!
git should always ignore (big) binaries: those dependencies, as commented by Iain, should comes from an artifact repository (like Nugget) or other externa referential: external to the git source repository, which is made to track the history of sources (text files), not to store binary dependencies.
But if you must, copy only the dll referenced by your project (umbraco.dll) in a versioned folder, and see if the project compile/works. Then add the missing one.
If you have to version those binary dependencies, it is best to try and version only the minimum amount of dlls.

VS2010 generates different assembly each time compiling the project

I have some c# projects. I added post build event to those projects that copy the resulted assembly (dll) from the bin into common folder.
It appears that each compile generates assembly which is binary different from the previous even when I don't modify the project files.
It is quite a problem for me since I'm using Kiln that monitor those file and think they were modified.
I read somewhere that the dll stores time stamp of compilation which if true then I cannot fix this. If so how do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?
Thanks,
Eran.

To address the specific question of "How do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?", I have a very simple answer: ignore.
We exclude /bin and /obj from the directories which our source control will even attempt to commit. This does mean that you will need to recompile the code on each machine after each change, but Visual Studio would do that anyway for any project where the code has changed.

Don't commit the output folders of your projects.
If you want to have a Setup folder or something similar that always contains the latest versions of the assemblies created by your projects, the solution is to make sure that your post-build event is configured to run only when the build updates the project output. There is an option that is named like this:

How to compile cs files into separate dll

I have a class library and cs files which are for different objectives. One is extension class, the other is windows form control the other is asp.net control, etc.
I want to compile all these cs files into a different dll.
PS: Some of them will need more than one class files maybe.

You may try command line compilation. (Working with the C# 2.0 Command Line Compiler)
csc /target:library /out:Something.xyz *.cs

I know this sounds too obvious, but if you want to compile them into seperate DLLs, why don't you create a project per assembly? So that's a project for the extension classes, one for the asp.net controls etc...

You have to create different projects in your solution (assuming you work in Visual Studio).
Each project can have multiple (class, resource, form, etc.) files and will be compiled into different assemblies (dll's). For each project you can specify settings (assembly name, target framework, etc.).
Classes from different projects can "use" each other by making references from one project to the other. Also, different projects can specify the same namespaces so that you can structure the aplication to your own wishes.
See Structuring Solutions And Projects

All *.cs in a single class library project will compile into the same DLL, you can not split them into individual dlls. If you want a seperate dlls for each class then each should be in a seperate class library project.

.net command-line compiler multiple projects

I need to build a batch file that runs on a directory and digs inside for suitable c# projects to compile. (and compile them of course).
I don't know the name of the projects inside the directory.
I can assume all project are in c# and written in VS2008 and above (if that helps).

setlocal
SET CMD= msbuild.exe
for /R %%d in (*.csproj) do %CMD% %%d
endlocal
This will build each project into individual assemblies, with all default build properties for each project. You can specify additional properties, or an MSBuild config file to use.