Version Defines of assembly definitions

In Unity 2019.1 a new option named “version defines” for asmdef files appeared, but it’s not documented in any way (or I wasn’t able to find it).

Afaik, it allows to create assembly-wide defines based on whether a specific package is installed. This is a great feature, which I’ve been really waiting for, but it seems that currently it only support the built-in Unity packages (eg, TMPro, SRP, all the modules, etc). I wonder if there are plans to extend support for user packages as well?

FYI, you can manually edit the asmdef (if you have text serialization) and add your own user packages that way.

Here’s an example from one of our projects:

HealthScholars.Utilities.asmdef:

    "versionDefines": [
        {
            "name": "com.healthscholars.voice",
            "expression": "1.0.0",
            "define": "VOICE_EXISTS"
        }

Once you do that, you’ll see the value you entered as the name appear in the inspector, and you can edit everything else as normal.

2 Likes

Manually editing the asmdef does not seem to inject a define symbol into the project settings. Is there any official clarification on how this can be accomplished when not building an asmdef as a package?

3 Likes

@Julien-Lynge I have been wanting to try this approach, but finding it difficult to find the ‘name’ for a given asset on the asset store. For example, if I want a define setup to know whether a user has the SteamVR plugin installed in the project, I should be able to use an asmdef for this by manually adding in the asset as you described, right? If so, how do I find out the ‘name’ (com.valve.xxx) for the asset?

You can see the names and versions of all installed packages in the [Project folder]/Packages/ directory. For instance, the manifest.json shows the identifiers for all the installed packages.

Yeah thanks I found that soon after. The problem now I’ve recently found though is that things such as SteamVR aren’t considered as ‘Packages’. When imported from the Asset Store, they are found under ‘Assets’ and so they do not show up in the dropdown on the Version Defines section of the asmdef. There is also no record of it in the manifest.json.

Do you know if it’s possible to use asmdef for Asset Store packages? Not sure how else I can do a conditional compilation based on those packages being imported/installed.

For those interested I made a script that adds defines via code, it’s not for versions/conditions, but you can at least see how adding simple defines from code can work.

2 Likes

In case somebody is wondering, if you still want to support Unity 2018, even though It doesn’t have Version Defines in assemblies, you can add them in another version and the assemblies will work anyway.

1 Like

I thought I got this working before on a previous project, but now I cannot get it to work on any LTS version (2020, 2019).

Did you ever get it working?

The docs are still (in 2022) missing - they now have some docs for the field, but only document how to reference Packages (where Unity staff claimed 3 years ago that it supports asmdefs too, even though the editor still doesn’t)

Where can I read about this? It is an interest of mine. Do you have a link where they are talking about this?

1 Like

“It works with any asmdefs, including those in custom packages.”

2 Likes

I gave up trying to do this and moved on to something that works. Maybe someone will figure out what this is for and it will be magical one day.

BTW, so far, I’m doing this:

  • I only use the version define what the manual says it can do: define a symbol if a specific unity or a custom package is present (either mine or someone else’s), this part of my code can rely on this
  • I use the ConditionalCompilationUtility for other assemblies.
2 Likes

I’ve gone ahead and filed a bug on it. After reading all the docs I can find, I can only conclude that it’s just not working - it’s not our fault, the code isn’t there.

I suspect that internally the decision was made to do this ‘for Packages only, in the first iteration’. That was an unfortunate decision 3 years ago, but OK fine … However: 3 years later Unity still does not allow Packages on the AssetStore lifting this up from ‘short-sighted design decision’ to ‘bug’.

FYI: Jason Booth’s Microsplat series are package-packages on the Asset Store. They install in the Packages folder (not in the PackageCache, in the Packages, so they become local package). Maybe talk to him how does he do that. :slight_smile: Since I’m not a publisher, I have zero idea what’s really allowed and what is not.

They aren’t. He converts them into non-Packages before upload. And the way he does it recently cost him 3+ months of revenue, IIRC, because only one person at Unity is allowed to review such ‘unusual’ packages. It’s a hot mess on Unity’s side. Using Packages is still unsupported/disallowed by Unity, after years and years of them dragging their feet.

Well, they are.
7816899--988917--screenshot.png

Just installed the latest 3.9.9.

? They took down his assets? I doubt it…

Anyway.

Here is the 3rd-party system Jason uses: GitHub - needle-tools/hybrid-packages: Export UPM packages as .unitypackage files - it’s not the same as Packages, it’s a workaround - and causes other problems. If you want more info on his recent struggles - what happened, what Unity’s explanation was, and how it’s affected him - feel free to look on the Publishers forum here, he’s been pretty clear about it.

Link to that drama?

Also, was the original poster’s situation ever resolved? I found myself needing to make a version define for third party asset store plugins and haven’t found a solution yet.

If you have access to the publishers forum, and care enough, you can search for jason’s posts there. Or you can go on discord and ask him directly. The TL;DR is that Unity only had one member of staff “allowed” to hit ‘OK’ on assets that use this special upload process, and that person went on holiday (allegedly!) and no-one bothered to cover for them. So assets were simply (silently) blocked from the assetstore until that person came back (a looooong time later).