Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Example Project - Assembly Definition Files

Discussion in '2017.3 Beta' started by LeonhardP, Jul 8, 2017.

  1. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    npatch likes this.
  2. tspk91

    tspk91

    Joined:
    Nov 19, 2014
    Posts:
    92
    I see two drawbacks in this system specially in projects with a lot of plugins. As it stands right now, I cannot use custom assemblies in my project. I would have to manually create so many and with such complex dependencies that it is not worth the time.

    -It is sorely missing a way to have multiple folders in separate locations being included in the same assembly, for example by using the same assembly name (but multiple assembly definitionn files) in all of them. This could be used to manually replicate the behavior of current "special" folders. This way I can include all Editor folders in all plugins in one assembly. Currently I need to create dozens of assemblies for this with complex dependencies, given that some plugins use multiple Editor folders themselves.

    -It cannot replicate the current "special" assemblies behavior. As custom assembly definitions are compiled first and without any dependencies to current unity special folders (plugins, editor), I need to put all my code and all plugins under assembly definition files. It would be better if there was some way to build special unity folders under assembly definition files into Assembly-VeryFirstPass, so we can reference them in the custom assemblies in the core game code easily.

    By the way, when there are unityScript files blocking the assembly compilation, it would be nice if the log included some info about it.
     
    Last edited: Oct 18, 2017
  3. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    Having multiple folders for the same assembly is something that has been requested multiple times and is something we will be looking into in the future.

    I'm not sure I understand what you mean by this?

    Thanks for taking the time to provide feedback on this feature.
     
  4. tspk91

    tspk91

    Joined:
    Nov 19, 2014
    Posts:
    92
    When there is any unityScript/js file under a assembly def file, it causes that assembly's compilation to fail. The offending file is not shown in the log so you have to search manually. Just a minor nitpick :D

    This whole feature will be great when it is more ironed out, it's just missing a few retro-friendly thingies to make the transition feasible.
     
  5. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    We will add it to our backlog to print this info to the log. Thanks.
     
  6. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    What's the reason?
     
    Peter77 likes this.
  7. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    It would require us to parse all C# scripts before compilation to extract the attributes, which would just add to the compilation time.
     
    laurentlavigne and Peter77 like this.
  8. rastlin

    rastlin

    Joined:
    Jun 5, 2017
    Posts:
    112
    I think implementing such request will promote bad habits. For big projects it would be a nightmare from maintenance perspective. Imagine trying to sort out the contest of an assembly, if one needs to pin-point naming conflicts, when basically you need to scan entire project for assembly files, parse it to output the assemblies and determine, which paths are included.

    To support what @tspk91 actually needs, I think much more reasonable is to make special assemblies be generated for files defined by assembly definition. So far all files are compiled into single assembly irrespective of special folders. I would imagine something like this:

    Plugins_Core.asmdef ->
    > Plugins_Core.dll
    > Plugins_Core.Editor.dll
    Plugins_Misc.asmdef ->
    > Plugins_Misc.dll
    > Plugins_Misc.Editor.dll
    etc.

    Including files from multiple, separate folders into a single assembly, based on multiple asmdef will create more problems than it will solve in my opinion.
     
  9. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    How and if we are going to address this issue has not been decided yet. Currently I'm leaning more towards providing an simple API, so the developers can decide for themselves how to compile scripts.

    The way this would work is there would be a special scripts folder, like "Assets/UnityBuild" which would built into it's own UnityBuild.dll assembly before any other assemblies are built. No user assemblies nor Unity assemblies would be referenced when building this assembly. Then we would invoke a method in this assembly with all scripts paths, defines, references, build target, etc. required for compilation.

    The developer can then decide to compile some or all scripts in a custom manner (like build a .sln file by invoking msbuild) and report any compiler messages to Unity. It would then also be possible to tell Unity to compile a subset of the scripts using the built-in mechanisms. The order of the build steps would be decided by the UnityBuild.dll code.

    This way you can have custom build steps for your own code and use the default mechanisms for third party code.
     
    DigitalJim likes this.
  10. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    420
    How this approach will be suitable for many asset store authors and packages with custom build pipeline in each?
     
  11. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    My current thinking is that asset store packages will still use the .asmdef files. The custom build system will be for your project code and you can get all the other .asmdef / built-in assemblies through an API, so you can either ask Unity to build them or include them as part your build pipeline. I think we might block publishing the Assets/UnityBuild folder to the asset store.

    The idea behind this custom build pipeline is to provide the lowest level of build customization possible and should only really be used if you have very specific requirements that cannot be fulfilled easily with our built-in mechanisms. So instead of us providing specific build features for everyone, we provide the tools for you to implement them yourself.
     
    npatch likes this.
  12. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    143
    The availability for customization is always appreciated.
     
  13. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    420
    So this customization will not fulfill this for asset store authors:

    Plugins_Core.asmdef ->
    > Plugins_Core.dll
    > Plugins_Core.Editor.dll

    because this can be done only for final product.

    I even suppose more to this. Some thing like this:

    Plugins_Core.asmdef ->
    > Plugins_Core.dll
    > Plugins_Core.iOS.dll
    > Plugins_Core.Android.dll
    > Plugins_Core.Android_amazon.dll
    > Plugins_Core.Editor.dll
     
  14. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    I can see this would be very useful for migrating existing asset store packages. I would like to wait and get more feedback on the .asmdef feature and assess how big of a problem it is for existing asset store packages to use it, before making a decision on whether to invest time on implementing migration features.
     
    npatch likes this.
  15. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    Perfect reason, thanks for clarifying.
     
  16. GarethPikPok

    GarethPikPok

    Joined:
    Apr 4, 2017
    Posts:
    6
    I'd like to second the idea of splitting Editor/special assemblies out automatically. As a test case, I took a large project and started tying to split it out, and I'm finding that making assemblies for every editor folder is a slow and painful process, and restructuring this project isn't worth the time investment. Is it likely to be a feature in the 2017.3 release?
     
    laurentlavigne likes this.
  17. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    143
    Maybe not but it's gonna take a time investment to transition to new features and new file structures so maybe it's worth it to invest it one time and be done with it.
    I guess each to his own time budget..
     
  18. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    Unlikely to be a feature in 2017.3.
     
  19. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    143
    Not sure if this has been mentioned.In the asmdef, will we be able to define a default namespace? Seeing as this is a library definition we could override the application/project default.
     
    Stormy102 likes this.
  20. jice_nolaroads

    jice_nolaroads

    Joined:
    Oct 2, 2016
    Posts:
    21
    hello,

    I try to use the feature in some case with unity 2017.3.0b8

    From a class under a asmdef folder (so in a custom assembly "MyAssembly") How i can access to tierce party plugin like Google Play Game service (e.g) which reside in managed dll ?
     
  21. BlackPete

    BlackPete

    Joined:
    Nov 16, 2016
    Posts:
    970
    I understand that these assembly definitions are not build files, but would this considered to be a step in that direction?

    i.e. in some (hopefully not too far) future release of Unity, we'd be able to specify a compiler so that we'd be able to compile certain assemblies with C#9 (or whatever's out by then), etc.?
     
    fwalkerCirca likes this.
  22. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,333
    Hi. i just downloaded the latest 2017.3 beta. Is there any documentation on how to enable "assembly definition files" ? i know there were plans to provide an "inspector" experience for that, instead of directly editing files. is this already available ?
     
  23. jice_nolaroads

    jice_nolaroads

    Joined:
    Oct 2, 2016
    Posts:
    21
    yes already available.
    no enabling necessary.
    you must use project -> right click -> create -> assembly definition and use inspector.

    doc is in FP: https://drive.google.com/file/d/0B51Vmelt0rENZThZOTl5ZTIyN28/view


    nobody for that ?
    i really need it :/
     
  24. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    if I add an assembly definition inside a folder, how do I access classes from another assembly that is not referenced by that definition? Adding using AssemblyName doesn't do it.
     
    Last edited: Nov 16, 2017
  25. FibriZzo

    FibriZzo

    Joined:
    Feb 2, 2014
    Posts:
    16
    Hello everyone.

    I've been trying for some time to test this awesome new feature, but I cannot get it to work properly with a base project with the "Example Project - Assembly Definition Files" and a random asset from the asset store (in this case, Advanced Inspector).

    I've read all posts in here and re-read them, but I still need help understanding it.

    The base project work just fine (i've compiled the "interdependent assembly definition files").

    But when I try to create all the necessary assemblies for Advanced Inspector I can't shake 5 errors :(

    AI's folder structure is (the relevant part):

    Plugins/AdvancedInspector
    Plugins/Editor/AdvancedInspector

    AdvancedInspector
    AdvancedInspector/Examples/CSharp/Editor

    As far as I know, the assembly definition files should be compilated in order:
    • Phase 1: Runtime scripts in folders called Standard Assets, Pro Standard Assets and Plugins.
    • Phase 2: Editor scripts in folders called Editor that are anywhere inside top-level folders called Standard Assets, Pro Standard Assets and Plugins.
    • Phase 3: All other scripts that are not inside a folder called Editor.
    • Phase 4: All remaining scripts (those that are inside a folder called Editor).
    So, first the "Plugins" folder. Then, "Plugins/Editor", third the project scripts, and finally the "AdvancedInspector/ Examples/CSharp/Editor". I've created the assembly files, configure the editor ones to be "editor only" and create the references:

    upload_2017-11-16_8-53-16.png
    (NOTE: inside the first folder is the "Examples/CSharp/Editor" assembly)

    Phase 4 references phase 3: "editor" references "project scripts"
    Phase 3 references phase 2: "project scripts" reference "Plugins/Editor"
    Phase 2 references phase 1 "Plugins/Editor" reference "Plugins"

    but I still get 6 errors, all of "Plugins/Editor", all of the same type:

    upload_2017-11-16_8-55-40.png

    What did I do wrong?

    I think it has to do with the "AdvancedInspector.dll" inside Plugins/Editor/AdvancedInspector, which I think is not referenced by the assembly in Plugins/Editor, but I have no other clue.

    The error states:
    The type `AdvancedInspector.IconPreviewSize' is defined in an assembly that is not referenced. Consider adding a reference to assembly `Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'"

    Which is included in the AdvancedInspector.xml:
    upload_2017-11-16_9-19-32.png




    Thanks a lot in advance!!!
     
    Last edited: Nov 16, 2017
  26. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    I wonder if this is related to bug# 969427 which has to do with deleting assembly definition not being recognized. It seems to have corrupted my project for good because I just downloaded changes from the same project in 5.6, where it works in 5.6 but red errors in this beta
    I've also tried deleting all dll in library and a few other things.
    So try this: compile your project in VS, if it works then you ran into this bug.
     
  27. FibriZzo

    FibriZzo

    Joined:
    Feb 2, 2014
    Posts:
    16

    Compiling in VS gives the same error:
    "Error CS0012 The type 'IconPreviewSize' is defined in an assembly that is not referenced. You must add a reference to assembly 'Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. EditorPlugins-Assembly"

    Thanks :)
     
  28. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    Do you mean that the script templates should create the MonoBehaviour in a namespace set in the .asmdef file settings?


    asmdef files will not become a build system. We would rather provide a different solution for customizing the build pipeline, see my previous answer here: https://forum.unity.com/threads/example-project-assembly-definition-files.482313/page-3#post-3262550


    https://docs.unity3d.com/2017.3/Documentation/Manual/ScriptCompilationAssemblyDefinitionFiles.html

    You can add .asmdef references using the inspector for the .asmdef file.
     
    laurentlavigne and codestage like this.
  29. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    Can you share the project, will be easier for me to see what the issue is :)

    Thanks for taking the time to report this bug, we will look into it.
     
    laurentlavigne and codestage like this.
  30. FibriZzo

    FibriZzo

    Joined:
    Feb 2, 2014
    Posts:
    16
    Sure! This is the link: https://drive.google.com/open?id=1IW0WLFcg3rj-j6t1iIjj1wreIkNCj62N

    As you can see, the problem is with some scripts inside the Plugins/Editor/AdvancedInspector folder, that try to access some classes inside its own DLL: "advancedinspector.dll" in the same Plugins/Editor/AdvancedInspector:

    Assets/Plugins/Editor/AdvancedInspector/FieldEditors/ObjectEditor.cs(105,54): error CS0012: The type `AdvancedInspector.IconPreviewSize' is defined in an assembly that is not referenced. Consider adding a reference to assembly `Assembly-CSharp-firstpass, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

    But the error says to add a reference to Assembly-CSharp-firstpass.

    Thanks a lot for looking into it!
     
  31. npatch

    npatch

    Joined:
    Jun 26, 2015
    Posts:
    143
    Basically yeah. In VS you can always set the project namespace through project properties. Seeing as assembly definitions practically generate projects for libraries, I'd like the option of setting a namespace for it that is propagated to all the appropriate places, like the template, or the VS project properties equivalent text field. Even more so if projects are gonna be regenerated every time you need to open the VS solution.
    I realize now that some of this if not all , might be a task for VSTU. But I'll leave it to you to decide what's what.
     
    Last edited: Nov 17, 2017
  32. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    I see that we already support this for the generated .csproj files with "Root namespace" editor setting. It just injects the value in the .csproj files. But it does not work in the editor when adding new scripts. I will add this to my backlog and look into supporting it when creating scripts in the editor and in .asmdef file settings to control it per assembly.
     
    npatch likes this.
  33. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,380
    The best way to do that would be to add to the syntax for the default script, no? Right now the template supports #SCRIPTNAME#, so if you add #ASSEMBLYNAME# in there, we can use that to chose if we want to add the namespace ourselves.

    Even better would be if what happens when you click "generate C# script" was scriptable, ie. we could register an object/callback that can override the default editor behaviour.
     
  34. BlackPete

    BlackPete

    Joined:
    Nov 16, 2016
    Posts:
    970
    Yes, this.

    I work between multiple projects simultaneously, so editing the default script doesn't really work that well because I'd end up with a template meant for a different project.

    It'd be nice to have per-project templates.
     
  35. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    Based on the documentation's diagram of references, if I put scripts in Plugins, they are automatically accessible to assemblies. This doesn't seem to be the case though, do we need to put assembly definition everywhere when we start using them?
    In the past I'd use plugins as a way to move stable code out of the main assembly and speed up compile.
    bug# 970184
     
    Last edited: Nov 18, 2017
  36. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    sometimes recompile doesn't happen when I press apply after adding a reference in an assembly definition.
    bug# 970183
     
  37. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    Early experience with assembly definition: very positive, compile time is very fast, with editor freeze being the bulk of time spent (I think it's reconnecting all the stuff in the assets), it's very useful as an incentive to separate responsibilities and the result is much cleaner code.
    At this point it is not production ready however, it breaks often, sometimes corrupting an entire project in a way that I haven't managed to recover from and the rules of reference aren't always clear.
    When everything works ... :cool:
     
  38. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    I've added a note about this and will keep this in mind when I have a look at adding support for default namespace.

    The issue here is that we used the term "Plugins" both to denote the "Plugins" folder and the precompiled assemblies (.dlls) Plugins that are imported by the PluginImporter.

    .asmdef files do not reference the scripts compiled in the Plugins folder, which would be compiled into Assembly-CSharp-firstpass.dll. This assembly falls into the category of Predefined Assemblies. We will update the docs to clarify this.

    The compile errors in project can be fixed by adding a missing reference to an .asmdef file. See bug report reply for details.


    Editor freeze is because we reload all the assemblies. Typically we see long reload times when users have lots of code in InitializeOnLoad, Awake and other methods called during the reload. Figuring out what script code is causing the delay today is somewhat tricky, but we are working on a better solution.

    The way to find script code that can cause long reload times today:
    1) Open the Profiler, enable deep profiling and profiling in the editor.
    2) Keep the profiler window visible, because you will need to "quickly" disable editor profiling.
    3) Enter play mode
    4) Once enter play mode is finished, exit play mode and disable editor profiling.
    5) Find the frame that takes a long time to complete and then find scripts that run for a long time.

    Example:

    Code (CSharp):
    1. public class Sleepy : UnityEngine.MonoBehaviour
    2. {
    3.     void Awake()
    4.     {
    5.         System.Threading.Thread.Sleep(2000);
    6.     }
    7. }
    And here I found the Sleepy.Awake in the profiler.
     
    Last edited: Nov 19, 2017
    steffen-itterheim and x4000 like this.
  39. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    4,380
    Any specifics on what you're thinking about? A "keep frames that take longer than a certain amount of time" button would be great both in the editor and in play mode. Having the number of frames that are stored be dependent on your screen width is also a bit bonkers.
     
    dadude123 likes this.
  40. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    I am doing that, apply doesn't push a recompile, that's the bug.

    Instead of updating the doc with this rather subtle difference (I'll surely miss it as a first user) is there a way that you guys make .asmdef auto ref any script inside plugins? If not, why.

    It makes sense. I didn't even know about [InitializeOnLoad], do you use that to not break a playing scene when hot-recompiling?
    In any case I think the freeze I am noticing is just the default unity reconnecting scripts to stuff, which depends on how many scripts are inside the scene, I think. If you know the details of that, it'd be great.
     
  41. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    I had a look at the project and the precompiled assembly Assets/Plugins/AdvancedInspector.dll has a reference Assembly-CSharp-firstpass.dll, which is no longer compiled when using .asmdef files. The author of AdvancedInspector needs to fix this issue, as AdvancedInspector.dll needs to be recompiled without referencing Assembly-CSharp-firstpass.dll. You can see the errors with Assembly-CSharp-firstpass.dll in the Editor.log.

    We prototyped this a bit and currently we look for specific root profiling names, like for instance "EnterPlaymode" and save those frames. I think also adding support for a time threshold and saving those frames also makes sense.


    This issue did not reproduce for me. You can reply to the bug with more details and possible a video showing this behaviour and we can take it from there. The only thing I can think of that would make this happen is if there are still compile errors after pressing Apply and that is why you didn't see the recompile.

    This would cause circular references. Assembly-CSharp-first.dll already automatically references all .asmdef assemblies and we therefore not make .asmdef assemblies reference Assembly-CSharp-first.dll. The idea with .asmdef assemblies that thirdparty uses can use it and when you drop them into your project it just works, because Assembly-CSharp.dll and friends auto reference them. You can think of the .asmdef assemblies as having the same behaviour as precompiled assemblies (.dlls), but they are just compiled in Unity instead of being precompiled.

    See dependency graph in docs:
    https://docs.unity3d.com/2017.3/Documentation/Manual/ScriptCompilationAssemblyDefinitionFiles.html

    [InitializeOnLoad] just provides a mechanism for initializing code after load of assemblies.

    The delay you are describing is Unity making a backup of all serialized MonoBehaviour data in the scene before unloading all the assemblies and then applying the backup to the MonoBehaviours in the newly loaded assemblies. You would need to a have very big scenes for this to have an impact on domain reload times.

    The backup and restoring of the MonoBehaviour data also shows up in the profiler as "SerializeBackups" and "DeserializeBackups". I would recommend that you use the profiler to see what is causing the long Unity freeze and if there anything you could change in your project to reduce it.
     
    Last edited: Nov 20, 2017
    laurentlavigne likes this.
  42. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    2,124
    Thanks a lot for all the details, I'll do that.
    One thing came to mind, I use lots of sciptobjects, they probably impact the time this takes.
     
  43. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    In general I'm loving this, and finding it super easy to use. The amount of time I'm saving with code changes is insane.

    A couple of comments/requests:

    1. Right now it's not possible to tell what assemblies are being compiled at any given time. For instance, I understand the dependency graphs that are in your docs, and so I can intuit what is going on. But if I was less experienced in scripting, or if I just frankly make a mistake, I might be accidentally causing a chain of compilations that are undesirable and unexpected.

    2. When you've got precompiled dlls that are inside a folder that has an asmdef file inside it, then... strange things happen. I'm not sure what exactly is happening, but the precompiled dll doesn't seem to be available to unity in general, so perhaps it's skipping the plugin importer in general? To recreate this, you can just download ProBuilder (which works fine) and then slap an asmdef file in its root ProCore folder (and then it freaks out not able to find any of its dlls). Same thing for UBER, and a variety of other assets.

    The workaround for #2 is simply to move those dlls out into the root folder, or into some non-asmdef folder like ZExtraDLLs or whatever you want to call it. But that's going to throw a lot of people for a loop (sure did me), and is going to be minor chaos for a variety of asset store assets.

    That's all I have, though -- this is fantastic stuff!
     
    dadude123 likes this.
  44. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Regarding this, I have a couple of points of confusion. When you say "we reload all the assemblies," do you mean ALL the assemblies? Even the ones that were not changed in the current compilation?

    And secondly, when we're talking about the Awake() method, is that something that's being called on all scene objects in the editor when you're NOT in play mode and the scripts are NOT marked execute in edit mode? (Sorry for the all caps NOTs, that might seem aggressive but honestly it was just hard to denote so many negative qualifiers in one sentence!)

    Basically I'm referring to the editor freeze that happens after a compile, not the editor freeze that happens when I press play. The Awake() thing makes perfect sense when I press play. But are non-execute-in-edit-mode scripts with Awake() methods being executed after a compile?

    That would be rather problematic, because I'm using Awake() in my scripts a lot of times to do things like define singletons where needed and set up other global stuff, and then using Start() to actually reference those singletons or other data objects that were set up and are now known to exist. It's a handy two-pass system you have set up, but if I'm shooting my after-compile-freeze-time in the foot with that, I'll need to figure out something else.
     
  45. Tallek

    Tallek

    Joined:
    Apr 21, 2014
    Posts:
    26
    I had a chance to play around with this feature recently and had some feedback.

    Option to choose or prevent plugin references.
    Right now, all my dll plugins get referenced by asmdef assemblies. I would love the ability to pick and choose which plugins are referenced. If not that, then at the very least it would be nice to have the option to disable plugin references entirely. We have some mod API assemblies that we would like to provide to modders with the intent that they pull them in to Unity, but we don't want them mixed up with other assembly references (particularly asset store stuff). Also, from a code organization standpoint, its nice to have collections of common scripts we can move from project to project without extra dependencies. Preventing plugin references will make it easier to prevent accidental dependencies from getting created for these types of things.

    Don't add non-script assets outside of the asmdef folder to the csproj files
    We have lots of xml, text, and shader files (and probably other stuff) scattered about our project. All these end up in every csproj file that gets created. It clutters up all the projects. Ideally, these asset files would only end up in the project file for the asmdef they should be associated with, per the same rules that the code files follow.

    Unnecessary folder nesting in created projects.
    Could we get the project file created alongside the asmdef? Its not the physical location of the project file that bothers me really, its the unnecessary nesting of folders in the created project. Say I have 20 scripts I want in an asmdef assembly in a folder like "Assets/Foo/Bar/Common". If i want to edit one of those scripts in Visual Studio, I expand the project, then 'Assets', then 'Foo', then 'Bar', then 'Common', and finally I'm where i want to be. That seems like unnecessary clutter. If the asmdef is at the 'Common' folder level, then I'd love to be able to expand the project and see those 20 scripts immediately... not expand a bunch of folders first.

    Ability to choose default namespaces.
    It would be great if we could specify a default namespace for the project in its asmdef file. In the "Assets/Foo/Bar/Common" example above, I'd want my default namespace to be "Common", not "Assets.Foo.Bar.Common".

    Automatic '.Editor' project creation for 'Editor' folders.
    If I have an asmdef for a Common.dll at "Assets/Foo/Bar/Common" and an "Editor" folder under "Common", It would be fantastic if a Common.Editor project would be automatically generated.
     
  46. x4000

    x4000

    Joined:
    Mar 17, 2010
    Posts:
    307
    Seconded on these two -- the first one in particular. It gets super confusing in the first case with the non-script assets from all sorts of other folders being added. I have something like 9 asmdef projects defined, and each of them has txt and xml files in them, so every project in VS winds up having a copy of all 9 folders trees. It's particularly confusing for shaders, but either way it's not a crisis.
     
    dadude123 likes this.
  47. Foriero

    Foriero

    Joined:
    Jan 24, 2012
    Posts:
    470
    Hi, will ADF work with VS for Mac?
     
  48. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    We have some documentation/blog posts planned that will document the details of the reloading assemblies, so I won't go too deep into it now. But basically we use the .NET Application domains isolation feature to support hot reloading of assemblies in Unity. We load all assemblies into one domain, then on recompile we need to reload the new assemblies and on enter playmode we reload all assemblies to reset all state, like statics, etc. We reload the assemblies by unloading the old domain and creating a new domain to load all the assemblies into. This is as fine grained as reloading of assemblies in .NET gets. Loading of the assemblies into the .NET (Mono) runtime scales very well and is not really an issue, the issue is all the methods that Unity invokes during the reload of assemblies.

    Yes, OnEnable and Awake will be called on all MonoBehaviours after reloading assemblies. Please use the profiler to see how this affects your recompile times.

    Generally speaking, I would advice against using [ExecuteInEditMode], there are various design issues regarding this feature which makes it behave differently than you would expect if you get too fancy with it's usage.
     
    Last edited: Nov 21, 2017
  49. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    I can see preventing all plugin references making sense, isolating your .asmdef code to only reside in .asmdef assemblies. Making a note of this.

    This issue has already been fixed and should land soon(TM), keep an eye out for the release notes :)

    I think Visual Studio/VSTU and Visual Studio for Mac already does this. Make a note of this and will look into it for our own built solution generator for MonoDevelop/JetBrains Rider/VS Code.

    This feature was already requested previously in this thread and I've added this to my backlog.

    By design the .asmdef system does not take the magic folders into account. You will need to add a .asmdef file to editor folder manually and set the platform to Editor only.
     
    dadude123 likes this.
  50. lukaszunity

    lukaszunity

    Unity Technologies

    Joined:
    Jun 11, 2014
    Posts:
    434
    Yes, it should be supported. Visual Studio for Mac also uses VSTU for Unity integration, like Visual Studio on Windows.