Is it not possible to include a git package with no meta files?
I have some external code that can run outside of Unity. I can create a dll from this code, import and use the dll in my Unity project without an issue. Now I would like to add this code using the package manager with a git url instead of creating a .dll.
But there are indeed no meta files in this package as it is not a Unity specific package. So when I import from the git url I am getting am error:
“has no meta file, but it’s in an immutable folder. The asset will be ignored.” and then the files in the git url are not downloaded.
Does this mean that I have no choice but to add meta files to this package? gross! 
Is there no way for unity to add/create the meta files when it include the package and how can it use the .dll if that had no meta files either.
Thanks
add the package files zo any unity project, open the project, make sure the settings for the dll are correct (ie target platforms etc), then copy those meta files back into the dll package
yes you need the meta because they contain the target platform settings among other things
The dll works fine.
This make no sense, metas should not be relevant for external code that has nothing to do with Unity.
Hi @francineW ,
This is not directly related to the fact that those assets are in a package. The Editor’s Asset Database system tracks assets by generating meta files that contain information like the asset’s unique ID, so that references between assets can be made and are not dependent on file paths in the project. The Package Manager just provides packages as separate “Assets”-like folders, so the same rules apply - files in them will only be imported by the Asset Database (and therefore be made available to the rest of the Editor’s subsystems, like the Scripting pipeline and the Build pipeline) if they have valid meta files.
The main difference between package folders and the main Assets folder of your project is that since the Assets folder is directly part of that project, it’s assumed that it’s fine to generate missing meta files. This enables drag & dropping external files into your project. On the other hand, packages installed by the Package Manager are stored under the project’s Library folder, which is unique to that specific instance of the project. In order to guarantee identical installations, the Asset Database can’t reliably create the meta files because the generated asset IDs would be random, so different instances of your project would have different GUIDs for the same packaged assets.
Another key difference between Assets and packages is that packages do not support “magic Editor folders” to determine assemblies and compilation order. Instead, asmdef files must be provided so that Unity knows how to compile scripts into assemblies, and how the different assemblies reference one another (references affect compilation order, undefined type name lookup, and runtime loading). At this time, the Scripting pipeline does not support .csproj files, so for now the .asmdef files are needed along with your .cs files. This means that in order to make it possible to use your non-Unity-specific package source directly as a Unity package using a Git URL, you unfortunately need to provide both one or more .asmdef files for the assemblies to build and .meta files for all of those assets (including folders).
Whew. That was a bit of a long detour, but I wanted to make it clear why this is happening. I agree that this could be improved somehow in order to facilitate integrating standard (non-Unity) .NET/C# code/assemblies. I don’t think this is something we can change anytime soon, unfortunately, but in any case, I’ll definitely make sure this feature request is tracked internally.
Wow that was a fantastic explanation and it makes sense. Thank you very much ! Now I feel better putting those meta files in the git repo even if the backend people yell at me for several days for messing up their repo. As they should 
OR I can stick to the dll route.
1 Like
But note that the dll would also need a meta file (which is generated for you by the Asset Database if it’s added directly to the project Assets folder, though!) It might actually be the closest to hassle-free that you could get, since shipping your package with sources requires including .asmdef files as well, as I briefly mentioned. DLLs also get to be faster to import since there is no compilation phase.