Runtime variable used to work, now it's never translated when resolving URL

I get this error and I have been working on a solution for hours with no avail:

2024/05/22 20:27:48.831 13458 13542 Error Unity Unable to open archive file: Config.CDNURLAndroid/packedassets_assets_ui/ranks_8a09a8a41253baeb47772f1246a9c3b6.bundle

The report shows it to have the correct and expected variable:

which I of course declare and set at run time

public static class Config
{
    //this is actually used even if it's greyed out
    //https://docs.unity3d.com/Packages/com.unity.addressables@1.21/manual/ProfileVariables.html
    //it's used by addressablesa
    public static string CDNURL;
}

Config.CDNURL = gameConfigVO.data.cdnURL;

I recently changed the project settings, but this shouldn’t have stopped working. I am out of ideas and in deep despair mode.

This is Unity 2022.3 with latest recommended addressables package

I have also tried using

AddressablesRuntimeProperties.SetPropertyValue(“Config.CDNURL”, gameConfigVO.data.cdnURL);

but it’s exactly the same

this new undesired behaviour MIGHT be linked to LOCAL assets wanting to load REMOTE assets as dependencies (which have the CDNURL variable in the url). This is a new behaviour for us and might have introduced the problem. However I wouldn’t be sure about it as I think it just not working in any case.

note that calling

Debug.Log($“Evaluate {AddressablesRuntimeProperties.EvaluateProperty(“Config.CDNURL”)}”);

results in the expected value

I pinned down the problem to runtime variable being resolved only once and never anymore if they are updated.

It become obvious when I gave to my class a default value

public class AddressablesCDN
{
    //this is actually used even if it's greyed out
    //https://docs.unity3d.com/Packages/com.unity.addressables@1.21/manual/ProfileVariables.html
    //it's used by addressables
    public static string URL = "this has been evaluated too early";
}

the url started to have the text as shown here. This because addressables tried to resolve the string before I had the chance to set it.

I am going to move away from code variables and move to profile variables, but I did that test already yesterday and didn’t solve the problem, so I suspect the value is cached too. I will try soon

from the docs:

“The value of the static property must be set before Addressables initializes. Changing the value after initialization has no effect.”

I am still surprised that the same reasoning is still valid when I do:

AddressablesRuntimeProperties.SetPropertyValue(“AddressablesCDN.URL”, $“{dataPath}/lm_assets/”);

in fact I moved away from static class as this is more elegant/efficient, but I would have expected 100% the value would change once called even after the initialization. This to me is a flaw.

Edit: from the tests looks like calling
AddressablesRuntimeProperties.ClearCachedPropertyValues(); would make this work, let’s see.

ok I finally understood what’s going on and why and I cannot believe how bad it is.

Eventually because the {} variables are resolved immediatly and I have no control when the local catalog is loaded (so I don’t have the time to initialise the property) I cannot use AddressablesRuntimeProperties.SetPropertyValue either without jumping some hoops.

I am then resorting to

static class IDTransformer
    {
        //Implement a method to transform the internal ids of locations
        static string MyCustomTransform(IResourceLocation location)
        {
            return location.InternalId.Replace("AddressablesCDN.URL", AddressableCDN.URL);
        }

        //Override the Addressables transform method with your custom method.
        //This can be set to null to revert to default behavior.
        [RuntimeInitializeOnLoadMethod]
        static void SetInternalIdTransform()
        {
            Addressables.InternalIdTransformFunc = MyCustomTransform;
        }
    }

which is absurd and I would feel ashamed if I did something like this to be honest.

Apologies that this isn’t documented well, we’ll definitely make some updates.

If you need values like this to be evaluated at runtime post Addressables initialization, the TransformInternalIdFunc is going to be your best bet.

Originally, it sounds like what you were trying to do is very similar to our CCD (Cloud Content Delivery) integration, specifically the values set in the CcdManager. For that, we do have to make sure the values are set prior to calling any Addressables methods that initialize the system. There’s a note about it at the bottom of this page, but otherwise that information could be more visible on our end.

Thanks for the reply. The whole flow is unclear, documentation can only put a patch on it. However what bothers me the most now is the inability to ask Addressables to NOT load remote dependencies if I don’t want to. In other words I would like addressables to optionally not load remote dependencies (and therefore break the loading) if I don’t want to.