For example, Rotorz’s ReorderableList project is a popular asset among Unity tools because it offers a clean, highly functional editor list. Currently, Lockstep Framework uses it for database editing and Photon has it in their codebase as well, so name conflicts crop up when they’re in the same project. How would someone go about having both Lockstep Framework and Photon in the same Unity project when they have conflicting assets in them?
While I have none of those assets, that’s very common problem with Camera classes and such too. If the source is C# and the asset developer hasn’t created their own namespace just do this:
namespace rotorzReorderableList
{
…
}// rotorzReorderableList
namespace Photon
{
…
}// Photon
namespace Lockstep
{
…
}// Lockstep
for each source file in the individual asset files. And I do the same for other assets. I try my best to avoid assets that use UnityScript because of the trouble they make. This way there will be Photon.reorderableList members and Lockstep.reorderableList members and if you actually have the ReorderableList asset already imported independently there will be rotorzReorderableList.reorderableList members too and so on.
1 Like
Thanks for the solution. I’m going to try to find some way to automate this because going through every script’ll be hell.
Actually shouldn’t be too hard to automate if you put the script that will add the namespace to add the namespace as Unity imports the assets from the package. No sure exactly when in the import process you’d get a change for your script to add it’s own edits however you’ll notice that Unity now says it deletes and cleans up the old package when you import a package even when the old package isn’t there.
Isn’t this the job reshaper was built for? (It might not be, I haven’t used it myself).
1 Like
If they are using the same version of the dependency then just deleting the duplicate files should fix things.
If they rely on having different versions then namespacing and importing will give you fine grained control.
No matter which option you go for send a note to the asset publishers so they can fix things upstream for everyone else.
2 Likes
Ya I have a major big gripe with Unity on this one. Unity will decline assets that include open source libraries that also happen to be in the asset store if you put them where the original author put them, they want you to put it in with your own stuff. Which is just guaranteed to cause problems for anyone else using the same asset. I don’t think the publishing department has any real developers there, or they just don’t care. I about went through the roof when I had an asset declined on this issue.
That’s a major hassle to delete the duplicate scripts because when you delete the duplicates any scenes and prefabs that were using the duplicates deleted would break. You would need to determine if they really matched 100% and take note of all the parameter values they are dependent on and then if they were 100% compatible replace the script on the asset or scene you are updating with the duplicate script you are keeping before deleting the original script. It’s easier to put them in their own name spaces and not subject yourself to wondering if you’ve unintentionally introduced bugs.
1 Like
Different approaches for different circumstances. Which is easiest would depend of whether interactions are primarily through code or the inspector.
Ideally everyone uses good namespacing to start with and then we don’t have any conflicts to fix.
If you had a different version of the library you it would cause all kinds of problems overwriting the existing files.
If you include your version of the library but store it in your directory and place it under your namespace it is entirely under your control, and won’t get in anybody else’s way.
Really, different circumstances doesn’t apply here. There are duplicate files and you can’t pretend to know what is in those files without thorough inspection and you sure can’t pretend to know the developer’s future plans for those files. Creating namespaces for those files is the solution.
1 Like
Except of course you’ve just bloated out compile times for no good reason whatsoever.
Name spacing three versions of the same library isn’t all roses.
And in deleting those three redundant files in those libraries for one you’ve created dependencies that the asset developers using those libraries must heed to keep from breaking your project but they know nothing about your project. You’re not saving any substantial compiler time at all really after that code is compiled and cached time stamps are the only things being checked by the build process. So really, deleting those duplicate library files doesn’t save you a lot of time and developmentally you paint yourself into a corner. But no it’s not all a bed of roses but the alternative is a crown of thorns.
Compile times are usually negligible compared to other time consumers in a Unity project.
Isn’t this is the case with either option?
Wouldn’t any changes we make to as Assets’ scripts be be rolled back when we update an Asset?
Any changes made after import are going to be fragile. These are just workarounds.
Any permanent solution is going to involve either 1) freezing at the current (modified) version or 2) an upstream modification to improve the Asset’s compatibility.
Run diff on the different versions, if they’re identical, nuke one of them. If they’re NOT identical, you have a problem, because one of the assets that relies on shared dependency may also rely on feature that is present only in one specific version of that dependency. You’ll probably have to pinpoint key differences and try to guess how important they are. Running two copies of dependency usually undesirable, because IF data between two copies end up being exchanged (Murphy’s law says it will), you’ll get very hardcore bugs that will be hard to pinpoint. Basically in this case you’ll end up maintaining a fork of both projects AND maybe of original dependency too.
2 Likes
Clearly, this would be easily resolved if Unity packages have had dependencies system, like packages in Linux distros. This way you wouldn’t have to put lib in your project, only put asset store ID where it is and when you download package, it will download dependencies as well, telling you that you have to buy those which are paid but you don’t have them.
1 Like
In order for linux dependency checking to work, someone needs first to waste lots of time resolving the dependencies and manually specifying what depends on what, because there are(were?) no automatic dependency detection programs.
In situation where PackageA and PackageB both depend on some SupportLib, BUT they need different version of it, dependency checking will fail miserably, because both versions of SupportLib will expose same symbols to the same namespace, so you’ll still have a clash.
Dealing with this kind of issue is somewhat similar to several iterations of Microsoft’s solutions to DLL hell. As far as I know, their latest idea is to install every single version of every single library software needs - based on information from application manifest. That’s quite inelegant, but it works.
Of course it’ll be up to package’s developer to specify dependencies. For older packages, nothing will change. For newer ones, devs would specify what library it needs and then keep it updated so it will work with newest version of said library.
The solution is really easy with the new Monodevelop tools (not sure if the old one has this). Right click the namespace (i.e. Rotorz.ReorderableList) → Refactor → Rename and rename it. Then import Photon and everything works 
.
1 Like