Greetings scripting forum,
I would like to have some kind of external library include path where I can implement and update API-like structures and update multiple projects at a time.
I am given to understand at this point that Unity doesn’t want to play, and that the only thing like this I can get is packages which I will need to import on a per project basis. Is this indeed the case, or can I still have my dream of a common API across multiple projects?
Are you talking about a shared set of script/code APIs used across projects? Or a shared ‘api’ of prefabs and other non-script assets?
The former you can do easily by compiling the code to a .NET assembly DLL and copying that into the Assets folder of each project you want to use it from. If you mean the latter, exporting/importing asset packages is the only way I know to do it.
If you have Pro you could use Folder structuring and an SVN to update your Plugin and Library files for each project it is attached to. That way each individual project can be updated whenever you make a change to the Core Lib. Then also Update to the templates folder so that any new project can get the most recently updated branch.
It’d probably be a pain to setup, but be pretty nice afterward.
As well as the more “standard” methods of doing this type of thing, you can always brute force it with symbolic or hard links in the filesystem if you want to be perverse.
I’m talking about scripts, but both would be nice. Anything that requires pushing to individual products is something I’m trying to avoid. It sounds like you’re giving me a no on both counts.
Ntero:
Ty for the info, sounds like some research. That might be a reasonable compromise.
xomg:
Actually, from what I can tell this is not possible. Maybe it’s a macosx thing, but Unity will not follow any such links. If that were an option, I would regard it as the best one.
Edit: Thanks to all who replied.
That’s interesting, and probably due to some file system abstraction layer that they’ve got going on to make it work cross-platform. Did you try a hard link, however that works in OSX?
Hard links work, but only until you re-compile the external DLL and the link gets broken… The ‘best’ option would be a build automation step that, post-build, copies the resulting DLL(s) into all the projects that need it, but that’s pretty kludgy 
A slightly cleaner workflow, assuming the scripts are stored in a VCS such as SVN or GIT, is to keep a checkout of the scripts directly inside the Unity project and forgo the DLL altogether. You can always switch to a DLL in the final pre-release stages, when the shared library code shouldn’t be changing much.
Note, however, that Unity doesn’t allow more than one script with the same name (an artifact of the limited support for .NET namespaces), so you have to make some compromises in your class/file naming using this approach.
Interesting. Thanks for this, I may indeed go this route.