Assembly Definition Woes

Hi,

Am I using them wrong or are Assembly Definitions kinda useless out of the gate?

I set my projects up in such a way that I have one big Library folder (which contains all my external or reusable code) next to my game specific code.

I get the bright idea to make my Library folder one massive assembly (and why not?), but when it comes to building a standalone, it doesn't seem to rebuild the assembly to respect Editor folders, ie hundreds of compiler errors because there are editor references it can't find. Does this mean that I have to create tens or maybe hundreds of assemblies for each Editor folder?

Is there a solution here that doesn't involve performing acrobatics to separate my editors into multiple folders? Which kind of makes my library folder useless.

Thanks.

 

So if you have an asmref inside the domain (domain?) of another asmref it will split it out into another assembly?

Cos I may be able to live with that

 

I haven't, thanks for the link!

 

--
Why not combine the best of both worlds and have at least a toggle on Assembly Defintion Files that says "put Editor folders inside this structure into a separate <assemblyname>-Editor assembly"?

Right now, using assembly definition files on any serious project that uses a combination of external submodules and asset store packages is impossible. The usual folder structure has Editor folders all over the place, right next to the specific scripts they relate to, which in my opinion is a very good thing that I wouldn't want to change.

 

@karl_jones - I agree with the other developers here. Having a simple option to automatically put Editor folders into the old Assembly-CSharp-Editor.dll would be a huge help. What you're asking requires that we put asmdef files into folders that we shouldn't be messing with. For example if we are importing Assets from the Asset Store. It's common practice for Asset Store assets to require that you delete the folders before updating, because as I'm sure you know, the package import process does not remove files that were removed by the asset developer in asset package updates.

Followup:
I just counted and our 2D Game project has 38 Editor folders in it! Having to put asmdef files in all of those just seems like an unreasonable thing to ask.

What might work is if we could specify a path/folder filter in the asmdef file so that we only need to maintain an extra asmdef file in the root folder (e.g. TextMeshPro or VoxelBusters) to exclude things like Editor folders.

Another idea is that if multiple asmdef files have the same assembly name, then they could combine into one assembly. For that to work you'd have to make the asmdef references refer to Assembly names and not asmdef assets.

 

The package manager looks like a nice improvement.

Currently the asmdef files create a separate csproj file for every one. If asset store packages bring in dozens of other asmdef files, hopefully you can figure out a way to keep this more compact, for example place the csproj files into a folder that the .sln references?

 

@karl_jones Another idea would be to have at least a bit more control about how asmdef files collect scripts. For example, a "include folders by name" string list and a "exclude folders by name" string list. That should keep everything working the same way you intend it to do, but allows people the flexibility to have "special folders" if they want. I always felt it was a great thing that I can create a script, and then after I find I need to have a custom editor for it, just create an Editor folder right next to it with the script's custom editor in it. What do you think?

Then I could have two asmdefs in a project at top level at least - one with "exclude Editor folder" and one with "include Editor folder".

 

I'm just trying to understand why you want to move away from it, and how the new workflows are supposed to be, both for newcomers and for experts. ("Developer Usability", a topic that is rarely thought about enough, Unity as a platform is a great exception to that)

Also, I second @tessellation in that current projects contain easily dozens of Editor folders (I counted – 29 for a current project which uses a combination of Package Manager, AssetStore packages and git Submodules).
"Solving over time" only works if there is a gradual path to that shiny future – currently, the documentation says "use asmdefs for everything or not at all", which, given that not all submodules/assetstore packages use them, means "not at all" unfortunately. We're actively looking into it (thus my involvement here) trying to figure out how to get there asap without breaking all external components we're using.

What would be the new recommended workflow for having CustomEditors for scripts?
Put them "somewhere you think it might fit"?
Put them "in your single Editor folder where all your editor scripts are"?
Put them "in an Editor folder right next to the script but don't forget to create a new asmdef for that single editor script"?

 

Hi again.
To not be the "guy who just complains", I today tried to do everything the "new way" and upgrade a whole existing project to using assembly definition files.

Here's my writedown:

Original Project Statistics

• 121 own scripts
• 4 AssetStore packages
• 6 unitypackages from github
• 6 git submodules (with some more recursive submodules)
• 1 new UnityPackageManager packages (ProBuilder)
• 27 editor folders scattered around, 5 in own scripts
• 8 projects in Visual Studio (csproj files)
  • ProBuilder.AddOns.Editor
  • PackageManagerUI.Editor
  • PostProcessing.Runtime
  • PostProcessing.Editor
  • MyProject
  • MyProject.Editor
  • MyProject.Editor.Plugins
  • MyProject.Plugins
• compilation time when changing a script ~9s
• time for Visual Studio to react when double-clicking a script: ~6s
• cold start for Visual Studio (not open before): ~19s

Process
All in all, it took me and a coworker ~3hrs to go through the project.
That was split up in ~1.5hrs adding asmdefs and connecting them for all folders with our code – project was compiling at that point again; and ~1.5hrs making the project build again (adding asmdefs to all editor folders).
In the end, we mostly made our code asmdef ready, and only touched some of the external references, mostly because we didn't want to break upgrade compatibility for those.

Pain Points

1. When creating asmdefs for Editor folders, the process is very very repetetive:
   1. create asmdef
   2. unselect ""
   3. click on "Unselect All"
   4. click on "Editor"
   5. Apply.
   6. drag other asmdef (that's not from this editor) into the references
   7. Apply again
   8. 90% of the time, when clicking somewhere in the Project Window have to "Apply" again (msg window pops up)
      
2. It takes a lot of thinking to figure out what goes where – I consider myself an advanced Unity/C# developer, and it felt like going back in time to having to AddReference tons of things in a larger project with multiple subcomponents. I think this is essientially because that's what asmdefs do, add references internally.
   I don't think that Unity beginners or even intermediary users will have any benefit from doing this.
   
   
3. I had to break the update path for the external components we decided to asmdef'y (because they were directly referenced from our own code), since now if I upgrade them, I need to re-create the asmdef files
   (most more complex AssetStore packages ask you to delete the folder and then import the upgrade because they contain DLLs etc.)
   
   
4. Visual Studio now doesn't fly, it just crawls on the floor screaming for help. Every time I cold start it, it takes ~30s, every time I double-click on a script in Unity after a recompile (with Visual Studio open) it takes ~138s (I used a stopwatch to measure that!)
   I have no idea whether that's a bug with visual studio or the Unity integration or Unity, but it happens on all machines I tested on.
   There are now 32 projects (csproj) that are loaded/unloaded every time.
   
   
5. When creating a new script from inside Unity and double-clicking on it, Visual Studio
   1. unloads/reloads all csproj files – this takes 138s
   2. then tells me "something has changed externally, should I reload?" which takes another 138s
   3. bringing the total time to 276s (more than 4 minutes)
      
6. Renaming the Assembly Name inside the asmdef file breaks all references to that asmdef file, contrary to how Unity usually handles asset references it seems these are not serialized with references of asmdef files to each other but instead with string references.
   I consider this an "annoying but not crucial bug".
   
   
7. There were some unsolvable dependency issues in the process that I'll try to describe here:
   1. we have a submodule with some code that references SomeExternalComponent (it creates nodes for a node-based system).
   2. that code lives in an asmdef
   3. these nodes use #if SOME_EXTERNAL_COMPONENT to make sure they compile even if SomeExternalComponent is not present (a common practice).
   4. the submodule in itself is fine (no SomeExternalComponent in there)
   5. when adding the submodule to a project where SomeExternalComponent is contained, it complains of not finding it.
   6. SomeExternalComponent does not use asmdef, so had to add it manually
   7. referencing the SomeExternalComponent asmdef to the asmdef of the submodule that creates nodes for it works
   8. now pushing those changes back the submodule
   9. now the submodule doesn't compile in itself anymore, since it complains of not finding that SomeExternalComponent asmdef.
      
      
   10. Ended up removing the node-generation code and not using asmdefs for it and SomeExternalComponent. Not sure what the right way would be here.

Result Project Statistics

• 26 asmdef files, with up to 5 references
• 12 of those for Editor folders

Compilation time is down from ~9s to ~5s for scripts that are in an ideal place (have their own asmdef not referencing anything). To my understanding this still takes that amount of time because all those external packages that we didn't dare to touch/add asmdefs to will be recompiled everytime such a poor little script is changed.

Compilation time is up from ~9s to ~13s for scripts that are at the end of the reference chain.

Visual Studio opening time is up from ~6s to ~138s since Visual studio unloads/reloads all those projects every time a script has changed (basically every time I save a script, go to Unity, let it compile, then double-click on a script to open it).

Postmortem
Fortunately all these changes happened in a separate branch and are now packed away until some or all of these issues are resolved. We will not be using asmdef files until then. Maybe the unloading/loading is just me missing a configuration detail, but that's just using a fresh install of 2018.1beta10, so the experience will be the same for most users.

For working on core scripts/modules, if compilation times actually increase, it might make sense to allow users to globally enable/disable the use of these asmdef files altogether, to make the overhead of working on sth that most of everything else refers to less of a burden. For a backend developer, the introduction of asmdefs made compilation times worse.

 

@fherbst I had a somewhat similar experience.

What I ended up doing was actually editing the asset store packages I use and make them compatible with custom assemblies. So I ended up with a total of 8 projects:

myGame
Devel (for fast development, depends on everything, no dependencies)
Vendor
Tests
and their -Editor counterparts.

What would really improve this workflow is to have partial asmdef files, where the same assembly could be split into multiple folders.


Check out this common pattern

Assets\SomeModule
Assets\SomeModule\Editor

Assets\AnotherModule
Assets\AnotherModule\Editor

With partial asmdef files, we would stick one MyGame-Editor.asmdef file in each of those Editor folders, and they would all be part of the MyGame-Editor assembly.
Without it, we need to change the structure to this

Assets\SomeModule
Assets\AnotherModule
Assets\Editor\SomeModule
Assets\Editor\AnotherModule

Now we need to maintain the names of those folders in two separate locations.
Even as a sole dev, this will most certainly get out of sync with time. It is also much worse to navigate when using an IDE with a dedicated "Unity" solution explorer (like Rider or Visual Studio).

This is also very bad for asset store packages, since it makes maintaining the packages harder and most packages use the "canonical" folder structure of having the Editor folder inside whatever it is the editor for.


We talked a bit more about this partial asmdef files in this thread


All in all, I really hope this partial asmdef file idea lands at some point. This, along with a easy way to create packages to use with the Package Manager (and have a way to have their resources available in the project) will make Unity development much faster and modular.

 

Putting an "editor assembly" in each folder with editor stuff will add up real quick. We have lots of very modular stuff, each module having its own Editor folder. If I were to follow this pattern, I would end up having well over a hundred projects, each containing just a few scripts (editors are usually only 1 or 2 script files). This overhead alone would make asmdef files lose their appeal.

I re-structured the project to have all editor stuff in a separate folder, and asmdef files are cool in this configuration, but it is a lot of work and duplication. I gave some more context in the previous post.

 

To solve the Editor folder script issue - I made a editor script that would turn all the assembly definition files on/off. So while developing we'd have them on (for quick compile times / code modularity) then turn them on when actually building the game / building asset bundles. I thought it worked great for a while - then I noticed all the Unity UI events I had set up would then be 'missing' after switching (since they reference using the assembly name).

So since that didn't work, I decided to make a script that would generate all the assembly definition files for the Editor folders. I didn't want to have 70+ projects created - so this is still something I only turn on when I am building the game. Generates them based on their parent's assembly definition file.

Code (CSharp):

1.  
2.     class AssemblyDefinitionType
3.     {
4.         public string name;
5.         public List<string> references;
6.         public List<string> includePlatforms;
7.         public List<string> excludePlatforms;
8.     }
9.  
10.     public class AssemblyDefinitionSwitch
11.     {
12.         [MenuItem("Tools/Create EditorAssemblyDefFiles")]
13.         public static void TurnOnAssembly()
14.         {
15.             CreateEditorFiles(new DirectoryInfo(Application.dataPath), null, false);
16.             AssetDatabase.Refresh();
17.         }
18.  
19.         [MenuItem("Tools/Delete EditorAssemblyDefFiles")]
20.         public static void TurnOffAssembly()
21.         {
22.             CreateEditorFiles(new DirectoryInfo(Application.dataPath), null, true);
23.             AssetDatabase.Refresh();
24.         }
25.  
26.         static List<string> EditorAssemblySibilings;
27.         static int duplicateNum = 0;
28.  
29.         static void CreateEditorFiles(DirectoryInfo Dir, FileInfo ParentAssemb, bool Remove)
30.         {
31.             FileInfo[] files = Dir.GetFiles();
32.             foreach (FileInfo file in files)
33.             {
34.                 if (file.Extension == ".asmdef")
35.                 {
36.                     ParentAssemb = file;
37.                     EditorAssemblySibilings = new List<string>();
38.                     duplicateNum = 1;
39.                 }
40.             }
41.  
42.             if (ParentAssemb != null)
43.             {
44.                 DirectoryInfo[] dirs = Dir.GetDirectories();
45.                 foreach (DirectoryInfo subdir in dirs)
46.                 {
47.                     if (subdir.Name == "Editor")
48.                     {
49.                         FileInfo[] editorfiles = subdir.GetFiles();
50.                         foreach (FileInfo file in editorfiles)
51.                         {
52.                             if (file.Extension == ".asmdef")
53.                             {
54.                                 if (Remove)
55.                                     File.Delete(file.FullName);
56.                             }
57.                         }
58.                         if (!Remove)
59.                         {
60.                             // create a assemb file based on the Parent one, only with includePlatforms changed to Editor
61.                             // assembly name is the parent assembly name + directory that contains the editor folder + "Editor"
62.  
63.                             AssemblyDefinitionType EditorAssemb = JsonUtility.FromJson<AssemblyDefinitionType>(File.ReadAllText(ParentAssemb.FullName));
64.                             EditorAssemb.references.Add(EditorAssemb.name); // add parent assembly as a reference
65.                             EditorAssemb.references.AddRange(EditorAssemblySibilings); // for subeditor folders to reference the above editor assemblies
66.  
67.                             EditorAssemb.name += Dir.Name + "Editor";
68.                             if (EditorAssemblySibilings.Contains(EditorAssemb.name))
69.                             {
70.                                 EditorAssemb.name += duplicateNum;
71.                                 duplicateNum += 1;
72.                             }
73.                             EditorAssemblySibilings.Add(EditorAssemb.name);
74.                             EditorAssemb.includePlatforms = new List<string>();
75.                             EditorAssemb.includePlatforms.Add("Editor");
76.                             File.WriteAllText(Path.Combine(subdir.FullName, EditorAssemb.name + ".asmdef"), JsonUtility.ToJson(EditorAssemb));
77.                         }
78.                     }
79.                 }
80.             }
81.  
82.             DirectoryInfo[] dirs2 = Dir.GetDirectories();
83.             foreach (DirectoryInfo subdir in dirs2)
84.             {
85.                 if (subdir.Name != "Editor")
86.                     CreateEditorFiles(subdir, ParentAssemb, Remove);
87.             }
88.         }
89. }

 

@LVermeulen That's neat!

This could be a real alternative to modifying the project structure, and behaves similar similar to how Unity handles the UnityEditor namespace: you can use anything from UnityEditor during development (available to all), but it will not be available during a build (so you get errors pointing to where you incorrectly used it).


Thanks for sharing your idea (and code)!

 

Hi there,
just to support what has already been said...
I was really glad when I first saw the assembly definitions feature, I thought this would really improve the compile time of my big project. I went through the same process that @fherbst described, adding asmdefs everywhere, including ones for Editor folders, and trying to figure out how to asmdef'y Asset Store assets and even the Standard Assets folder (spoiler: it's very hard)...

And now I'm thinking of removing them altogether, because moving or adding any script makes Visual Studio completely reload everything, or when it doesn't, the file does not see any reference nor can be seen by.

Btw, apart from creating asmdefs for each Editor folder being horribly tedious, I see how it makes for a nice and unified system, and still I'm not sure that the Editor should be considered a platform... it somehow feels conceptually weird.

 

A good idea would probably be to allow multiple asmdefs with the same assembly name (maybe with an additional toggle) to combine into one, so separate folders from different script modules could be treated as one (like "Editor" for example).

 

I have not read the whole post here, but in my opinion, just removing as many Editor folders as possible by just creating one and then starting the same folder structure as the original in it reduces the asmdef to just one per plugin or folder.

• Assets
  • Scripts (asmdef)
    • Editor (asmdef Editor)
      • One
      • Two
      • Three
      • ...
    • One
    • Two
    • Three
    • ...
  • Plugin
    • ...

 

Not all plugins or projects have editor folders that simple. Often it's more like:
Assets

Code (CSharp):

1.   |-somescripts
2.       |-someeditorscripts
3.   |-morescripts
4.       |-moreeditorscripts
5.   |-evenmorescripts
6.       |-withevenmorefeatures
7.           |--withextras
8.               |--withextraeditors
9.           |-..
10.           |-withoptions
11.               |-thathaveoptions
12.                   |-thathaveeditors
13.           |-...
14.       |-andothers
15.           |-withotherfeatures
16.               |-withothereditorfeatures

I've come across a few of these (one example is the oculus sdk), and it doesn't seem wise to just rip them out of those hierarchies and having to recreate their nesting just to know where they came from, besides also making it harder to maintain that separated structure afterwards.

 

Vendors will eventually adapt to how asmdefs require folders to be setup, maybe even just providing the download with them setup.
But for now, it's as is, tedious, or rearrangeable.

 

Or, Unity could allow merging asmdefs or similar and help us not wait many years for everyone to adapt (as with all other 'legacy' options)

 

One point I'd totally agree. After all ASMDEFs are setup, using VS is just awfully slow at best. It's crazy how unresponsive it is. @fherbst did an awesome job to describe his workflow and findings in such a detail. @karl_jones Is the drastic decrease in Visual Studio performance something that can and hopefully will be improved? To me it's the major reason why I'll revert back to how it was (like fherbst did), because it takes longer using ASMDEFs to interatively develop than it does without.

 

That would be awesome since I rather not revert
I'm using 2018.2.0b9 btw.

 

I actually stopped using VisualStudio because of how much time reloading took.
Been using Jetbrains Rider for a while now, and don't even notice reloads.

I went to extremes to try and fix this in VS, even going as far as creating a VS extension to make the changes to the projects using the VS API instead of just reloading them all. It helped, but using Rider was still better in the end.

 

@SugoiDev, @Alexees, for me, the reloading of Visual Studio got better (I wouldn't say fixed, but definitely feels like "mostly back to normal") after fully uninstalling it and then have a newer Unity version reinstall it properly. It seems somewhere along the installs something just "broke by default" and a lot of people now have those reloading issues.

That being said, I still feel code is much more organized if CustomEditors are placed near the scripts they are editors for, everything else just feels weird and leads to a very error-prone duplication of folder hierarchies. I tried!

 

Yeah, that "partial asmdef files" idea would be the perfect solution to keep existing hierarchies and avoid duplication.
It's also much better to navigate the editor files in the IDE (and in the Editor) if they are in folders next to each other.

 

@fherbst it acutally helped me too. Reinstalling VS was it.

 

Karl, this attitude you have of "everyone will adapt" is really patronizing.

There are thousands of Unity projects that are in development now, using 3rd party assets that are currently on sale now on the Unity Asset store, that still have embedded Editor folders.

It really doesn't seem like much work for Unity to, for instance, automatically disable all of the assembly definition files whenever we make a Windows, in order to at least speed up compile times when we're editing.

As long as Unity is making money from the asset store (and we've spent thousands), how about you fix the system so it actually functions with those assets?

 

What I mean is that the pain-in-the ass process with the /Editor folders only becomes an issue when you try to make a build.

Everything works fine in the editor, even if you don't bother to setup a separate assembly definition file for every little /Editor folder in your project. Just dropping a single assembly definition file in my /Add-ons folder, for instance, speeds up compile times, as intended, when we work in the editor.

However, once we try to make a build, we run into all of the issues.

Thus, it would be nice if there was an option to completely ignore the assembly definition files (pretending they don't exist at all) when we try to make a build.

Now I know there's currently an option to not include the compiled assembly at all when we try to make a build for a certain platform, but that's not what I'm suggesting here.

I'm suggesting an option to completely disabling the assembly definition functionality when we go to make a build.

 

@karl_jones Is that "partial asmdef" idea on consideration? It would solve the issue of having to move things around nicely and we would have only the necessary number of projects. It would also allow us to not have to change asset store packages. Instead, we would just put a partial asmdef file in each of the package's Editor folder and they would be all compiled to a single assembly.

 

That doesn't sound clean to me, as it separates related code, and even more like a hack. You'd have a hard time manually deleting an extension that has many separated editor subfolders afterwards. And depending on how this copy-paste operation works, either possibly end up with duplicate named editor subfolders or possibly duplicate script names inside a big editor folder.
But maybe it's just my misunderstanding of how this proposed solution should work.

 

I've been following all comments, but i dont see how i can solve the following.
I've been using (naughty atributes) with some personalized atributes (meaning the type of [range(1,2)],. ).
I've used an assembly definition for it and works ok in edit mode and when i compile to android.
But when compiling to windows standalone all scripts using the special atributes, fail because they dont find the the atribute definition (if i make the asdf only editor) or the atributes fail to compile with internaleditor not found (if i make the asdfs all platforms).
Is there a fine tuning i can make?, and why works with android compiling and not windows.
If not perhaps i can try the option of deleting/disabling all asdf before compiling and restore them afterwards (with the proposed utility).
Thanks in advance.

 

Thank you very much Karl,
sure, i'll prepare an example, so i don´t bother you with all the code of naughty atributes, although perhaps i will take a bit as i dont know much about creating new inspector atributes.
But anyways, can you confirm me that theoretically, personaly defined inspector atributes, should work ok with asdfs?

thanks again, i'll start on the example this afternoon.

 

Thanks Karl,

you were totally right, i had a mixture of editor and non editor scripts in one of the folders.

I was kind of worried (new to c#) that conceptually as non editor scripts can have lots of atributes that are not inspector attributes, that the tool would not have gone the way to separate them, but looking backwards it was obvious it was already doing it as it was mentioned that editor scripts already were in a separate assembly before asdf.

So yes "if it works without asmdefs in Unity it should work with them" (i know there are exceptions discussed but for me is true enough).

Still wandering why i thought it was compiling in android, perhaps i will look on that, but if thinks work as they should i'm happy about it.

Still new to using asdf so i will probably ask more question as wich is the new way to emulate precompilation conditions functionality on scripts, etc .. but for the moment i'm quite happy i can incrementaly walk through the different functionalities and issues i've been reading here.

thanks a lot! and best regards,

 

Hi,
it looks i was wrong about compiling ok in android (something i changed in a folder?, i was dreaming?, parallel universe? , haha).
thanks again i thought i should inform about it so no one gets uncomfortable thinking about unexpected behaviours.

 

Ok, here again, a solved problem(probably selfgenerated jj) but just in case it can help someone with little experience like me who runs into it.

I had the tipical self made soundcontroller tool, with its general scripts and with the editorscripts in separate folder.
I can make a asdf for the general script and everithyng ok, but when i make an asdf for the editor folder (with the customeditor for the main class) y see that in the inspector the class shows
"Multi-object editing not supported."
So i look in console and the message is
"Instance of SoundControllerEditor couldn't be created. The script class needs to derive from ScriptableObject and be placed in the Assets/Editor folder."
Really the class derives from UnityEditor.Editor. so . hmm not sure but kind of think its not a scriptable, but .. ho knows?
So i mess around in the "crappy computer im using at the moment" probably the cause of lots of my weird observations, and i find out that it starts to happen to other editor folders as i delete and recreate the asdfs.

So i create the asdfs again for the editor folders, dont care about the messages, reload the project (actually close/open unity just in case) and everything looks fine. yeay!!

I guess i didnt have the pacience to wait enough, the crappy computer had enough of me or something but in any case is repeatable if i delete/recreate the asmdfs in the editor folders (one of the times i even managed to crash it when renaming the asmdfs .. to quickly?jj ).

resume, dont despair just reload unity (better than the next common problem solver.. to unplug/plug the computer).

 

Hi Karl,
I send You the example and the codefiles simplified to allmost minimal expresion (no functionality just structure and some variables).
I think perhaps the #region definitions can mess up a bit the asdf?, but i havent tried yet as i've been deleting all the project to leave only this to files in the almost minimum expresion (with 40 and 60 lines).
I'll keep reducing the code and trying.
Best Regards,

 

Hi Karl,
probably something related to sincroniztion of files with visual studio?
because now with a little more reduce code, happens the same but when i edit in visual studio one file and change a bit the structure (not enough just changing a value), when i go back to unity and it reloads it corrects itself as it did last day when i reinitiated unity.
What can also afect (apart from the #define statements) is that the files are a little messed up in unix/windows line ends.
I send you the reduced files. I just move the line anyware (not enough to change the value) "float tempFloat = 0f;" in the editor and it reloads and solves the problem.
For you to recreate it you should just delete the SCEditor.asmdef and recreate it (once i tried moving it in and out but i think it wasnt enough).

Best regards.

 

How is it a hack? The whole utility of the assembly defs is to speed up the day to day editing process. They really aren't needed when you're making a build, so why not implement the option to ignore them in a build?

As of now, you've created a system that simply doesn't work with the vast majority of assets that Unity is currently selling on its asset store, which is where Unity derives the majority of its revenue from, from my understanding.

Please implement my solution instead of telling people "just restructure your entire project bro"

It's stuff like this that makes me want to move to Unreal. Road Redemption might just be our last Unity Engine project.