We Keep Coding

re-using functions across projects in Unity and C#

I'm quite new to C# and Unity so have mercy on me. I'm using visual studio.
I have what seems like a pretty common problem. Which is - i want to use functions i write across several projects in unity. I don't want to have to go search for the code in some folder, copy paste it into the new project, or fiddle with symbolic links or use .dll's. These are all not great solutions to the problem. Can't i just somehow create a class I can access across all my projects? Custom namespace perhaps that is not project specific? that i can simply just call at the beginning of wherever i want to use my homemade scripts.

If you don't want to build a custom DLL and the headache that comes with maintaining its versioning alongside Unity releases, consider building an AssetPackage. You can right-click in one of your projects and export a bunch of scripts that you want to be re-used in other places together as a package. When you start a new project, just load that package into it by dragging and dropping it.

If you're using git for your projects, you could add the shared code into a separate repository and add them to your projects as a git submodule.

You have 2-3 things to consider in this situation:
Ease of deployment
Whether or not you will update that code
Ease of update, if you will update it
If you just want to bring it in once, then Erik's answer should be simple enough.
If you want to keep things as an updated library though, you will need another method.
Symbolic links as you mentioned would be the best, or DLLs. However, with this, you'd run the risk of breaking your other projects if you ever modify the common lib from inside your project.
Another option would be to have a separate VCS (git, svn, etc) inside your project for your common code. This way you can update if/when you want, you can roll-back if something breaks, and you can even fork your "common" code to make a project specific change.
Since OP mentioned it, in this case, OP could specifically use Git Submodules or simply add a second Git project and add that sub-Git to the parent's .gitignore file

Solution Output Directory

The project that I'm currently working on is being developed by multiple teams where each team is responsible for different part of the project. They all have set up their own C# projects and solutions with configuration settings specific to their own needs. However, now we need to create another, global solution, which will combine and build all projects into the same output directory.
The problem that I have encountered though, is that I have found only one way to make all projects build into the same output directory - I need to modify configurations for all of them. That is what we would like to avoid. We would prefer that all these projects had no knowledge about this "global" solution. Each team must retain possibility to work just with their own sub-solution.
One possible workaround is to create a special configuration for all projects just for this "global" solution, but that could create extra problems since now you have to constantly sync this configuration settings with the regular one, used by that specific team. Last thing we want to do is to spend hours trying to figure out why something doesn't work when building under global solution just because of some check box that developers have checked in their configuration, but forgot to do so in the global configuration.
So, to simplify, we need some sort of output directory setting or post build event that would only be present when building from that global, all-inclusive solution. Is there any way to achieve this without changing something in projects configurations?
Update 1
Some extra details I guess I need to mention:
We need this global solution to be as close as possible to what the end user gets when he installs our application, since we intend to use it for debugging of the entire application when we need to figure out which part of the application isn't working before sending this bug to the team working on that part.
This means that when building under global solution, the output directory hierarchy should be the same as it would be in Program Files after installation, so that if, for example, we have Program Files/MyApplication/Addins folder which contains all the addins developed by different teams, we need the global solution to copy the binaries from addins projects and place them in the output directory accordingly.
The thing is, the team developing an addin doesn't necessary know that it is an addin and that it should be placed in that folder, so they cannot change their relative output directory to be build/bin/Debug/Addins.

The key here is that team is responsible for a deliverable. That deliverable is a collection of binaries. So the "global" solution ... or "product that uses the deliverables from teams" is interested in ensuring that all of the 'current deliverables' work together. That is, that you have a deliverable from the collaborative effort.
So this begs a few questions. Do the team deliver what they consider to be a 'release'. This may be automatic in the build system. If it builds and all tests pass then publish it.
What you are looking for is a team publishing or promoting a release. The source code is how you got there, the binaries are the result. Each team controls what binaries it considers to be a release (this may be automated by the build system).
Not exactly what you asked, but I hope it is the answer that leads to the right questions to give good results.

One very simple way would be to create the solution. Include all the projects and add a project (or more) to handle the global solution build tasks. The projects in the global solution should then have a reference to the projects they need and then let Visual Studio handle how to get the binaries from each project. They will (under normal circumstances) be copied to the output folder of the build project. So the project added specifically for the global build tasks would have a copy of all the referenced projects
Another way would be to create a global MSBuild script that references the rest of the build scripts. Each project is on it's own a MSBuild script
EDIT
From the comments it would seem that there are two categories of projects. One that needs building and one that does not.
For those that need building reference them as projects in the aggregating project for those that do not require building add them either as references or add the dll as resources.
Using the later change the property of the Build action to None and copy to output directory to Copy if newer
In both cases you now have all dll's in the output directory you can then have a post build action on the aggregating project moving the dlls that should be in a specific folder (ie not in the output folder)

Have a look at the practice of Continuous Integration and the usage of a Build Server with scripted builds. This is an indispensable instrument when developing different parts of an application as a team, and your problems are a great illustration of the reason why.

You've not mentioned if you use a Version Control system. I've found in practise that each developer maintains his/hers/their teams configuration and builds locally on there machine, since you don't check *.suo or *.user files most of the personal configuration only affects the individual team member.
On a completely seperate machine check-out the same code from all repositories and compile the project on the build machine (this can be completely automated). This maintains your build servers independance.
Don't worry about it being a "Solution". You can easily build multiple solutions one after the other.
Since the output path is relative (and probably "bin\Debug") it'll get built wherever you check it out to. If you want all the binaries in the same output folder you could tweak the output path on every configuration to match. Something like "....\bin\Debug" (obviously this affects where the projects get built to on the local machines but it might not matter). That way multiple projects would get built the same target output.
You could also include a seperate setup build on the build server which isn't on each developers local machine to package up the final product.

Updating classes used in multiple projects?

I have a few classes that are abstracted in a way that I can use them in multiple projects. I'm always working on these classes, optimizing, adding, etc. So when I optimize something in one of these classes, I then need to copy that new version into every project I remember using it. This isn't a very good way of doing it, but is there a better way?
Thanks

Put these base classes in a single project and share this project between your different solutions as an referenced class library. This way you will not have to copy / paste anything between projects or solutions and everything should always be up to date.
You could even set-up a local NuGet feed so you can use NuGet to retrieve this shared project as a reference in a well structured and managed way.

Instead of manually copying the updated classes to every project that uses them, create a Class Library project and reference the compiled file in every project that uses the classes. Organizing your classes like that will help you to follow the DRY ("Don't repeat yourself") principle.
If you need to reference files instead of compiled libraries, however, you can reference a file as a link so that multiple projects refer to the same file without copying it to each solution folder. To do that, right-click on your project, choose Add existing item..., browse to the .cs file, and choose Add as Link from the combobox in the right lower corner.

How about if you extract the classes into a separate project, and add a reference to this project in every project you are using?

It is a bad idea to copy paste file throughout the application. To avoid these repetitions you can either:
make a link, if the amount of file is really small . In the Solution browser of Visual Studio, right click, Add Existing file, chose your file and in the split button, choose Add as a link
create a separate project and reference this project wherever is is necessary if the amount of files not tiny.

Create a base-lib and build it to a "shared" location. Add a reference to it in you project. It will keep the other projects smaller and will be faster to build.

Question when adding a project to a Visual Studio solution

I created a brand new blank Visual Studio 2010 solution, and added an existing C# Project to it. I built the solution and it compiled correctly.
But when I go the solution folder, I see that the imported C# project is not physically in that folder. It seems it only references the project to wherever it is.
Is this intended? Should I even worry about this?
How can I create a physical import, meaning the project is copied to the solution folder?

How can I create a physical import, meaning the project is copied to the solution folder?
If you want to do this, copy the project to the solution (outside of VS), then add the local copy directly.
The default behavior allows you to share a project between two solutions. This is occasionally useful (if handled with care).

'How do I create a physical import?'
You don't - you're adding a project to the solution which will always result in referencing it in-place. In order to structure your solution you need to copy or move the existing project to the desired folder, created any desired Solution Folders to match the physical structure and then Add existing project as needs be.
The other alternative is to Add new project and then copy all of your project data over from the existing one but this will be prone to errors at some levels.

Adding an existing project always makes reference to the original. That makes sense in a lot of cases. If you want to use the project in a number of solutions and you want to make sure that they are always using the same version then you have the choice to either just reference the compiled library or have it available in each solution. If you do have it available in each solution then the risk is that you will make some mod of it in one solution that breaks the others. I am pretty good at doing this!
As mentioned already if you want to modify that project and don't mind if it gets out of sync with other versions of it then you need to copy it into your solution folder and then add it from there.
The version control software I use pretty much forces me to do that as it does not like code that is not located inside the solution tree.

Moving projects files in a .NET project

It's not code-related but IDE related. I'm working on a .NET solution with about 35 different projects. These projects need to be re-organized into a new folder structure. Why? Because about 10 of those will be removed and the rest will be divided in more logical units.
One way to do this is by creating a new solution, Drag&Drop the projects into a new folder tree within the Windows explorer and then just add them to the new solution.
To be honest, that sounds dumb!
Is there a way to just move projects into different folders from within the IDE? I've tried to "save as" the projects but the IDE won't accept a different folder.
It's irritating but because there have been a few wrong choices in folder names, I'm now stuck with those names.
Example: Right now I have a project main folder which contains child folders named "Client", "Server", "Business", "Database" and whatever more. Within those child folders, there are more child folders, each a three-digit number. Within each numbered folder there's a project which is named in some logical way, like Company.Business.Customers with additional logic within this project.
The problem is that not all projects now follow this naming convention and I consider it obsolete.
A project like Company.Business.Customers should just be in a folder named Company.Business.Customers in the project root so it's easier to recognize. The name already makes it clear that it's a business class for this project. The clear division within client classes, business classes and whatever more just needs to be arranged within the solution, but I want to flatten the file structure. (And remove some obsolete projects.) Basically, I'm not refactoring, I'm just cleaning up.
VS2008 doesn't seem to have such an option, though...

Fire up notepad.exe and open the .sln file. And start Windows Explorer, navigate to the solution directory. Observe how the .sln file content matches the solution structure. Edit the entries, make the corresponding change with Explorer. Backup first.

I don't think there's an easy answer here. Your main problem is going to be that Visual Studio (or .NET) doesn't care if you have classes that belong to a different root namespace sitting in a project.
So if you have a project called Project.BusinessObjects and another project called Project.DataObjects there is nothing stopping you from putting a class called Project.BusinessObjects.User into the Project.DataObjects project.
I don't know of any way of doing all of this without a lot of manual work. Resharper will help quite a bit if you use the 'namespace rename' feature, but you're still gonna end up with a lot of grunt work.

Also, be VERY wary of doing this in conjunction with version control systems. You have to know your version control system really well to know how it's going to react to such major refactoring.
Other than that, what you are describing doing is not all that difficult. You do have to edit the solution files and maybe the project files by hand, and you might need to remove a project from a solution and add it again when it's under the right directory.
I would make a backup, and then refactor away. I think it is a mistake to think that you can do everything you need from the IDE, though. And if you do what you describe from the IDE in a source control system that uses the old Visual SourceSafe API, you will certianly (guaranteed) mess up your bindings, that API is just not made for moving (or renaming, for that matter) files around in the way you describe. The best way to do this under that scenario is to remove all source control bindings and then re-add the reorganized solution back in.
It's not that difficult, you just have to prepare (do a backup) and experiment until you get it right.

I don't think there's any way to do this from within Visual Studio, and as #gmagana points out it's going to be very difficult to do if the files are under version control.
However, it is possible to do it manually.
Start by creating the new, desired folder structure - ignore the .csproj files and solution files for now, and more the .cs files you're interested in into the new structure.
Now, fire up Visual Studio, and create a new, empty project. If you have different types of projects, you might want to create one new, empty project for each type. This will leave you with an empty .csproj file, and a .sln file with just one project.
Copy the empty project file to where they're needed, and rename them as needed. You can edit them and change the Assembly name and default namespace if you want, or wait until you're done and change the settings with Visual Studio.
Finally, edit the .sln file, and remove the Project section. Copy the empty .sln file to where you want it, and open it up in Visual Studio. Now go and add each of your existing projects to the new solution.
Within each project, click the "show all" button, and start including all the files you've copied into the project structure. Resolve missing dependencies, change the namespaces and assembly names for the project, and make sure that the code files don't specify a namespace you don't want. Repeat until done.
Once you get the new solution to build, it will be helpful to open up the DLLs in Reflector in order to ensure that you haven't missed any namespace declarations in the code file - if you're trying to get to a point where there's a 1-1 correspondence between the DLL and the namespace, or even ensuring that no namespaces are split between DLLs, Reflector is your friend.
Good luck.

I've used the following solution to solve my problem:
I started with a new, empty solution in a new folder.
For every project that needed to be moved, I used the Windows explorer to create a child folder in the solution folder, this time with the proper name.
I copied the projects from their original location to their new folders.
I added all the (moved) existing projects from their new locations.
In the Solution Manager, I renamed the projects to a better name.
I fixed the project properties and other settings for all projects.
This did clean up the whole project quite nicely. I then added the whole project to Vault (Version Control System) and once it was in the VSS, I deleted the folder again (actually, just renamed it first) and retrieved it back from the VSS system so any obsolete binaries and other garbage was gone too.
It's a lot of work, but the result turned out exactly what it needed.