I’m trying to troubleshoot something, and to do so, I’d need to know which files Unity compiles when I make a change. Does it print this out somewhere or maybe in a log? If so, how do I see it?
https://docs.unity3d.com/Manual/LogFiles.html
Or console window inside Unity editor.
Hrm… the fact that you said, “or console window” makes me wonder. I’ve never, ever seen the console window say which files are compiling. How do I see which files are compiling?
You can’t, you can see in the bottom-right corner when Unity’s compiling (circular progress bar) and usually some error in the console if error occurs. Sorry I just mentioned this because of the “troubleshoot something”, I see why it was misleading.
You can share the problem, maybe we can help?
Sure, here’s my problem: https://forum.unity.com/threads/how-can-i-tell-if-im-using-asmdefs-everywhere-i-should.672640/ My code takes 11 seconds to reload but a new project takes 5. I’m trying to figure out how to reduce my current code to a 5 second reload time.
As a quick check why don’t you just use command line to find all folders containing .cs files and that check that each of these folders has an assembly definition?
In .NET compilation is not file based, it is unit based. There is no file compilation order to define or log.
OK, good to know. So how can I prove that my compilation isn’t slow because I’m missing an ASMDEF somewhere? That’s all I really want to do.
By experimental means. You may add asmdef files where you think it will help and measure their compilation time by reimporting them from script and looking how much it tales. You’ll need and AssemblyDatabase and Stopwatch classes
1 Like
OK, I’ll look into that. But here’s the thing. The documentation says:
> Although not strictly required, Unity recommends that whenever you use Assembly Definitions in a project, you do so for all of the code in your project. Otherwise, when you change scripts in one of the predefined assemblies, Unity must still recompile all the code in your project, since the predefined assemblies automatically depend upon any assemblies you create using an Assembly Definition.
What if the only reason my build is slow is because I’ve got a script somewhere that’s not in an asmdef? If that’s the case and I don’t know it, I can waste my whole day experimenting when the real problem is I’ve got a lone script somewhere that’s outside of any asmdef. It’ll feel like no matter what I do, I can’t improve performance, when really, it’s just a dumb oversight on my part… an oversight Unity provides no help with troubleshooting, as far as I can tell from this thread. This feels like black box testing.
Shouldn’t Unity have some way to let me know, “Yo, I’m compiling EVERYTHING, because something’s outside of an asmdef.” Even if it was literally this vague, that would help me out immensely.
As it stands right now, if experimenting with asmdefs improves nothing, it could be because I’m missing an asmdef, or it could be because my compile time performance is as good as it’s going to get no matter what I do. But it’s important to know which one it is, right?
Sorry for the rant, but I hope I’m just thinking about this the wrong way and someone will correct my thought process.
That’s easy thing. Look into Library/ScriptAssemblies foder int your project.
I see this:
$ ls -1 Library/ScriptAssemblies/
Assembly-CSharp-Editor-firstpass.dll
Assembly-CSharp-Editor-firstpass.pdb
Assembly-CSharp-firstpass.dll
Assembly-CSharp-firstpass.pdb
AutoLetterbox.dll
AutoLetterbox.Editor.dll
AutoLetterbox.Editor.pdb
AutoLetterbox.pdb
BuiltinAssemblies.stamp
Editor.dll
Editor.pdb
Fungus.Editor.dll
Fungus.Editor.pdb
Fungus.Examples.dll
Fungus.Examples.pdb
Fungus.FungusLua.Editor.dll
Fungus.FungusLua.Editor.pdb
Fungus.LineEndings.Editor.dll
Fungus.LineEndings.Editor.pdb
Fungus.Runtime.dll
Fungus.Runtime.pdb
Fungus.Usfxr.Editor.dll
Fungus.Usfxr.Editor.pdb
GoogleAnalytics.dll
GoogleAnalytics.pdb
NSelection.dll
NSelection.pdb
Scripts.dll
Scripts.pdb
Spine.Examples.dll
Spine.Examples.pdb
spine-unity.dll
spine-unity.pdb
spine-unity-editor.dll
spine-unity-editor.pdb
Tests.dll
Tests.pdb
Unity.PackageManagerUI.Editor.dll
Unity.PackageManagerUI.Editor.pdb
Unity.TextMeshPro.dll
Unity.TextMeshPro.Editor.dll
Unity.TextMeshPro.Editor.pdb
Unity.TextMeshPro.pdb
Unity.Timeline.dll
Unity.Timeline.Editor.dll
Unity.Timeline.Editor.pdb
Unity.Timeline.pdb
UnityEditor.SpatialTracking.dll
UnityEditor.SpatialTracking.pdb
UnityEditor.XR.LegacyInputHelpers.dll
UnityEditor.XR.LegacyInputHelpers.pdb
UnityEngine.SpatialTracking.dll
UnityEngine.SpatialTracking.pdb
UnityEngine.XR.LegacyInputHelpers.dll
UnityEngine.XR.LegacyInputHelpers.pdb
What am I looking for in this output?
For predefined assemblies. Here’s it at lines 4,5 with a pdb. Something is out of asmdef in your project. Also you can look at their creation/modification times to see if they’re compiled always at the same time or not.
1 Like
Ooh, this is exciting. Can you explain why that tells you I’m doing something wrong? I thought Assembly-CSharp-firstpass.dll was for things in the Assets/Plugin directory?
Oh, and it was modified earlier today.
I’m bumping this. It feels like there are 5 devs on the planet that understand how to troubleshoot asmdef performance related issues. Please share with the rest of us 
1 Like
I realize this is an old post, but if you’re looking for a way to identify which assemblies are being built, this may interest you: Unity - Log Assembly Compilation times · GitHub
The Unity API includes the CompilationPipeline class, which has a few events, including “assemblyCompilationFinished”. That event passes the relative assembly path and an array of compiler messages for warnings and errors.
It doesn’t list which scripts were included in the assembly, but it can be used to determine which assemblies are being compiled when compilation occurs.
1 Like