Assembly Definition Files

[martindevans]

Alexeess requests support for assembly definition files.

[Alexees]

The feature is fairly new in Unity. It works by creating Assembly Definition Files on a per folder basis. All scripts in that hierarchy then gets compiled into one assembly for each file, which does not recompile unless something changed inside of these folders scripts. This saves compile time on large projects.
But since they work on a per folder basis and the dissonance files are split across two parallel folders, all references from one folder structure into the other fail when the access is on an internal restriction level, because it's basically two different Assembly.

[martindevans]

I've been working on another project in the very latest version of Unity (partly as a way to learn all of this new stuff) and I think I understand assembly definitions pretty well. I think it should be fairly easy for me to support them :)

[martindevans]

I've just checked out setting up asmdefs in Dissonance and it seems to work with the current layout of Dissonance files.

• In Assets/Plugins/Dissonance create a definition called Dissonance which references nothing
• In Assets/Dissonance create a definition called DissonanceIntegrations which references Dissonance
  • When you install an integration, it will become part of this assembly

This works because the internal attributes which you mention (defined in Jetbrains.cs) are defined twice by Dissonance. Once in Assets/Plugins/Dissonance/Core and once in Assets/Dissonance/Core. So they're internal, but that's fine because they're only ever used from inside the new assemblies you've defined. This is essentially how Dissonance is already setup - Unity implicitly turns Assets/Plugins into a separate assembly from everything else in Assets.

I'm not completely certain if/how/when we'll distribute this in Dissonance. We try to keep differences between Unity versions versions to a minimum and we don't really get a huge advantage from asmdefs because we're basically already using them with the implicit Plugins assembly system. Longer term we're going to want to re-organise the project to support the package manager (#111), so I'll hold off for a while to see exactly how the whole packages story develops for asset publishers.

[martindevans]

I just realised my previous response wasn't quite correct, sorry about that. The problem is that while my previous response works in editor it fails when you try to build the standalone player because all of the editor only stuff has been bundled up into the same assembly definition (which of course cannot work in player).

So you need to create more assemblies:

1. Assets/Plugins/Dissonance/Dissonance.asmdef
2. Assets/Plugins/Dissonance/Editor/DissonanceEditor.asmdef (references 1)
3. Assets/Dissonance/DissonanceIntegrations.asmdef (references 1)
4. Assets/Dissonance/Integrations/{Integration_Name}/Editor/Dissonance{Integration_Name}Editor (references 1, 2 & 3)

Now this will cause problems because some of these assemblies now try to access internal items in other assemblies. Rather than making all of these things public (which would make the API surface of Dissonance very messy) you can expose these internals to specific other assemblies.

Find Assets/Plugins/Dissonance/Core/AssemblyAttributes.cs, you can insert lines like this:

[assembly: InternalsVisibleTo("DissonanceEditor")]
[assembly: InternalsVisibleTo("DissonanceEditor.dll")]

To expose all the internals of this assembly to the assembly named DissonanceEditor (you need both of these, due to a bug in Unity). Now the editor can access the internals of Dissonance. You may also need to do the same in DissonanceIntegrations to expose internals to your integration editor assembly.

I'm probably going to include these changes in the next version of Dissonance, shipping in the 2018.1+ versions of Dissonance.

[martindevans]

Tom has just merged a PR of mine which partially solves this problem (and will be in the next release). For now all I've done is add the appropriate InternalsVisibleTo attributes so that if you create your own asmdefs (with the right name) they'll work as expected.

We didn't ship the asmdefs themselves for a couple of reasons:

• Not everyone will want to use them. Adding them to Dissonance by default will make things unnecessarily complex for anyone not using them.
• It makes support/release a lot more complex with every platform dependent change we make.
• Longer term we'll be probably be swapping over to using the package manager and whether that's going to be based on asmdefs or not is unclear at the moment. We'll re-assess when the package manager is properly available to asset publishers.

[Alexees]

@martindevans I'm impressed about the effort you took to implement them. It's always nice to see others keeping up with Unity's latest versions for future upgraders to come.
I must admit that I'm not using ASMDEFs at the moment. Those specific to platforms not currently active are not stripped when using .NET, which is going to be deprecated, and IL2CPP does not work for me as it gives me a bunch of cryptic errors when run. None of your business, but maybe interesting to know.

[martindevans]

Dissonance 6.2.5 is live on the asset store with the changes made to Dissonance to support users adding asmdefs. Check out the documentation here to see exactly which asmdef files you need to define.