Does Unity log which files it's compiling?

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

 

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:

Code (CSharp):

1. $ ls -1 Library/ScriptAssemblies/
2. Assembly-CSharp-Editor-firstpass.dll
3. Assembly-CSharp-Editor-firstpass.pdb
4. Assembly-CSharp-firstpass.dll
5. Assembly-CSharp-firstpass.pdb
6. AutoLetterbox.dll
7. AutoLetterbox.Editor.dll
8. AutoLetterbox.Editor.pdb
9. AutoLetterbox.pdb
10. BuiltinAssemblies.stamp
11. Editor.dll
12. Editor.pdb
13. Fungus.Editor.dll
14. Fungus.Editor.pdb
15. Fungus.Examples.dll
16. Fungus.Examples.pdb
17. Fungus.FungusLua.Editor.dll
18. Fungus.FungusLua.Editor.pdb
19. Fungus.LineEndings.Editor.dll
20. Fungus.LineEndings.Editor.pdb
21. Fungus.Runtime.dll
22. Fungus.Runtime.pdb
23. Fungus.Usfxr.Editor.dll
24. Fungus.Usfxr.Editor.pdb
25. GoogleAnalytics.dll
26. GoogleAnalytics.pdb
27. NSelection.dll
28. NSelection.pdb
29. Scripts.dll
30. Scripts.pdb
31. Spine.Examples.dll
32. Spine.Examples.pdb
33. spine-unity.dll
34. spine-unity.pdb
35. spine-unity-editor.dll
36. spine-unity-editor.pdb
37. Tests.dll
38. Tests.pdb
39. Unity.PackageManagerUI.Editor.dll
40. Unity.PackageManagerUI.Editor.pdb
41. Unity.TextMeshPro.dll
42. Unity.TextMeshPro.Editor.dll
43. Unity.TextMeshPro.Editor.pdb
44. Unity.TextMeshPro.pdb
45. Unity.Timeline.dll
46. Unity.Timeline.Editor.dll
47. Unity.Timeline.Editor.pdb
48. Unity.Timeline.pdb
49. UnityEditor.SpatialTracking.dll
50. UnityEditor.SpatialTracking.pdb
51. UnityEditor.XR.LegacyInputHelpers.dll
52. UnityEditor.XR.LegacyInputHelpers.pdb
53. UnityEngine.SpatialTracking.dll
54. UnityEngine.SpatialTracking.pdb
55. UnityEngine.XR.LegacyInputHelpers.dll
56. UnityEngine.XR.LegacyInputHelpers.pdb
57.  

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.

 

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

 

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: https://gist.github.com/ericallam/c769cedb7050e8057230cc9d15492718

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.