Assembly Definition files not working as expected.

I am trying to use Assembly definition files, I create one and suddenly classes outside of that definition file are no longer able to see namespaces and classes inside of it.

I hope this is not the intended behavior, as this this makes it quite useless IMO. So, I hope its a bug.

Cannot seem to resolve it, any help would be appreciated.

 

Yeah this is completely jacked up, there is no way this is desired behavior.

 

That's not been my experience.

Are the files that can't read the files in their own assembly definition, or are they just free-floating scripts?

 

I did that, but it seems to be making no difference. I tried referencing in both directions, its got to be a bug.

I also get different results:

1) If I create the asmdef files in different orders.
or
2) if I make the assembly definition files, close editor, delete the sln and csproj files, reopen editor.

I can sometimes get two asmdef's to play together nicely, but 3 or more never work. Always one definition file will not be able to "see" others.

I even did a layout exactly like described in https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

 

Both. The 2nd screenshot I posted was simply creating an asmdef in the "ThirdParty" folder. No other asmdef files were in the project.

The first screenshot was with a "Main" asmdef file located in the root assets folder. If i ONLY create this file, it works. But then when I add another one elsewhere, suddenly unity doesnt see my scripts as monobehaviours anymore.

I have played with it for 4+ hours, playing with references, moving folders around, etc. Cannot get it to function as expected.

 

Having similar problem too with an assembly definition file in a ThirdParty folder and Editor folders. Works fine in the editor, but throws all sorts of errors when attempting to build to iOS.

I get 212 Errors similar to this:
Assets/ThirdParty/EasyTouchBundle/EasyTouch/_Documentation/Cinemachine/Base/Editor/Editors/CinemachineBasicMultiChannelPerlinEditor.cs(3,7): error CS0246: The type or namespace name `UnityEditor' could not be found. Are you missing an assembly reference?

Not sure if I should be removing the Standard Assets folder, or adding a Main assembly definition file, or removing all the editor folders from the Third Party folder? I tried excluding for iOS, but that wasn't the answer.

 

My project is pretty huge, its an in progress game and I also have a few Third Party assets that are really large MB wise that I haven't cleaned up. Whats the process for sharing stuff like that?

I might be able to replicate the issue in a blank project. Regardless, if the issue is not occurring in a new project, it doesnt matter because it exists in a more complete project.

EDIT: I will delete sounds, textures and meshes to make it smaller. How do I need to send it in?

 

Check karl's sig!

 

Could we have a checkbox under "Any Platform" that reads "Editor only"? So that when you click "Editor only" it will deselect "Any Platform" as well as all other platforms except "Editor".

Because right now the workflow for an Editor asmdef is:

• Create Assembly Definition in Editor folder
• (wait for recompile)
• Uncheck "Any Platform"
• Click "Deselect all" at the very bottom
• Click "Editor" at the top (2nd item)
• Apply
• (wait for recompile)

Just feels unecessarly convoluted, especially since you have that convenience when assigning platforms to DLL files dropped into the project.

Happened to me quite a few times that I missed the "Editor" checkbox too and selected another platform instead. In a project where compiling then takes 10 seconds or so it's particularly annoying.

Or why not use the existing Inspector for DLLs. Wouldn't that work?

 

So I was thinking about setting this up in my project, but it seems like it might not be as magical as I initially thought. Am I right about this process?:

1) Create asmdef in the base directory (catch all).
2) Add asmdef files to every Editor directory.
3) Add asmdef files in subfolders as you see fit, but if classes within that subfolder reference another folder, you need to link those.

This means we need to edit asset directories, right? Rather than a catch all in the base directory working for important assets? It also means it's not trivial to have an asmdef in my game's directory, as I need to update it with every asset's directory wherever they're referenced.

Or am I understanding this incorrectly?

 

Assembly Definitions only affect .cs files. Ignore assets, they have nothing to do with assemblies (assembly == "DLL" ... more or less).

I changed the file structure in my projects so that I have:

Scripts
Scripts/SubfolderPerFeature
Editor
Editor/SubfolderPerFeature

The former way of doing things did not lend itself well to adapting to asmdefs, meaning I would rather avoid this structure from now on:

Scripts
Scripts/SubfolderPerFeature
Scripts/SubfolderPerFeature/Editor

Assembly definitions work better/easier if you can start out with 2 asmdef, one under /Scripts and one under /Editor, rather than having to check every Scripts subfolder for an Editor folder and having to reference that.

Once I have this, I start decoupling individual features. The idea is that eventually the asmdef in /Scripts and /Editor will be declared "DO NOT USE" and no .cs file should belong to them. To ensure that, I eventually switch off all platforms except for one we will never ever use (Tizen ... WTF is that anyway? *g*). That way all new features will have to have an asmdef.

In the end you have about the same work with both structures, but there's one big reason to avoid Editor subfolders:

• Programmer creates new "feature" folder with scripts in it
• Programmer creates asmdef for that feature
• all is fine up to here
• Programmer adds some "Editor" scripts to this feature-folder
• Programmer does not add asmdef for Editor
• all seems fine but .... from now on builds will fail

The reason is that asmdef by default include "Any Platform", which includes editor. So the above workflow will tend to create asmdefs that include Editor scripts which of course can't be in a build.

Therefore separating Scripts and Editor in two folder paths makes it clearer that one needs to create an asmdef for both. And even if you forget to add an asmdef, the "catch-all" asmdef at the Script or Editor root folder will get these script files and thus builds continue to work. It's only at the time where you need to reference a new feature in some other asmdef that you'll find that this feature you're trying to reference has no asmdef yet, so you'll add one.

 

Thanks for the explanation! Though by 'Assets' I mean scripts downloaded from the Asset Store. They always have their own folder/file structures, so you now need to add asmdef files to them, or restructure them like you've suggested. But that seems like a nightmare for upgrading?

 

Contact the developer and encourage him/her to provide asmdef with the next release (I suppose these files will be ignored if the user uses an older version of Unity).

During the transitional period we have to do this ourselves. However I rarely need more than 10 minutes to prepare an Asset Store plugin for general release among our developers, including cleaning up file structure and suppressing warnings (sometimes even errors). Plus upgrading plugins is something we only do when we are convinced that it helps our work. Over the year we upgrade each plugin on average once or twice.

 

I'd like to get back to the subject of the post.

Having the same issue with my 3rdparties when trying to create a thirdparty.dll, mostly my regular main scripts (that will be added to Assembly-Csharp.dll don't get to know what's inside the thridparty dll.

My third party folder is not under the unity Script folder. Could it be something ?

 

- Allright, so then I simply moved the assembly definition file into a single submodule (TextMeshPro in this case)

Now it compiles. Why ? Any clue ?

 

Could you tell from your side why are we having this behavior? It seems I almost got it working finally by manually adding an assembly definition file in every third party module that was not recognized by the main .dll

It's a definitely tedious as most third party asset does not have an assembly definition file. Plus it's not the intended behavior, feels buggy.

Those errors should not be there, I quintupled checked.

 

We managed to have it working, beware to check that there is no assembly reference error in the first line of your console ( EConsole was not showing it)

 

I have been having this problem and I just solved it (for me at least). The errors are pretty unhelpful because I think what they really point to is there was an error compiling the assembly which should contain the namespaces or classes which can't be found. In my case I had a lot of errors saying "PostProcessing" namespace couldn't be found. The actual problem was that my "Plugins/" directory, which has it's new asmdef file, was not compiling and so not producing a dll with the PostProcessing classes. The reason the "Plugins/" directory was not producing a dll was because there was a subfolder in that directory with some Boo files in. Once I put a separate asmdef file in with the Boo files, then everything else was ok.

I definitely think the error messages could be improved here, by pointing out the first assembly which failed to compile, rather than the error messages from the compilation of the final .exe. And obviously there should be an error when folders mix script types.

 

Same happened to me with .js files (error appeared in the console at some point). Also +1 for better error feedback

 

Anyone else notice the duplicate projects in the solution with the *.Player on the end?

What's that about? I only see them pop up after I've switched build targets.

 

Hi Karl,

I wonder if you could clarify something for me. I have a "ThirdParty" directory in which I've placed all of the 3rd party packages I use in my project. To isolate that code, I've added an Assembly Definition file at the root of the ThirdParty directory.

Almost all of these 3rd party packages have their own Editor directory. Is the recommended/required approach that I got into each of those Editor directories, and create an editor-only Assembly Definition, which references my ThirdParty assembly definition? That seems to be what I need to do in order to avoid build errors. But it also seems awkward to have to add content to a 3rd party directory. What if I update the package? Do I need to go around updating assembly definitions each time I do this?

This is made worse by the likelihood that any given 3rd party package will have many different Editor folders within each, each of which seem to need a separate assembly def file. I assume I must be doing something wrong...

 

Thanks for the clarification. Maybe I'm just at an awkward point being on 2017.3 and using packages not sourced from the package manager. Sounds like things will be easier moving forward. Thanks again.

 

This seems broken with the release of the new Package Manager. If you import a package like TextMeshPro through package manager, the code is outside of your Assets folder. That means you can't solve the problem by placing an assembly definition file. Is there another way?

 

@karl_jones Just wanted to ask how you suggest to work with ASMDEFs when dealing with platform specific MonoBehaviours? The way it worked so far was to use preprocessor directives to compile them out, but you always left the class body intakt to not remove it as a reference from scene GameObjects to avoid warnings.
If I now would just put all those scripts into an assembly for a specific platform and build for another one, all of them will be missing on GameObjects. Since GOs cannot be platform specifically removed, that's a problem.
Not to mention SerializedFields.

 

Even the following Unity link referencing Resources states "Don't Use it". By Adressables, you mean AssetBundles?

 

How do we use this with assets inside the Package Manager?

When I create an assembly definition for my own scripts I get the error

• The type or namespace name `TMPro' could not be found. Are you missing an assembly reference?

And I can't add a reference to TMPro in the Package Manager.

 

I don't have the Packages entry in my Project view. Is that new in 2018.2, or am I missing something?

 

@karl_jones I found a concrete case I like to hear your opinion about. I have a gameobject in my scene which is mandatory to be there. It reacts to UWP inputs. I now want to add android specific inputs without altering the code already written. For this to work I wrote an adapter that translates input from android to UWP. It has to exist on the gameobject. It's one of several scripts that are only needed on Android target platform. Now the thing is, I'd like to put all of these android scripts into their own ASMDEF. Problem is that it's attached to the gameobject and will result in a missing class when built. I could programmatically add it, but then I'll have to write yet another script to attach it and have that script in another ASMDEF which references the android one.
How would you solve, or how would you handle such a situation?
The simplest way would be an automatic component removal or hiding (in editor) if the component won't be available on that platform even though it exists in the editor (Would be a nice feature thinking about it. Greying out components that won't be part of the build, also showing what platform they're ment for or something similar).

 

Could you maybe consider actually documenting this feature? Afaik, since 2015 the only information available is the one from the manual about the standalone player settings, which says:
"Set an array of assets to be loaded when the player starts up."

There are a bunch of important information about how to use it, differences between the editor and players, etc. that are missing. A good example is that there's no information about how you'd go about using the platform-specific ScriptableObject you're recommending to use. It's preloaded, sure, but that doesn't help anyone get any information from it.

I happen to know that OnEnable is called on application startup on ScriptableObjects added to the preloaded assets, and you can use that to assign it as a singleton. I don't think that's been written down anywhere.

 

@karl_jones I have another question related to ASMDEFs. Code is available to all platforms by default. If you don't like them on specific platforms you have to use preprocessor directives. What is actually missing though is an option for platform specific editor code.
If the code is not platform specific in the case it does only run there, but in the case it is not needed in the game on other platforms, code still has to exist in the editor to be tested. This means that every ASMDEF containing scripts of this kind, has the target platform AND editor. But editor means its available on every platform. This means ASMDEFs are somewhat unusable here because you still have to go into the scripts and wrap them in #if UNITY_EDITOR && <Platform> to get that kind of combination.
Is it possible to add this feature to ASMDEFs? Platform specific Editor ex-/includes?

 

Thought so
I added the idea here:
https://feedback.unity3d.com/sugges...th-platform-specific-editor-in-slash-excludes

 

@karl_jones could you tell me if it's intended behavior that a lot of my ASMDEFs generate a second VS project file, ending on .Player.csproj

 

I got that alright. what I mean is that some of them appear twice, once with and once without the .Player addition to the name.
in those cases, when searching references in code, both of these show their results even though they seem to be the same. and its not all of them. the editor Assembly files don't generate these twins at all.

 

Ok you guys,
after a lot of back and forth I decided to roll back to not using ASMDEFs at the moment.
Therefore I wrote something I wanted to share with the community, a Helper for toggling them to not loose your work. This package adds the following:

- an ASMDEF menu to the top for toggling all ASMDEFs in the project Assets hierarchy
- a context menu for ASMDEFs in the project view to block them from being toggled

what it does is adding the ~ to the files so they disappear from Unity's AssetDatabase but can be added in again. For the files that are ignored a scriptableobject is created which lists the file names without extensions so you can easily see which ones are still active.

Enjoy

 

Jesus Christ, why is the default behavior not to skip over /Editor/ folders?

I, like many people, have my add-ons all in one folder. It would be great if I could just make an assembly for them all, but, as was stated above, many of them have one or multiple /Editor/ subfolders.

If I tried to make an separate assembly definition for every single one of those would end up dozens if not hundreds of assembly definition files.

Thanks for nothing.

 

Or, at the very least, have the option to ignore the assembly definition file completely when I make a build. At least then my recompiles when using the Editor would be fast.

Very disappointing.