asmdef questions

1) can you explain to me what this is and what its purpose is:



2) is there a way to reference a package inside an asmdef in such a way that the package is automatically downloaded?

 

I did this which looks promising



but then I did this and it seems to not work (same asmdef):

 

this worked





edit: wrong module but it works with the right one too

 

That's a great feature, but I wonder is there are plans to also support custom packages (not only Unity modules and the built-in com.unity.* packages)? @HaraldNielsen

 

Thanks for the response! Maybe I misunderstand something, but I can't see my custom assembly in the `Version Defines` list, even if it's added to the `Assembly Definition References`. Consider a project, where two custom asmdefs are defined; I want to add one of them as a dependency for another. While both asmdefs are visible in the `Assembly Definition References` list, none of them appear in the `Version Defines`:

 

Could it be `Version Defines` only work with the new package manager packages, but not with asmdefs directly? It's much less useful then, as in the most cases third party stuff is distributed via .unitypackage archives (actually, I've never seen a single non-Unity package distributed via the package manager). Could we hope for `Version Defines` to support asmdefs directly? @karl_jones @HaraldNielsen

 

Sure, I can edit it, but it still expects a package name. Any chance it'll also be possible to use an asmdef GUID (or name)? (in the same way as `references` property works)

 

Yeah, I got that, thanks. The issue is that most of the third-party stuff is distributed out of that packages system, so the defines will be much more useful if they'll support direct asmdef references in addition to the packages; this will also allow more flexible and granular dependency setups.

 

This doesn't work at all.

If I define a Version Defines for Physics 3D, it's there even if Physics 3D is not installed.



Conditional code that is supposed to be able to detect that and compile - simply fails. I believe this is the purpose of this functionality, and it doesn't appear to work at all. I'm trying to use this so that my plugin can compile even if you don't have Physics installed, and you will just lose certain functionality. Please advise. I don't believe there is any other way to accomplish my goal here short of a user adding DEFINE's into their project, which I want to avoid.
It's also possible that the result of the Version Define isn't getting recalculated and is holding an outdated value. I don't know what triggers that.

 

@karl_jones Since you suggested editing the corresponding ASMDEF JSON, how do you cope with the package version? I checked out com.unity.modules.physics and it's JSON looks like this:

Code (CSharp):

1. {
2.     "name": "com.unity.modules.physics",
3.     "version": "1.0.0",
4.     "type": "module",
5.     "displayName": "Physics",
6.     "description": "The Physics module implements 3D physics in Unity. Scripting API: https://docs.unity3d.com/ScriptReference/UnityEngine.PhysicsModule.html",
7.     "icon": ".icon.png",
8.     "dependencies": {
9.  
10.     }
11. }

Can we just add the missing fields to the ASMDEF JSON or is not not working that way? How do you define the version of an ASMDEF so you can reference it. I guess the part with HOW you reference it is already covered as you answered @Elringus

 

This is a little old but right now these versioning only looks at the packages installed in the project. Not the assemblies reference by the asm def. It would be nice if it was also to work on the definition references.

While one version of my libaries in the project may include the TMPro in the asmdef.
Another project i may not want to enable that feature, even though TMPro is in the project being used by something else.

Or if there were defines created for each reference for example

#define PACKAGE_DID_SINGLETONS
#define PACkAGE_TMPRO

 

So far as I can tell this is still broken, 2+ years later, in 2019 LTS. The *only* way to get VersionDefines to work with anything except Unity's hardcoded stuff and packages is ... to ignore the Inspector and manually edit the text files. It's a shame. The inspector was only half-implemented .

 

In 2019 you said:

It's now 2022, and it's still not true. It's still not documented. It still doesn't work. Confirmed BROKEN in both 2019.LTS and 2020.LTS

Anyone figured out the hacks to workaround this, make it work, yet? STILL NOT IN THE DOCS.

 

I feel people in this thread have talked above each other's head. BTW, yes, I also would like to see the possibility to set version define referencing another assembly definition instead of a package.

 

@karl_jones - An hour or two ago I made a minimal test case and submitted it as a bug report in 2020 LTS.

 

I'd like to see this implemented too

 

My bug report(s) were rejected by QA staff who apparently didn't really understand what 'assembly definitions' are, what 'version defines' are, or how to use them. I eventually asked them:

"As I showed in my bug report: accessing asmdefs - which is the ONLY
WAY Unity allows code to be written on the AssetStore - appears to
bypass the versiondefines, leading to incorrect results.
...
If you have a way for: [I re-described the problem in simple bullet points]
...
then please show me how - the project I uploaded shows that this failed. Did I do something wrong? What do I have to do additionally to make it succeed?"

That was 26 days ago with no response.

@karl_jones this is why requests for us to log bugs often aren't received well -- your colleagues keep blocking bug-reports, apparently because of their own lack of training / understanding (like the time where QA rejected a bug report a Unity Engineer had asked me to file and along with the rejection I was told to post on the forums for community help instead).

What is going on? It looks bad - as if QA just close anything on topics that are beyond their experience-level / skill-level.

Also: how do I log a bug in Unity so that it actually gets looked at by a software engineer?

 

(I mean - I would LOVE it if I've just been using it wrong all this time, if there was some secret undocumented setting I could use that would simply make this all work. Or if there was some other step I was supposed to be doing but hadn't (and which is missing in the UnityEditor as a warning/error - because right now it just 'fails') -- then I could start using this feature immediately. If that makes me look stupid because it was something I should have known from the start - great! My problem is solved!)

 

Thanks! Case 1395717 - and if you look at it and say 'oh, a436t4ataf you fool! you did something stupid / misunderstood this!' then I'll be very happy to hear it - I feel I've been back and forth experimenting on this, reading the docs literally 10 times over, emailing and discord chatting with other devs who've tried this and couldn't get through it either.

Also there's possibly multiple issues (I tried filing multiple bug reports to make it clearer, but it ended up seeming like it was only one single underlying issus)

 

This is the shocking problem: Unity's AssetStore has explicitly blocked Packages since they were introduced, and officially still has zero plans to allow them. So whiel the Unity PackageManager team(s) spent the same period refusing to provide features or fixes to core functionality "because you can create local Pacakges / use asmdefs / use VersionDefines", we are left with no way forwards.

 

Until/unless the scripting team is willing to talk to their colleagues in the AssetStore and/or PackageManager teams and force them to change policy ... that isn't an acceptable solution.

This would be massively better than "nothing" - which is all Unity allows us to use today (I say "allows" because we have - as far as I'm aware - no APIs to control any of the linking/building behaviour here, so there's literally nothing anyone who is not a Unity employee can do about any of this).

That is the least of our worries right now. Right now everyone is doing MUCH WORSE hacks because Unity is blocking this. Yes, actual version handling would be far better. But at least a binary on/off would allow great improvement for everyone.

Additionally: I suspect (would love input on this) this would enable us to self-fix a lot of other bugs in Unity's current build/link system, e.g. multiple problems with DLLs that Unity so far keeps refusing to fix or even consider -- if we could wrap DLLs in asmdefs (which we can sort-of do today), and had this 'merely binary on/off' linking feature, we could intelligently enable/disable which DLL's are linked. The current actually in use by publishers solution to that is - literally "write a binary that runs outside of Unity's core and pre-renames DLLs out from under Unity, live, and at import time run similar scripts that mess with the file-system, renaming DLLs to ".not-a-dll", and back to ".dll" to do all the things Unity should be doing but isn't, and eventually leaves the Editor with only one DLL that's linkable".

That's ... horrific. And it only happens because Unity's blocked everyone from doing any kind of selection of DLL's/asmdef linking apart from the "One Weird Exception" that is "you can have two DLLs with the same name if and only if one is marked Editor only, and the other is marked not-Editor" (NB: that trick *only* works for Editor/non-Editor, no other pairing seems to work - suggesting it's been special-cased somewhere).

 

The performance team at Unity has already done some pretty neat (and massively useful) work in this area that ... might already have solved this problem?

I only started using it recently, but the TypeCache stuff gathers a lot of metadata (currently: type names, types, type-inheritances, custom attributes, ... ) early in the process and then caches it, specifically because this kind of metadata request is needed throughout the Editor (by Unity, as well as by developers and publishers) but is slow to generate and - by definition - cannot change except during Assemlbly reload.

... I don't know exactly where in the rebuild that gets generated, but my understanding it was super-early. Maybe (maybe!) early enough that it could be used for this too? AssemblyVersion is - if I remember correctly - nothing more or less than a CustomAttribute within C#?

 

So, the TL;DR as I understand it is:

1. DLLs in Unity are broken for most (all?) non-trivial examples; you cannot (for instance) support even Unity's own Input System today in an Asset (because it requires compile-time #if's and Unity provides no way for anyone to have multiple DLL's, except for Unity's own internal 'magic' for Editor DLL's).
2. AssetStore Bundles require proprietary hacks by ... everyone ... because Unity added this feature on the payment side, but has not added anything that would allow anyone to use it on the compile/build side.
3. Cross-Asset references between diferent authors (extremely common on the asset-store today) are liable to break without notice, require proprietary hacks, and there's no safe way around it.
4. Nothing's going to get fixed for another few years, until a whole new build system is created. Since asset-store publishers have to wait 3 years before we can use new features, that means we're looking at 'this will all be broken until 2028 at earliest'.

?

It doesn't seem like an acceptable outcome -- it materially damages asset-store development, and is one of the few reamining reasons people object to using asmdefs ("it messes up assets"). This just seems like a really poor choice.

 

Sure -- a long term fix is also necessary, and switching to a more standards-compliant usage of MSBuild stuff seems like a no-brainer in the long-run.

But these aren't new features - asmdefs were introduced going on 4-5 years ago, and they still don't work for anything except a narrow slice of the common/widespread use-cases.

Asset store publishers seem to be trapepd between two parts of Unity that refuse to synch their roadmaps - PackageManager and Asmdefs/builds.

Even if we ignore/sideline publishers (and pretend Unity doesn't care about the AssetStore), this can't be great for large projects either. From my informal chats with larger studios -- they too hate this, it's like asmdefs were a nice idea half-implemented and then discarded, they don't actually make things better for us on real projects .

 

Thanks, I look forward to that!

Although I must say: Three years ago it would have made sense for this to be fixed at the asset-store. It's stunning that the PackageManager was launched without planning any of this, and that asmdefs were first beta-tested and then made production/live -- again without apparently anyone asking 'will it actually work on Unity's own asset store?' .

But fast-forward to today and I feel the situation is different, the problems have got bigger. Now we have a bunch of problems both on the asset store AND in projects, all of which would be solved by what seems - as an outsider - to be a very small number of features, specifically: obvious missing functionality in asmdefs.

 

2023.. and here we are, still empty handed

 

So an asmdef outside of the packages doesn't have a version as there's no json specifying it, plus being this asmdef from another package from the asset store, it may not be configured in any way to have a version.

Could you then just assume the version it has is 0.0.0? That way we can make an expression that checks against that and treat it as an on-off switch for asset store package interoperability. If in the future the package has a version (somehow, after implementing a feature that allows specifying versions on asmdefs or something), it won't be 0.0.0, it will be higher and distinct.

 

Still disappointing that there is no official solution.

I have resolved to adding script defines upon compilation. Like this:

Spoiler

Code (CSharp):

1.  
2. #if UNITY_EDITOR
3. using System;
4. using UnityEditor;
5. using UnityEngine;
6.  
7. namespace YourNameSpace
8. {
9.     public static class AssemblyDefinitionDetector
10.     {
11.         public static void DetectAndUpdateDefine(string assemblyName, string define)
12.         {
13.             // Check if the asmdef file exists (if not then the asset has been removed).
14.             // We do NOT use reflections on the assemblies here because even if the asset files
15.             // have been removed the assemblies are still loaded and this would give a false positive result.
16.             bool found = false;
17.             // Nasty string search. n2h: use regexp.
18.             string defineNameJsonString0 = "\"name\": \"" + assemblyName + "\"";
19.             string defineNameJsonString1 = "\"name\":\"" + assemblyName + "\"";
20.             var defines = AssetDatabase.FindAssets("t:AssemblyDefinitionAsset");
21.             foreach (var defGUID in defines)
22.             {
23.                 var path = AssetDatabase.GUIDToAssetPath(defGUID);
24.                 var asset = AssetDatabase.LoadAssetAtPath<TextAsset>(path);
25.                 var text = asset.text.Substring(0, 100); // only search in the beginning of the text.
26.                 if (   text.Contains(defineNameJsonString0)
27.                     || text.Contains(defineNameJsonString1))
28.                 {
29.                     found = true;
30.                     break;
31.                 }
32.             }
33.  
34.             // Add or remove defines.
35.             if (found)
36.             {
37.                 // InControl is installed
38.                 addDefineSymbol(define);
39.             }
40.             else
41.             {
42.                 removeDefineSymbol(define);
43.             }
44.         }
45.  
46.         private static bool addDefineSymbol(string defineName)
47.         {
48.             bool didChange = false;
49.  
50.             foreach (BuildTargetGroup targetGroup in System.Enum.GetValues(typeof(BuildTargetGroup)))
51.             {
52.                 if (isObsolete(targetGroup))
53.                     continue;
54.  
55. #pragma warning disable CS0618 // Type or member is obsolete
56.                 if (targetGroup == BuildTargetGroup.Unknown || targetGroup == BuildTargetGroup.GameCoreScarlett)
57.                     continue;
58. #pragma warning restore CS0618 // Type or member is obsolete
59.  
60.  
61. #if UNITY_2023_1_OR_NEWER
62.                 string currentDefineSymbols = PlayerSettings.GetScriptingDefineSymbols(NamedBuildTarget.FromBuildTargetGroup(targetGroup));
63. #else
64.                 string currentDefineSymbols = PlayerSettings.GetScriptingDefineSymbolsForGroup(targetGroup);
65. #endif
66.  
67.                 if (currentDefineSymbols.Contains(defineName))
68.                     continue;
69.  
70. #if UNITY_2023_1_OR_NEWER
71.                 PlayerSettings.SetScriptingDefineSymbols(NamedBuildTarget.FromBuildTargetGroup(targetGroup), currentDefineSymbols + ";" + Define);
72. #else
73.                 PlayerSettings.SetScriptingDefineSymbolsForGroup(targetGroup, currentDefineSymbols + ";" + defineName);
74. #endif
75.                 Debug.Log($"{defineName} symbol has been added for {targetGroup}.");
76.  
77.                 didChange = true;
78.         }
79.  
80.             return didChange;
81.         }
82.  
83.         private static void removeDefineSymbol(string defineName)
84.         {
85.             foreach (BuildTargetGroup targetGroup in System.Enum.GetValues(typeof(BuildTargetGroup)))
86.             {
87.                 if (isObsolete(targetGroup))
88.                     continue;
89.  
90. #pragma warning disable CS0618 // Type or member is obsolete
91.                 if (targetGroup == BuildTargetGroup.Unknown || targetGroup == BuildTargetGroup.GameCoreScarlett)
92.                     continue;
93. #pragma warning restore CS0618 // Type or member is obsolete
94.  
95. #if UNITY_2023_1_OR_NEWER
96.                 string currentDefineSymbols = PlayerSettings.GetScriptingDefineSymbols(NamedBuildTarget.FromBuildTargetGroup(targetGroup));
97. #else
98.                 string currentDefineSymbols = PlayerSettings.GetScriptingDefineSymbolsForGroup(targetGroup);
99. #endif
100.  
101.                 if (currentDefineSymbols.Contains(defineName))
102.                 {
103.                     currentDefineSymbols = currentDefineSymbols.Replace(";" + defineName, "");
104. #if UNITY_2023_1_OR_NEWER
105.                     PlayerSettings.SetScriptingDefineSymbols(NamedBuildTarget.FromBuildTargetGroup(targetGroup), currentDefineSymbols);
106. #else
107.                     PlayerSettings.SetScriptingDefineSymbolsForGroup(targetGroup, currentDefineSymbols);
108. #endif
109.                     Debug.Log($"{defineName} symbol has been removed for {targetGroup}.");
110.                 }
111.             }
112.         }
113.  
114.         private static bool isObsolete(Enum value)
115.         {
116.             var fi = value.GetType().GetField(value.ToString());
117.             var attributes = (ObsoleteAttribute[]) fi.GetCustomAttributes(typeof(ObsoleteAttribute), inherit: false);
118.             return (attributes != null && attributes.Length > 0);
119.         }
120.     }
121. }
122. #endif

Then the code for detecting the InControl asset (which uses asmdef with name "InControl") looks like this:

Code (csharp):

1. #if UNITY_EDITOR
2. using System;
3. using UnityEditor;
4. using UnityEditor.Compilation;
5. using UnityEngine;
6.  
7. namespace YourNameSpace
8. {
9.     public static class InControlDetector
10.     {
11.         [InitializeOnLoadMethod]
12.         public static void AutoDetectAndUpdateDefine()
13.         {
14.             if (!EditorApplication.isPlayingOrWillChangePlaymode)
15.             {
16.                 DetectAndUpdateDefine();
17.  
18.                 CompilationPipeline.compilationFinished -= onCompilationFinished;
19.                 CompilationPipeline.compilationFinished += onCompilationFinished;
20.             }
21.         }
22.  
23.         private static void onCompilationFinished(object obj)
24.         {
25.             DetectAndUpdateDefine();
26.         }
27.  
28.         [MenuItem("Tools/Settings Generator/Debug/Detect InControl", priority = 1101)]
29.         public static void DetectAndUpdateDefine()
30.         {
31.             AssemblyDefinitionDetector.DetectAndUpdateDefine(
32.               assemblyName: "InControl",
33.               define: "KAMGAM_INCONTROL");
34.         }
35.     }
36. }
37. #endif
38.  

It adds the define automatically.


However, it's not ideal since it does a simple string check in all asmdef assets (which is ugly).