[Released] Auto-ASMDEF (Single-Click, project wide assembly definition creator)

​

Asset Store
Short manual explaining what, how and why

Auto-ASMDEF will set up assembly definition files for your entire project(or selected folders) in a fast, and extremely convenient way.
Assembly definitions work really well as long as you don't have to include 3rd party assets that don't utilize them. Setting up one asset isn't so bad(unless it has a weird folder structure, usually with multiple Editor folders scattered around), but when you have like 30 - it can be a day's worth of work,
and you spend most of that time waiting for Unity to recompile, it's an absolute nightmare - so I came up with a solution for this specific problem.

We don't care about which assembly they end up in, we don't need nor want to know what's going on in the background, we just don't want to recompile stuff we don't have to and maybe we want to get access to that code - but that's it. Auto-ASMDEF does exactly that. After essentially a click of a button you end up with an ASMDEF setup that resembles Unity's special folders structure, like so

​

What was in Unity's FirstPassRuntime assembly will end up in Auto-ASMDEF-FirstPassRuntime assembly, what was in FirstPassEditor will end up in Auto-ASMDEF-FirstPassEditor, and so on - meaning this is completely backward-compatible, you don't have to set up your project in a special way, put your assets in special folders or anything like that. If it worked before Auto-ASMDEF then it'll work after that as well - except it will compile faster.
This also means referencing those assemblies is simple and straightforward(since it won't clutter your project with ASMDEF files, there is only 4 at most(depending on your project, if you only have scripts in the FirstPass then it'll only create one)). In fact you don't even have to reference them manually, if everything is in a custom assembly except your own code then your code will be compiled after those by default - but it's a good practice to do so.

And of course if anything goes wrong(like you forgot to reference an assembly you want to access from code, or maybe just imported another asset) you can also revert the changes with a click of a button.

I know a lot of people like to follow videos instead so I made one, going into detail about what ASMDEF files are to begin with, following with a step by step guide about how to use Auto-ASMDEF - I'm not used to talking in videos and it shows, if you prefer text over voice let me know and I'll make another one

Updated(1.2) setup guide

Original setup guide(I'll leave this here as I went into detail about what asmdef files are, why you should use them and what not)

Requires 2019.2(as it relies on assembly reference files)

 

Hello,

Purchased today - this seems like a pretty useful asset as my project is quite big now. Generally is working, however a couple of things causing an issue for me:

• It doesn't seem to search / look deeper than the root folder depth? I have nested folders that also have assets / scripts inside... it misses all of those i.e. (/Assets/DownloadedAssets/FolderName/Etc.)
• For some folders that have other sub-folders it's unable to search and hook them up too. Like an editor folder that has sub-folders.. as some assets do (strangely).

Be great if you can investigate and push a fix for the above, if you see that too.

// WildStyle

 

It's also skipping other folders in the root that have scripts, and not creating definition files for them. So at the minute this asset seems to have some bug / issue, unless I'm doing something wrong...

// WildStyle

 

This sounds really strange, it doesn't care about path names, it checks the assembly the file currently is in(so Assets\sub0\Editor\sub1\sub2\someEditorScript.cs should be seen as an editor script).
I just replied to your email, I'm not sure what could be the issue yet but we'll sort it out.

 

Hi, thanks for this asset.

I'm facing an issue where I'm looking to revert created asmdef files. However, I'm doing this after deleting a folder that was in the project. Now, it's trying to search for the asmref files in the deleted folder and throwing errors.

As a result, its stuck here not allowing me to regenerate the asmdef files.



Also, can you add an option to rescan the folders? Everytime I need to close and reopen the tab for it to repopulate the FolderHierarchy area. And would it be possible to add the Select/Deselect All option to "Always Referenced Assemblies".

 

Also, what's the correct workflow when adding new folders/asset store packages after you've run the tool once? There seems to be no way to update the asmdefs, just Revert.

 

@mutp Sure, manual refresh makes sense, thanks for bringing that up!
I'll look into the deleted files issue today, files should be safe to delete(as it checks whether they exist or not when it tries to revert), but if you manually remove the amsdef files the asmref files will still be there pointing to nothing basically, I'm not sure how Unity handles this - but I'll look into it and get back to you. For the time being you can manually remove the created database and the created asmref files (you can search for *.asmref in the project, and the database is in a Resources folder next to the editor script(sorry, I'm not in front of my main rig right now but it's called "something database" I believe - it's just a scriptable object so you can verify if you found the right one or not, it contains session data, and references to the created files. If you remove the database asset it'll be created again and you can restart the process. Or you can just remove the entire folder and reimport the asset.

Also, what's the correct workflow when adding new folders/asset store packages after you've run the tool once? There seems to be no way to update the asmdefs, just Revert.​

Yes, after folder structure change you should hit revert and then let it set it up again - creating new files in directories with asmref files already in is perfectly good though, assets rarely change their structure at all, it shouldn't be an issue.

The way use it in my project is basically like this

• I have a folder named _game, with both runtime and editor scripts, in the folder hierarchy window I exclude it from the selection
• I have random 3rd party stuff everywhere else, everything is included in the folder hierarchy window, I don't change the always included assemblies at all, or anything else at all

This works for me really well, because I don't have to worry about manually referencing anything, my _game folder will always be compiled after the created assemblies and their structure works because the asset sets up the connection properly with the default settings(this wasn't the case at release, when I made the video, then setting up references had to be done manually - that's still an option, but really isn't necessary at all). Absolute worst-case scenario if I either add a new asset or an update changes the folder structure, then I hit revert, wait for it to recompile, then hit start process again and it's done.

 

Thanks for responding so quickly.

Yup, that's exactly how I'm using it as well. I just ran into the issue where I deleted a 3rd party folder from my project and then tried to Revert. It kept throwing an error that it can't find the deleted folders asmref.

Eventually I was able to figure out the ScriptableObject's location, and delete that 3rd party folder path from the list. Then, Revert and regenerate the asmdefs/asmrefs.

 

@mutp I just uploaded the new version, I fixed the errors when files are missing(apparently I had a mental breakdown at the time, I did check if the file exists, however I proceeded to delete it outside of the if body, completely disregarding the result lol).
Also there is a new Rescan button in the Debug settings tab(I decided to put it in a submenu as it runs through the entire project looking for scripts, pressing it accidentally would be annoying - but you can keep the tab open in case you need to rescan multiple times).

And here it is in all its glory - if you don't want to wait until it gets approved by Unity let me know and I'll send you the update directly.

 

Sure, let me send you an email and you can send it to me there.

 

When I revert the asmdef process, it doesn't clear the references built up in the TSD.AsmdefManagement.AsmdefManagerDatabase scriptable object.

 

Yes, it will overwrite the data when it creates new asmdef\asmref files. The only reason I keep track of the created files is to easily remove them later, clearing the database would free up like a few kb of disk space and that's it.

 

Be very careful that you pay attention when you initially set up where the asmdef files "root/home" is and do not move it. Always, always make a backup before attempting any sort of major change!

I goofed up and didn't set the folder to a subdirectory within Assets, I had set the Assets folder itself as the root. Then, not really realizing what that I did that, I noticed the new files in the Assets root, so I moved them into an "AutoASMDEF" folder. Then I figured it is probably best to simply start over and make sure I was doing it correctly, so I hit the revert button. *! Big Mistake !*

I didn't realize or think of the fact that those files were not in their original locations. (I had not used this asset since I bought it last year and thought I remembered the proper step, so it's mostly my own fault)

Not but a few seconds after hitting revert, I was looking at Rider and my open files started closing left and right, my whole project tree started depopulating... my entire assets folder (95% of what was in there) was suddenly wiped out. All that was left was the folder structure and some random files/metas that were not included in any ASMDEF's, I believe. But even more strange is it also wiped out my working directory which I know for sure was not included in the initial asmdef definition.

It was a direct deletion, too. Nothing in the recycling bin. Frantically trying to hit Ctrl + z in Windows explorer, etc. Luckily I am religious about backups, otherwise, that would have been it.

I guess I must not properly understand how AutoASMDEF works under the hood or asmdef in general. I was under the impression that the asmdef essentially wraps the files within the specific folder, but the original files were still kept intact?

It took the majority of the day, but I was able to get things restored, fix a bunch of broken references and serialization, etc, but everything is back to as it was prior now, and I made 3 new separate backups and put them in different locations, just in case....

That said, I would like to very highly request that some additional safety checks be put in place. Perhaps, save in a config file outside of the Assets folder, the current hierarchy/location of the initial asmdef files upon creating them and then if things are not in the same place as they were when it was first set up/created, *don't* allow the revert! I definitely do not want anyone else to have to deal with the sinking feel that takes over your whole body as your files disappear because you mistakenly, and out of pure habit, move a few files into a folder

 

@MostHated Moving the files wasn't the problem, it checks if the file exists and doesn't delete randomly anything.
You set the base folder to the Application.datapath(~Assets/), and then when you hit revert it deleted the contents of the base folder, which in this case was set to the Assets folder. This folder should only ever contain the automatically created asmdef files, because when you hit revert everything in the folder will be deleted.
I'm not sure if you didn't get my email(I wrote about an hour before your post, if that's the case let me know, I can send the update right away).

Moving forward the base folder selection is going to be automatically done in the background to avoid situations like this, and also the files will be referenced by GUID, not just by absolute path(so moving them around is not going to be a problem). But again, moving files around wasn't the problem, if a file isn't found in the stored path then it's going to skip it.

 

I just replied to the email. That's my bad. I see the time showing 2 hours ago, but I didn't receive the notification that I had a new email until about 10-15 minutes ago. Today has just not been my day, it seems, lol.

I would definitely appreciate if you could send me over the updated file. I very much would like to use this, but I was too worried to try it again just yet.

 

@MostHated - Ahh I see. I just sent an email with the update, let me know how it went!

So I just submitted 1.2, with some major improvements in the background and also simplified the workflow.

• Everything is GUID based now, meaning you can move, remove, rename files\paths without losing track of them.
• The creation of asmdef file holder folder is done automatically in the background(it creates a folder named AutoASMDEF in the Assets folder, if one exists(and it's empty) it's going to use that one, if one exists but isn't empty it's going to create a new one with a number suffix)
• Hitting revert won't result in manually created file removal, it'll remove the created asmref and asmdef files, and will only remove the created folders if they are empty(so if you put anything in the same directory the directory will be skipped completely), this should prevent any accidental file removal due to user error
• The new data currently coexists with the old, meaning you can safely update the asset without hitting revert before. This results in a bigger database file for now, in a couple of months I'll remove the old data completely but for compatibility reasons I decided to leave it here(and it's like <10MB in a real project anyway).

 

For anyone else reading this... buy this asset.

Seriously, it's great.

Should be on front page of Unity Asset Store and cost way more in my opinion. It has saved me literally 1000+ hours of work across projects.

 

Just a quick note, whenever I revert the asmdef, the app window always ends up thinking it's still there and shows the button to revert, even if the autocreated autoasmdef folder doesn't exist anymore.

 

One other thing that might be a nice additional feature is some performance metric tracking. I came across this just a few minutes ago and thought that it seemed like it might be nice to have some similar features added to the asset to try and maybe compare before and after applying the ASMDEF, or to help in deciding which ones to add and which not to.

https://github.com/Bullrich/Unity-Assembly-Debugger

 

@MostHated It's not looking for the created files but a database file that keeps track of session data and what not - so if you manually delete the created .asmdef files it won't change the state(and the .asmref files are most likely still there, and removing these by hand would be by far the most time consuming). Or did you experience this after hitting revert?

A timer is a nice idea, but I would advise to always reference everything. You only have to compile these once, setting up the references by hand is rarely worth the effort. The youtube guide is serviceable but outdated, in short

• in the folder hierarch you should deselect the folder you with your scripts(the ones you are actively working on, this is usually completely separated from 3rd party code)
• select every other folder
• leave the referenced assemblies at default(~everything should be selected)

By using it this way your references will work 100%, and you only have to wait for longer compilation once, for the very first time. I'm going to make a new tutorial but really it's that simple now, just remove the checkbox from the folder with your scripts and hit start process. This way that folder will be compiled after the assemblies, so when you change anything in your folder it won't recompile the assemblies.

PS I'm sorry for the late reply, I'm usually fast to respond but a lot of personal stuff came up as of late and usually by the end of the day I barely had the mental capacity to breathe lol.

 

No worries, there is no rush. This issue occurred while using the Auto-ASMDEF menus Revert button, I had not manually touched any of the related files. It was only after I tried it a few times, did I manually delete the automatically created AutoASMDEF folder. It still had the same issue of the menu button saying Revert after having already reverted.

 

@MostHated that's really weird, how did you solve it? Reopening the window was enough, or did you have to do anything else? Or did it fail to revert, were there any errors in the console?
I can see it happen if for some reason reverting fails, most likely due to a regex error(this happened multiple times in the past, but all of these issues have been fixed), other than that the only thing I can think of if maybe for some weird reason Unity didn't refresh the GUI which is even more unlikely.

 

I had reverted the changes as one normally would, closed the window and did some reorganization of folders and things, then opened it back up and went to redo the process and noticed the button had said "Revert", I looked in the folders and saw that the actual files created by autoasmdef were no longer there (the folders were still there), so I went and hit the revert button and then it changed to the expected in order to actually create the asmdef files.

I imagine that a flag or something that simply tells the button to change back to display the begin process button didn't get changed? It didn't seem like it was actually doing anything when I hit the revert button, but I suppose it could have attempted to actually revert again and there was just nothing there, but I don't recall any sort of messages or errors indicating anything going on.

 

I just went to open it back up and opened the "Always Referenced Assemblies" menu and then my console exploded with these messages that don't stop until I close the window.

The window is doing a strange "flashing" randomly every few seconds. It's only this window that is doing it.

https://i.imgur.com/OwHEQl8.gifv

[Error] Resource ID out of range in SetResource: 1059223 (max is 1048575)

 

@MostHated Which Unity version are you using? They probably changed something in the background with GUI code and the icons aren't working as they used to, it's only been tested with up to 2019.3.15 - but this should be an easy fix, it happens every now and then.

I also recorded a new guide as the contradiction was a continuous reason for support emails, I updated the first post in the thread. On a side note, I'm really not sure if voiced videos are working for me, if you guys would like one with subtitles instead let me know.

 

I am using 2020.1.0f1. Strangely, though I have been using 2020.1 the whole time I have been using this and everything was working just fine prior, I had made adjustments in that menu before and everything was good.

Even though the UI is blinking and those messages were going, it still actually created the new asmdef files just fine, lol.

 

Thank you! Very strange indeed. I'm downloading 2020.1.0f1 now, I'll let you know how it went - although the fact that apparently it's randomly not working suggests that I'm going to have a fun time with it lol. If you happen to run into it again in an easy to replicate fashion please let me know.

 

Yeah man, no worries, definitely will do.

 

@MostHated Just submitted an update, it should be live in a day - if anyone wants it right now let me know and I'll send it to you directly

• Fixed UI related issues that led to resource ID out of bounds errors
• Changed the UI slightly to make it more consistent
• Reworded the hints as it was a constant source of confusion, it should be easier to understand now
• 1.2.1 was tested on 2019.3, 2019.4 and 2020.1, but 2019.2 should also work

Important, after the update make sure to restart Unity. Until now I used a custom static class to manage the textures directly, this worked well until 2019.4 but something changed under the hood and it caused issues - long story short, after you update the asset this static class will still be alive in the memory until you close Unity, and it's going to throw ResourceID errors so a restart is required.

 

Nice, glad to hear you were able to narrow it down. I would not mind the update, if it's not too much trouble, I have been doing a fairly decent bit of back and forth adding and removing it in my project, so it would be nice not to have to worry about it going nutty on me and making me have to restart each time it does.

 

Would it be possible for give an option to deselect all "Always Referenced Assemblies" with one click? I always have to deselect every single assembly.

 

@mutp sure, but are you absolutely sure you actually have to deselect those assemblies? I found it to be a waste of time every single time I decided to manually set the references up, in fact it caused so much confusion I was thinking about straight-up removing it(or at least put it under the debug tab).
Default settings work without manually doing anything and compilation only takes longer for the very first time, it won't affect compilation time when you iterate over your scripts beyond that(unless you actually change the scripts in one of the included folders, but that defeats the purpose of setting up assemblies in the first place).

In case you missed it, there is an updated setup guide in the first post, I'm addressing this issue specifically as well.

Can you tell me a bit about the structure of your project, why do you need to set up references manually? Don't get me wrong, I'm not arguing(I already put the request on my todo list), I just feel like there is some misunderstanding about how Unity handles compilation and you are probably doing more than you need to.

 

Ah, I didn't know that. I just deselect every assembly and then just add the ones I need, after the setup is done thinking that was the right way to set it up.

 

Bought this asset and quickly tested it. Works without a flaw so far, awesome. Just one tiiiiny wish.
Do you think you could rename your rootfolder from 2SD to something different maybe TSD? I don't know about every other dev, but I have on overarching folder which is called "_PROJECTASSETS" and gets filtered to the top in the ProjectView. With your "2SD" folder it gets sorted to the second place which is kind of annoying

Alternatively: Is it generally ok to rename the root folder before or even after the Auto-ASMDEF Operation is complete?

 

Another request I would like to make, if possible when editing the assemblies, could there be a way to automatically either A. any assembly that ends in *.Editor, have a button to set them all to editor only, or B. Have a way to temporarily filter out any that *don't* end in *.Editor so that I can quickly run down the list if need be to make sure all of the .Editor assemblies are set to editor only? Otherwise I end up with build errors and have to go back and redo it, etc, etc.

Would be much easier/quicker. Especially considering how often I like to try out new asset packages I find on github, so there could be a decent number coming, then going out if I don't like them or whatever the case may be.

Edit - - It might be my own doing, but I have still yet to be able to figure out how to actually do a build while the ASMDEF files are in place. I have been messing around with it a bunch, but always seem to end up with *some* build errors and have to remove them first. Perhaps there are just some things I need to also sort out on my end in addition.

Double edit -- Looks like the above was due to files using UnityEditor namespace but were files not actually located within an editor folder for one reason or another, so I manually made a new folder and asmdef for it and added it to the editor second-pass assembly. Then discovered there were tons more and then it tried to recompile and AutoASMDEF's link under the menu was gone to try and open it and I had to remove it all anyways. Seems like its just easier to remove them when building overall.

 

do you still have build issues even with all assemblies referenced? (the default state where everything is checked)

 

Sorry it took so long to reply, we just got power back after a crazy storm/hurricane type thing Monday. I was indeed having issues trying to build with everything checked, which is what prompted me to believe that I needed to deselect the editor assemblies from being included in the runtime. Are others able to build with simply having all of them always checked?

 

Edit: just submitted 1.2.2. Since a lot has changed make sure to hit revert before updating from earlier versions.

I'm finalizing an update, should be live soon. v1.2.2

• Automatically disable regex in the text box when a funky folder name is present(so if you have something like Assets/$Folder, or Assets/^Folder you can't use regex, as these have special meaning). If you don't set the excluded list by hand in the "Exclude Textbox" tab(instead of selecting them in the "Folder Hierarchy" tab) then this doesn't affect you in any way.
• Added some additional data to the created asmdef and asmref files, so if you accidentally remove the created database file it can still find the automatically created files and delete them. Starting the tool up takes a bit longer as it has to run the cleanup then, but if you don't reopen the window it'll only happen once. It's possible to manually trigger the process by opening Debug Settings->RunCleanup.
• Made some improvements to performance when looking up files
• Added a button to select\deselect every referenced assembly(but again, in 99.9% of the time it doesn't worth the time you put into it)
• Moved the 2SD folder from Assets/2SD to Assets/Plugins/2SD
• Fixed an issue when instead of using an already existing (and empty) AutoASMDEF folder the tool created another with a number suffix
• Fixed a regression that caused issues with folder names that end with "Assets"

@BTStone That's fair, now that I think of it it makes very little sense to even put it in the root folder instead of Plugins. It is safe to move\rename any time.

@MostHated You shouldn't get compilation errors just by always referencing everything, this is how Unity compiles their code without using assembly definitions. The tool looks up every *.cs file in the project, and based on which assembly are they in it selects a *.asmref file that is equivalent to the one it's currently in - so if a script is in an Editor folder it will be put in an Editor assembly. Compilation errors should only happen if you have a runtime code that tries to access Editor code(which isn't present at all in the build), if you don't reference the editor assembly in the editor the only difference is you get the same error in the unity editor as well.

So if you have a runtime MonoBehaviour that has a "using UnityEditor" that's not going to work in a build, but just by referencing the assembly on the assembly level(referencing isn't really a good word for this, it just means it's compiled after that specific assembly in this case, so if you actually try to use it from code you can) shouldn't ever cause build errors - unless you had build errors before running the tool.
I thought so at the time, precisely because it's named "reference", it suggests that it does have a reference to the assembly so why would it work at runtime when that assembly doesn't exist, but turns out that isn't the case that's why I decided to enable every "reference" by default. The only way the tool could take this possibility into consideration is by reading every single line in every single script looking for a "using UnityEditor" pattern, but Unity itself doesn't do that so even though it could be done, it wouldn't be practical and the analyzing the project takes longer then I would like it to as-is already.

 

I definitely understand and it certainly makes sense that simply having them all be referenced by default would work just fine. The issue seemed to be related to my tools which do make use of UnityEditor but are not located in an editor folder due to being or needing reference to things outside of the Editor folders. What was strange though, is that without asmdef files applied, the project would build and run as expected with no issues.

I may have to do some refactoring in order to make things work properly, in the meantime I have just had to not use asmdef files, though, I suppose I could attempt to still use them on some specific folders, I will just have to experiment and see what works and what doesn't.

Just a side note, since you mentioned project analysis taking a long time. If you are not familiar with RipGrep (which uses the UNLICENSE license), it is a Rust based search tool that is shockingly fast, even compared to things like the SilverSearcher(AG) due to the fact that similar to the Burst compiler, it makes use of SIMD and aggressive inlining. I came across a really interesting example repo using it within Unity to locate references. Considering RipGrep works with Windows, Linux, and Mac, and is licensed quite openly, do like to mention it. Whether it is with this project or not, perhaps it might be of some use.

 

Feature request please if it's not too hard:

Ability to process new additions (and, lower priority but nice if possible, clean up removed asmdefs nuked with removed assets) without doing a full revert and process.

Otherwise every single file gets picked up in git as changed and it's a bit annoying.

 

@MostHated I was thinking about it, do you have an instance of the script that causing the build error in any of the included scenes, or have a reference to it anywhere in code? I'm thinking maybe Unity is only including code that's actually used, but when it's compiled into a dll first it can't do this. A year or so ago I ran into the same build error(without using asmdef files at all), I used a monobehaviour as a quick and dirty editor tool, is your situation similar to this?
I'll look into RipGrep, looks promising, thanks for bringing it up!
@firstuser I hear you. Let me think about how to handle this, it does require some redesign but it doesn't sound that bad. So to make it clear, it is coming, I'm just not comfortable saying when yet.

 

Latest version isn't playing nice for me with addressables when I try to build the bundle (or even analyze rules) I get a bunch of errors like:

[CompilerError] The type or namespace name 'IMGUI' does not exist in the namespace 'UnityEditor' (are you missing an assembly reference?)

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/AsmdefAssembliesTreeViewBase.cs:4 column 19

2:   using UnityEngine;

3:   using UnityEditor;

-->4:   using UnityEditor.IMGUI.Controls;

5:   using System.Linq;

6:   using System.Text.RegularExpressions;

[CompilerError] The type or namespace name 'Compilation' does not exist in the namespace 'UnityEditor' (are you missing an assembly reference?)

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/AsmdefManagerEditorWindow.cs:7 column 19

5:   using UnityEngine;

6:   using UnityEditor;

-->7:   using UnityEditor.Compilation;

8:   using UnityEditor.IMGUI.Controls;

[CompilerError] The type or namespace name 'EditorWindow' could not be found (are you missing a using directive or an assembly reference?)

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/SaveFolderPanelExample.cs:5 column 39

3:   using System.IO;

-->5:   public class SaveFolderPanelExample : EditorWindow

6:   {

7:   [MenuItem("Example/Save Textures To Folder")]

[CompilerError] The type or namespace name 'TreeView' could not be found (are you missing a using directive or an assembly reference?)

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/AsmdefTree.cs:11 column 28

9:   namespace TSD.AsmdefManagement

10:   {

-->11:   public class AsmdefTree : TreeView

12:   {

[CompilerError] 'AsmdefAssembliesTreeViewBase.BuildRoot()':

no suitable method found to override

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/AsmdefAssembliesTreeViewBase.cs:31 column 35

29:       Reload();

30:   }

-->31:   protected override TreeViewItem BuildRoot()

32:   {

[CompilerError] 'AsmdefTree.RowGUI(RowGUIArgs)':

no suitable method found to override

Compiler Error at /Plugins/2SD/2SD/AsmdefManager/Scripts/Editor/AsmdefTree.cs:109 column 27

108:   // Custom GUI

-->109:   protected override void RowGUI(RowGUIArgs args)

110:   {

111:       AsmdefTreeViewItem item = ((AsmdefTreeViewItem)args.item);

and many many more, I can't test right now but I have a feeling this would happen on a regular build potentially too. Any ideas on what this might be or what else I might need to share to make debugging this easier?

 

Revert asmdef stuff wasn't enough I had to delete 2SD folder entirely to build or use addressables.

 

Im having unity 2019.2 something,
the Asset Store tells me:
Needs Unity upgrade to version 2019.3.

Do i need a higher version?

 

@firstuser You are right, this was introduced with the last update. There is a TSDAutoAssembly.asmdef in the root folder, either remove it or change the platforms to Editor only - the only it's there so the IDE don't want to reload it each time after a recompilation. I already submitted the hotfix for this, thanks for reporting it! Also just an FYI, I started working on the assembly update feature, I'm pretty sure it'll be live by the end of the week - but I would like to avoid introducing something like this build issue, so testing will take some time, however if you would like to try it before it's live let me know.
Edit: the hotfix is live

@Sandler It probably works with 2019.2, but the current version was only tested with 2019.3.1 to 2020.1. I just responded to your review, hit me up if you need help, these issues are usually simple to solve over TeamViewer.

 

Hello there!
I've just started using the asset for the sole reason because we want to start using UnitTesting, and to set this up we need to start using asmdefs.
So I followed the steps in the video and selected everything from the hierarchy but "our own code".
But since I have to reference "my own code" with the test assemblies, i need to asmdef-y "my own code" as well. So I've just created a asmdef in "my own code" root folder and referenced the four generated ones (first pass, second pass...) and reference the new asmdef from the test assemblies.

What is the right way to go here? I thought i could ref like this:

Test Assemblies --> My own core code --> the generated asmdefs (basically all the rest 3rd party code)

Or do I have to create asmrefs in every folder like your asset does as well?

So generally my question is:
How do I use your tool if I want to have test assemblies testing my own code?

Thank you for your help in advance

 

@monokelvivien Thanks for reaching out! In this case it's probably the easiest way would be to

• Manually create an assembly for your code by placing an .asmdef file in the root for your scripts(like Assets/_game/scripts). For the sake of simplicity, let's call it myRuntime.asmdef
• Run the tool, your code will be automatically skipped since it's already in a custom assembly. If you plan to reference code that is outside of myRuntime.asmdef make sure to deselect it in the Always Referenced Assemblies tab(as referencing can only work in direction)
• Select the myRuntime.asmdef, and in its inspector add a reference to each automatically created assemblies(these look like "AutoASMDEF-<something>"). You only have to do this if you need access to third party code(or anything that is outside of the created myRuntime assembly) in your game code.
• Select Tests.asmdef and add a reference to myRuntime.asdmef

With this setup you would only have to recompile myRuntime and Tests assembly. One thing to keep in mind, if you are only running your game in the editor this is perfectly fine, but if you build your game you can't include editor code in the assembly or the build will fail, so it might be a good idea to also create a myEditor.asmdef and reference myRuntime.asmdef from it - if you have any editor code under the root of myRuntime.asmdef.

Let me know if this helped!

 

@Pecek Hey, thanks for the fast response

So the way you've described is also kind of what I've tried. So here I my steps that I took:

1. Use your plugin and include all code BUT my _Project folder contains everything that we're working on (The code compilers correctly after this step)
2. Setup an Runtime.asmdef in the _Project rootfolder (the code throws compiler errors because of missing assmebly references from here on)
3. Create a new folder in _Project called (Asmdefs) and add an Editor.asmdef there
4. In every Editor folder create an Assembly Reference to the Editor.asmdef
5. Hook up the AutoASMDEF-files in the Runtime.asmdef
6. Hook up the Runtime.asmdef with the Editor.asmdef
7. Hook up the testing assemblies with the corresponding Runtime&Editor asmdefs

What I thought is weird that after using your tool, even though I've deselected the whole _Project folder, my testing asmdefs got included into all four of the generated ones.

But the same problems stay I have compiler errors that certain namespaces are not found.
Since it doesn't compile, it may miss more, but the ones it's complaining about are:
* Cinemachine
* TMPro
* Obi
* MKGlow
* NavMeshComponents

So it's both UPM packages and plugins that are included in the Assets folder. It seems like the Runtime.asmdef isn't capable of referencing anything from the generated asmdefs. Here's a screenshot of how i've setup the runtime.
I'm using Unity 2019.4.10f1 if this makes any difference.
Thank you for your help and patience!

 

@monokelvivien Sorry, I forgot to mention if you reference the generated assemblies you have to make sure the assemblies you are referencing these are not referenced by the generated assemblies.

Hit revert, then deselect the "Runtime" assembly in the "Always Referenced Assemblies" tab, I suspect this is going to solve all of the mentioned compilation errors(it probably fails before it can get to these, the console usually makes it seem much worse than it actually is).

The reason for this is it's not possible to set up cross-references(as "assembly reference" in this case really is just a compilation order at the end of the day, so by cross-referencing you are telling Unity you want "Runtime" to be compiled both after(when referencing the generated assemblies) and before the generated assemblies(when referencing Runtime in the generated assemblies)). I edited my original reply for future reference.

Also make sure to restart the editor after doing this, sometimes it works fine without restart but it can also lead to really weird errors, it's just better to let Unity reload the assemblies from scratch.

 

v1.2.3 is live with a workflow improvement

• Added option to update the project without reverting first(the button will be visible above the "Revert" button)

If you add scripts to your project just hit Update and it will only create the required files asmref and asmdef files
If you remove files you don't have to do anything, the tool will automatically skip any missing item