koobas.hobune.stream
Unity overwrites files with the same name but in different namespaces on package import?
I have a couple of files that I use all over the place - Mainly utils classes.
So let's say I'm working in project1, and have a script layout of:
Scripts
... Utils
..... Utils.cs
..... Helpers.cs
The classes are defined like so:
public static class Helpers
{
...
}
public static class Utils
{
...
}
In another different project, I also have files of the same name (they were originally the same as from the previous project, but modified more to suit the second project)
Scripts
... Utils
..... Utils.cs
..... Helpers.cs
BUT: in the second project, they're defined in a separate namespace:
namespace Project2.Utils
{
public static class Helpers
{
}
public static class Utils
{
}
}
Now I'm done working on Project2, and want to export the project as a package, and import it to project1. When I do that, Utils.cs and Helpers.cs from project2 overwrite the corresponding files in project1 even though they were in a different namespace! - This ruins things! Not cool, not cool!
Is this how this stupid thing works? should I be making my custom importer? ahh.... everything has to be custom made doesn't it? is there a tool for this, people use that I don't know about?
This doesn't happen if I manually copy the files over (don't use the import tool)
Thanks.
EDIT:
This is me in project1, importing project2 - the stuff that are not marked with "new" - should be marked!
And look at the import path - it's wrong! it should be "Complete Delegate/Utils/..." instead of "Scripts/Unapplied/..." which why things are getting ruined.
Hey Vexe,
Unfortunately, you're talking about two different things: files vs. namespaces.
Think of it from the computer's perspective, a file is a file. It doesn't care what's in the file. So when you have 'C:/YourProject/Scripts/Utils/Helpers.cs' that's just a file. If you drop another file with the same name ('Helpers.cs') into the same folder, you're asked to replace the whole file. There's no merging, splicing, or anything fancy.
Namespaces help to logically (not physically) organize classes. They are virtual buckets, that aren't restricted to a file structure (in most cases). Your OS doesn't know anything about this. It just knows about files.
Hello Everyone, please read our question carefully first. because you have some misunderstanding about the issue. I know this "if you drop another file with the same name ('Helpers.cs') into the same folder, you're asked to replace the whole file."
$$anonymous$$y Issue is: $$anonymous$$y packages are created with different root names with unique namespaces, scripts are located in different subfolders, but during import, all moved to the Scripts of the first one package. can you please help me how to solve this issue? Thanks, Thanks,
I believe imports go by metadata. It's likely that, due to previous imports and exports, these files have the same metadata ID in both projects. In project1, try making a copy of ColorDuo.cs and delete the original. Then export this copy and import it into project2.
Importing a package does not validate the contents of that file at all. It is a simple process that copies files from the source paths into your project.
As such, it cannot know that your class is a different one since it's located under a different namespace. The import process does not know that what you're importing is a class file... For all it knows, it's just a file that it needs to copy to the project's folder.
You could modify your project structure to match the namespace structure of classes (e.g: Scripts/Utils/Namespace/.../Class.cs)
This would've solved this specific issue.
2019, 2020 both have the same issue. Even more - packages created with different root names, scripts are located in different subfolders, but during import all moved to the Scripts of first one package. Perfect.
That's not an issue at all. Every imported asset has a meta file next to it. This meta file uniquely identifies an asset. When you essentially duplicate an asset, use it and modify it in another project and then move it back you are the one who creates this conflict in the first place. If you want to apply breaking changes / want to create seperate a fork of an asset you should delete the meta file and let Unity generate a new one for the script asset. However I generally would not recommend to keep different versions of the same file. If you apply breaking changes to a script you may want to think about actually splitting the code and refactor the names properly. Though the meta file thing still holds true. In any case when you want to split up / duplicate and modify an existing asset you usually want to generate a new asset id.
Unity is visual editor at first, devs are not required to fill .meta manually, why we'll have to be aware of meta contents and moments when we need to fix them to fit correct import scenario? :) It's unobvious and not documented. From the other side - it's really hard to find all "wrong" meta-files.
BTW, my case is real issue, because even after cleanup/reimport/recreate all the metas i got mix of two packages at import (talking about local packages). The only solution works for me - completely change na$$anonymous$$g of all directories in two packages, i.e. $$anonymous$$y$$anonymous$$egaTool1/Scripts changed to $$anonymous$$y$$anonymous$$egaTool1/$$anonymous$$y$$anonymous$$egaTool1.Runtime. Currently it's working, but not sure will it work for assetStore downloaders or not.
ps. another related issue - export/import package with asmdefs + Editor scripts. For such combination i can't use runtime scripts to attach to objects to see my custom editors, got something like "Script is an Editor script and can't be attached to scene object". But script is not Editor script, it's located in different folder and/or related to another asmdef.
It's a pity Unity has so buggy P$$anonymous$$, i'm sure it's working, but there are too much undocumented pitfalls. Just want normal P$$anonymous$$ with XIX century dependency management :) Probably someone can post link to docs/tutorial with UP$$anonymous$$/P$$anonymous$$ tips and tricks.
right bro.. I have to get the same issue. after done the above all methods. Please help me.
Hello Everyone, My Issue is: My packages are created with different root names with unique namespaces, scripts are located in different subfolders, but during import, all moved to the Scripts of the first one package. can you please help me how to solve this issue? Thanks,
