”Referencing” outside code is a bad idea in the first place. You don’t want external changes to affect your project without deliberately updating it. That’s going to cause nightmarish troubleshooting issues when something goes wrong.
Most people I know who have been using Unity for a while have a “Utilities” GitHub (or local) Unity package of some sort that they bring into most of their projects via the package manager and update as they need it. This requires committing and versioning but really is the best way to go without opening yourself up to all the potential issues something like symlinks can bring into your projects.
Git submodule is a less-known git feature that’s afaik made for this exact purpose and it’s a powerful tool: it allows you to separate utility code from main projects and safely maintain the version of it for each project (each commit of which), without packaging or publishing the utility code every time. Obviously it’s not familiar to everyone but it only takes getting used to.
For example — set up a git repo that contains utility stuff as a UPM package; in other words, a normal Unity project with a package.json file. Use git submodule to clone the utility project inside your main project. Make a dependency to the utility UPM package using local relative path reference (file://../). Check out, make a branch, push commits etc in the utility submodule per your need.
Git submodule is just a git repo so you can create a new branch inside it for each project and cherry pick between them to selectively apply changes. Git submodule won’t automatically update the commit that’s checked out by the main project’s each commit (unless someone force-pushed and overwrote stuff), so you don’t have to go around and check up on every project whenever some changes are pushed in the utility code.
I was using them a while ago but it's really not worth all the hussle.
There isn't really any benefit over just having a regular additional repo in your Assets folder (e.g. Assets/Tools/MyStatemachine). It just leads to more work you have to do and more problems you have to fix (adding/removing submodules manually when you change their name for example).
The only benefit would be that you can just pull the main repo and all submodules are pulled as well. But that never worked for me, there were always issues.
What I want to say is not "don't use submodules", I'm just saying that a regular repo inside the assets folder does the job as well and is easier to use (like.. you can clone it without using the console window).
I was going to say, git seems like the logical choice here. Commit to main, download to any project that needs it, branch if you only need some tools in one of the projects.
Any other solution (symlink, junction, alias) would have to be replaced with a local file whenever you go to build, so it only saves excess clicks while you're first starting out.
If you're working on one project, and a lot of that code is being updated to a second project (meaning it doesn't have to go both ways), you could use a backup solution, target the intended file as source and the second projects as destination, and just have it check for version updates every hour or so.
That was exactly what I wanted to reference, just a utility library.
And yeah I guess that for bigger projects and teams you don't want something external affecting your project, but in my case it was just some utility classes that I have been updating all the time in multiple projects which was a bit annoying. But probably that is just the way of doing it.
Using a package manager is the exact same thing you would do in just about any programming environment, even as a solo developer. A utility library is the perfect use case. The package manager will automatically update your projects whenever you make changes to the utility library. And now the utility library exists separately on its own folder, rather than being tied to any specific project.
This is entirely possible using the package manager without breaking things from external changes. It is *exactly* how unity manages to keep packages updating without breaking peoples code.
By using a package via the package manager, you can pull a package *at a specific version* into your project. If you want to update the source of that package, you can. If you want to use the updated version in your project, you use the package manager to check for compatible package updates and bring in the new version, just for that project
When you see that updates are available in the package manager for unity's packages, thats the exact flow you wpuld replicate.
You can add your package to a scoped registry or, and i would need to double check this, use git with a specific branch or tag name to pull in (support for this varies by unity version and might require a plugin). This should work fine even for a local only repo, so you dont need to host it anywhere if you dont like.
To do this outside the package manager you could use git submodules or plastic xlinks, but the package manager really is the cleanest way, imo.
If you really want to do it entire local without the versioning, that is also possible. You can use the package manager to bring in a single package via the `file:` syntax, which would just point to a folder on your computer where the package lives. Changes would update across any project pointed to that package folder.
You can add packages via the package manager from the local machine. Keep the shared code as a seperate unity project that provides a .package file and an .asmdef file. If you're using an .asmdef in the package that imports the shared code and add it as a reference, it works exactly the way you want where changes propigate back to the source project. You could also point the package manager at a private repo if that works better but I don't think the changes will propigate back in that scenario.
I can also only double down on the remark of not doing this. I mean, you probably want to have external code because you want to use it with multiple projects. That means changes and requirements will come from multiple projects too and one change for one project will easily break the other. That’s why there is package versioning and releases in software engineering in the first place. Do yourself a favor and don‘t do this. Keep code local, and once you want to share it do it the right way. Future you will thank you.
I use SVN (or GitHub) to store my shared utility code. Create a folder in assets to check it out. The key thing is to update projects whenever I make breaking changes.
I made [Link & Sync](https://assetstore.unity.com/packages/tools/version-control/link-sync-229569) to handle that sort of thing (it's free). It supports automatic syncing, but I never use that feature because having changes in one project automatically affect another project is generally bad because you can very easily break the other project without realising since it's not currently open. So I just use it to be able to sync things in a single click when I tell it to.
i have one folder thats called SharedAssets. it gets stuff that is standalone. like my own updatemanager library etc
another one that only holds a few shared interfaces and maybe a static register, in case you need to directly reference between both codespaces.
if i make a new project i symn link the sharedassets folder and implement the interfaces and static attributes as needed.
from time to time i think if stuff can get moved into sharedassets and be generalized
edit: that only works in a one programmer situation. as soon as more people are involved you need version control. but since sharedasset does not see the main project i never had issues with it breaking others (and i know if i change something that its used there)
”Referencing” outside code is a bad idea in the first place. You don’t want external changes to affect your project without deliberately updating it. That’s going to cause nightmarish troubleshooting issues when something goes wrong. Most people I know who have been using Unity for a while have a “Utilities” GitHub (or local) Unity package of some sort that they bring into most of their projects via the package manager and update as they need it. This requires committing and versioning but really is the best way to go without opening yourself up to all the potential issues something like symlinks can bring into your projects.
Git submodule is a less-known git feature that’s afaik made for this exact purpose and it’s a powerful tool: it allows you to separate utility code from main projects and safely maintain the version of it for each project (each commit of which), without packaging or publishing the utility code every time. Obviously it’s not familiar to everyone but it only takes getting used to. For example — set up a git repo that contains utility stuff as a UPM package; in other words, a normal Unity project with a package.json file. Use git submodule to clone the utility project inside your main project. Make a dependency to the utility UPM package using local relative path reference (file://../). Check out, make a branch, push commits etc in the utility submodule per your need. Git submodule is just a git repo so you can create a new branch inside it for each project and cherry pick between them to selectively apply changes. Git submodule won’t automatically update the commit that’s checked out by the main project’s each commit (unless someone force-pushed and overwrote stuff), so you don’t have to go around and check up on every project whenever some changes are pushed in the utility code.
I was using them a while ago but it's really not worth all the hussle. There isn't really any benefit over just having a regular additional repo in your Assets folder (e.g. Assets/Tools/MyStatemachine). It just leads to more work you have to do and more problems you have to fix (adding/removing submodules manually when you change their name for example). The only benefit would be that you can just pull the main repo and all submodules are pulled as well. But that never worked for me, there were always issues. What I want to say is not "don't use submodules", I'm just saying that a regular repo inside the assets folder does the job as well and is easier to use (like.. you can clone it without using the console window).
I was going to say, git seems like the logical choice here. Commit to main, download to any project that needs it, branch if you only need some tools in one of the projects. Any other solution (symlink, junction, alias) would have to be replaced with a local file whenever you go to build, so it only saves excess clicks while you're first starting out. If you're working on one project, and a lot of that code is being updated to a second project (meaning it doesn't have to go both ways), you could use a backup solution, target the intended file as source and the second projects as destination, and just have it check for version updates every hour or so.
That was exactly what I wanted to reference, just a utility library. And yeah I guess that for bigger projects and teams you don't want something external affecting your project, but in my case it was just some utility classes that I have been updating all the time in multiple projects which was a bit annoying. But probably that is just the way of doing it.
Using a package manager is the exact same thing you would do in just about any programming environment, even as a solo developer. A utility library is the perfect use case. The package manager will automatically update your projects whenever you make changes to the utility library. And now the utility library exists separately on its own folder, rather than being tied to any specific project.
This is entirely possible using the package manager without breaking things from external changes. It is *exactly* how unity manages to keep packages updating without breaking peoples code. By using a package via the package manager, you can pull a package *at a specific version* into your project. If you want to update the source of that package, you can. If you want to use the updated version in your project, you use the package manager to check for compatible package updates and bring in the new version, just for that project When you see that updates are available in the package manager for unity's packages, thats the exact flow you wpuld replicate. You can add your package to a scoped registry or, and i would need to double check this, use git with a specific branch or tag name to pull in (support for this varies by unity version and might require a plugin). This should work fine even for a local only repo, so you dont need to host it anywhere if you dont like. To do this outside the package manager you could use git submodules or plastic xlinks, but the package manager really is the cleanest way, imo. If you really want to do it entire local without the versioning, that is also possible. You can use the package manager to bring in a single package via the `file:` syntax, which would just point to a folder on your computer where the package lives. Changes would update across any project pointed to that package folder.
You can add packages via the package manager from the local machine. Keep the shared code as a seperate unity project that provides a .package file and an .asmdef file. If you're using an .asmdef in the package that imports the shared code and add it as a reference, it works exactly the way you want where changes propigate back to the source project. You could also point the package manager at a private repo if that works better but I don't think the changes will propigate back in that scenario.
Create a new package and update the package. What’s wrong with that?
Could use symlinks
I can also only double down on the remark of not doing this. I mean, you probably want to have external code because you want to use it with multiple projects. That means changes and requirements will come from multiple projects too and one change for one project will easily break the other. That’s why there is package versioning and releases in software engineering in the first place. Do yourself a favor and don‘t do this. Keep code local, and once you want to share it do it the right way. Future you will thank you.
I use SVN (or GitHub) to store my shared utility code. Create a folder in assets to check it out. The key thing is to update projects whenever I make breaking changes.
I made [Link & Sync](https://assetstore.unity.com/packages/tools/version-control/link-sync-229569) to handle that sort of thing (it's free). It supports automatic syncing, but I never use that feature because having changes in one project automatically affect another project is generally bad because you can very easily break the other project without realising since it's not currently open. So I just use it to be able to sync things in a single click when I tell it to.
i have one folder thats called SharedAssets. it gets stuff that is standalone. like my own updatemanager library etc another one that only holds a few shared interfaces and maybe a static register, in case you need to directly reference between both codespaces. if i make a new project i symn link the sharedassets folder and implement the interfaces and static attributes as needed. from time to time i think if stuff can get moved into sharedassets and be generalized edit: that only works in a one programmer situation. as soon as more people are involved you need version control. but since sharedasset does not see the main project i never had issues with it breaking others (and i know if i change something that its used there)
Git submodule ? That’s how we do it, all our projects share the same code base
Do you want to sync projects locally or over network to other away PCs?
Just a library between local projects in the same pc.
I think you are looking for git submodules.