koobas.hobune.stream
Assembly Definition in Editor folder
I am trying to struct my source by Assembly Definition files. When it come to a Editor folder case. It seems all script are included in none-editor dll, with parent or child folder of .asmdef file named "Editor". And event the folder is Editor-script only and name "Editor", if there is any .asmdef file in the folder. Build process will not ignore it, and generate UnityEditor reference error. Do this mean Assembly Definition files can not be used with editor script?
I found the setting here. Just not documented.
I am trying to implement assembly definition files for a larger project with many external dependencies. I find a large number of packages that now require separate asmdf's for their editor folders and oftentimes the respective folder contains only one script. It is a cumbersome task and it does not feel right.
If I were to reimport the packages, I have to make sure to keep these files. If somebody else from my team imports a new package, he is forced to setup the assemblies and that is quite a technical task that I rather not have people do.
I was trying to clean up the project by splitting the assemblies, but now I have dozens of them and it feels like I achieved the opposite of what I intended.
Is there a different way of going about this? What is the idea here? I don't get it.
Build times are not thaaat much of an issue, so for now I will keep most things in the default assembly and thereby have Unity autodetect the editor folders.
I'm having the exact same issue, and it basically makes assembly definition files unusable. In my case, I'm building my own "external dependencies" - basically packages that we will be reusing on many projects, and these packages each depend on various other external packages. The instant I give my own packages asmdef files, I need all my external packages to have asmdefs too, with all the complications that arise with either relying on other developers to manage those properly or having to update them myself every time a new version of the package comes out.
The simplest solution, in my opinion, is to still let Editor folders have special status even when asmdef files are used. Basically, you just add an implicit asmdef to all Editor folders that is set to Editor Platform only and References the "parent" asmdef (the first asmdef file found when traversing up the folder hierarchy). This way, at worst, I can just add a single asmdef at the root of each external package that doesn't have one.
Adding an asmdef file for each Editor folder in an existing package can result in a lot of small assemblies. A better approach would be to reorganize the package so there is a PackageName.Runtime and PackageName.Editor folder/asmdef, so you only get 2 assemblies per package.
As for having to update the .asmdefs for a new version of the packages, it seems to me that the entire process of creating the .asmdefs for specific packages could be easily automated with a script. Point the script to the root folder of package, all scripts in Editor (and sub) folders are moved into a new PackageName.Editor folder and all other scripts are moved into a new PackageName.Runtime folder. And add a dependency from PackageName.Editor to PackageName.Runtime.
$$anonymous$$y comment to a previous discussion for supporting a migration feature for the Editor folders. https://forum.unity.com/threads/example-project-assembly-definition-files.482313/page-4#post-3296568
Ah wow, thanks for pointing me to that thread. I wish I had found it earlier. I had that solution in $$anonymous$$d before, but discarded it, because I wanted to stick to the concept of not touching imported packages. Devs will have to at least provide a reference to new packages as they import them. You never know, if scripts have hard-coded path references or other ugliness that would be broken by this (they shouldn't, but well). The advantages of assembly definition files might still outweigh these issues, though. A tool could also give a warning and suggest the restructuring in the import popup. That would reduce the pain to a $$anonymous$$imum. Overall It is a good thing to move away from magic folders and towards explicit definitions.
I have created a script that disables all assembly definition files before building the project and reenables it after the project builds, since i'm only interested in reducing compile time. When they fix this behaviour than I can delete my script
It can be as simple as rena$$anonymous$$g all the .asmdef files to .asmdef--- and back again.
Sucks that it's necessary to do this though!
I've come up against this issue as well, and I have multiple 3rdParty tools. Its cumbersome alone to have to add an editor.asmdef for each editor folder, but its even worse that the tool isn't smart enough to recognize multiple editor.asmdef files and create one assembly for it. Instead, each has to have a unique name.
I think it would be a very easy fix to have the assembly definitions recognize multiple .asmdef of the same name and add them all to one assembly. This way 3rdParty developers could simply add a editor.asmdef to their editor folder and uniform behaviour would be achieved.
EDIT:
One gotcha is that you need to check the "Test Assemblies" box for each editor.asmdef, to ensure it can access the UnityFramework for includes.
Another is that if you are using asset bundles built from a different project, and any of those assets have scripts attached to them, you need to make sure the other project has the same assembly definitions setup, otherwise when you stream the assets in, the scripts wont be found.
I also found that you can name the .asmdef files the same (Editor.asmdef), but in the inspector give them unique names. This is convenient if you want to find all of them when searching in the Project window.
Did you manage to resolve the issue?
The docs for .asmdef files are available here, let us know if you find them lacking.
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html
I've got a similar issue. $$anonymous$$ain.asmdef in root assets folder and then 3 more (game scripts and two 3rd party plugin catalogs each with it's own .asmdef). While building, Unity gives me an error about non-existent type - and that's understable, because editor scripts are included in .dll files generated by asmdef, but they reference the UnityEditor classes that Unity strips when building. Any idea how to tell Unity to ignore */Editor catalogs when building these assemblies based on .asmdef files? I guess right now I have to create a separate .dll for each Editor catalog in my project to avoid this?
Yes, you have to create separate .asmdef Editor only assemblies for all Editor only scripts.
