@okcompute_unity Hey, I got the same error in 2019.1 with packages that got installed via the Git integration of the Package manager. Should I still create a bug report or is this already known?
It can’t seem to find the files as they reside under the Library/PackageCache folder…
@okcompute_unity I had this problem as well, but in my case, it was because AssetDatabase.FindAssets didn’t understand backwards slashes, e.g.:
‘Packages/com.package.test****Runtime/Components/Popup’
I suppose I shouldn’t join folder paths using Path.Combine. Is it also a bug, or should I make sure to always use forward slashes?
AssetDatabase.FindAssets is part of Unity API (not a .NET API). Unity file system expects forward slashes, not backward slashes. This is to to provide consistency across platforms. So, this is not a bug
I believe the issue also applies to ScriptableObjects defined in Packages/, but present in Assets/. So, for instance, I have an embedded package with an SO defined at Packages/MyPackage/MyScriptableObject.cs. I create an instance of that SO in my Assets folder, say at Assets/Data/MyScriptableData.asset.
Now, I can try running the following:
var paths = AssetDatabase.FindAssets("t:MyScriptableObject", new string[] { "Assets/Data" });
…however, this returns paths.Length == 0. Similarly, AssetDatabase.LoadAssetAtPath returns null when I give it the exact path of the SO instance, which was defined in a package.
Okay, well I think I’ve figured out the cause of my particular problem. In my case, the package I had installed was originally installed via Git URL in the Package Manager; the ScriptableObject was created in this configuration.
However, I then uninstalled the Git URL version of the package, and installed it again via a repo cloned on my local disk. I guess this meant that somehow the ScriptableObject was hashed differently by Unity; subsequently, when looking for MyScriptableObjects in my project, Unity couldn’t find the type as defined in the package-on-disk (even though there was an asset present, as created by the package-from-Git).
So in my case it was due to changing the source of the package in Package Manager; if I create & search for the ScriptableObject using a package defined by a single, particular source, I don’t have the issue. My bad!