Search Unity

no definition for ResourceManagment

Discussion in 'Addressables' started by Sylon87, Apr 24, 2019.

  1. Sylon87

    Sylon87

    Joined:
    Aug 20, 2018
    Posts:
    125
    hello

    i'm trying to get my code work but i'm having an error because it can't find IAsyncOperation that should be contained into
    using UnityEngine.ResourceManagement;

    but when i'm trying to access it just say that there is no definition of that..... what i missing ?
     
  2. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    913
    As noted in the changelog, IAsyncOperation had been replaced with AsyncOperationHandle. This is not always an exact one for one, so depending on your usage, you may have to tweak your code slightly.
     
  3. Sylon87

    Sylon87

    Joined:
    Aug 20, 2018
    Posts:
    125
    thank's i just miss it.. now works, again thank's you!
     
    unity_bill likes this.
  4. _watcher_

    _watcher_

    Joined:
    Nov 7, 2014
    Posts:
    132
    I have just integrated Addressables into a test project, where it works (temporary 2019.1.1f1 project, LWRP)
    When porting the temp solution into my existing project (will call this one "Main project", originally 5.x 2D project that was over time upgraded to 19.1.1f1), i got:
    Code (CSharp):
    1. The type or namespace name 'AsyncOperationHandle<>' could not be found (are you missing a using directive or an assembly reference?)
    2.  
    But everything ported fine, i have literally imported the same class (and imported the Addressables package etc), so stuff like
    Code (CSharp):
    1. using UnityEngine.AddressableAssets;
    2. using UnityEngine.ResourceManagement;
    is included. Everything else works fine. Any ideas?

    EDIT: for some reason, the up-to-date versions of packages in the temp project and the main project are different. Packages in both report "up to date" and can not be further updated.

    Temp project (fresh 19.1.1f1 LWRP):
    > Addressables: 0.8.4
    Dependency: > Scriptable Build Pipeline 1.4.1-preview (installed)

    Main project (old 2D made new 19.1.1f1):
    > Addressables: 1.0.2
    Dependency: Scriptable Build Pipeline 1.3.1-preview (1.4.1-preview installed)

    When you look closely, it seems counter-intuitive for newer version (just the version number) of Addressables to be dependant on older SRP (?), but that's what it says.

    Also after further testing, while AsyncOperationHandle is recognized in Temp project, it is not recognized in the Main project, however UnityEngine.ResourceManagement.AsyncOperations.IAsyncOperation is recognized in the Main project, which leads me to believe that 1.0.2 is simply older version of Addressables , and 0.8.4 is newer, as @unity_bill mentioned, IAsyncOperation was replaced in favor of AsyncOperationHandle.

    EDIT2:
    [1.0.2-preview.2] - 2019-02-15
    [0.8.4] - 2019-05-09
    But when i look at the change logs, i seem to be dealing with completely different (addressables) branches i.e. it makes sense why i cant update now. The only reason why this is so that i can think of is that the Main ("Old-incrementally updated") project is not compatible with the "new" 0.8.4 addressables, only with the 1.0.2-preview.2 ones. Idk why though.

    EDIT3:
    I'm starting to believe that my issue is unrelated to this thread, but maybe someone with similar setup finds it helpful later. Ive done some more tests.
    Created new 2D project (19.1.1f1).
    Created new 3D project (19.1.1f1).
    Created new LWRP project (19.1.1f1).
    Comparing packages inside Package manager, i've noticed that some packages are different from the Main project.
    "Unity Ads" (2.0.9, Main) vs just "Ads" (2.0.8, 2D / 3D / LWRP)
    "Addressables System" (preview.2-1.0.2, Main) vs "Addressables" (preview-0.8.4, 2D / 3D / LWRP)
    "Burst" (1.0.3, Main) vs "Burst" (1.0.2, 2D / 3D / LWRP)
    (and others)

    Also tried to install "Burst" 1.0.3 into Main. Installed fine. Clicked "Changelog". There is no mention of 1.0.3 in changelog (?) ¯\_(ツ)_/¯

    This is baffling, am i missing something obvious? Are there separate package forks for older code-bases of the editor or something?

    I want to stay up-to-date with LWRP/HDRP and will probably port the whole "Main project" into a fresh 19.x LWRP (or HDRP) base soon, that should solve it? Is this advisable and why (or will the v1.0.2 Addressables get an update at some point so i can use AsyncOperationHandle or should i just use IAsyncOperation in my "project version" and why should i care)? Should i be clear on whether i want to have HDRP or LWRP base before i proceed with porting Main into a fresh 19.x RP, or is it possible to upgrade/downgrade (HPRP->LWRP, LWRP->HDRP)later (i've read somewhere that it is not)? Any more info on this situation (to better understand and learn from it) would be welcome.
     
    Last edited: May 11, 2019
  5. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    913
    is only on the staging server and is actually quite out of date and not very usable.

    Don't look at the staging server.
     
  6. _watcher_

    _watcher_

    Joined:
    Nov 7, 2014
    Posts:
    132
    @unity_bill Thanks, but have you looked at my whole post?

    This is what Unity downloads automatically when i click "Install" in Packages manager. But only in one of my projects. In another (fresh new) project, i get 0.8.4 to download automatically when i click the same "Install" button. Same Unity installation. Different projects.

    I've summed it up so you dont have to read that long post, but id advise you read it in full instead. Alternatively please advise, how i can force my project to "not look at the staging server" as i didn't set up anything in that regard and rely on the automatic update by clicking "Update" button in Package's Package Manager window.
     
    Last edited: May 13, 2019
  7. unity_bill

    unity_bill

    Unity Technologies

    Joined:
    Apr 11, 2017
    Posts:
    913
    Not exactly sure what's going on here. Either....

    you intentionally are pointing to staging in order to get some bleeding edge LWRP/HDRP. that seems bad, but if that's the case, just keep an eye on our release notes thread, and manually pick the version of addressables we announce as latest. You can pick any version from within the package manager. Of note, staging is supposed to go down in the coming months, so this seems particularly bad.

    or

    you have no idea what I'm talking about when I say "staging". Look in Packages/manifest.json and delete the line that says "registry". By default that file does not specify a "registry" as it'll default to the proper production server. At some point, someone edited that file in your project. I assumed that someone was you, so when I said "don't point to staging" I figured you'd know what I meant.

    Staging is a test server, that shouldn't actually be used by customers, but was unfortunately made public once upon a time. and in the past, some packages have asked people to look there. but I'm mostly sure that practice is dead.
     
    _watcher_ likes this.
  8. _watcher_

    _watcher_

    Joined:
    Nov 7, 2014
    Posts:
    132
    That alone did it, You cant imagine how much you helped, thank you.

    I am unaware of modifying the file, although i did use alpha/beta versions of Unity in the past for this project, unsure if that could've something to do with the injection, but anyway - absolutely fantastic, thanks again! :)
     
    unity_bill likes this.
  9. johnseghersmsft

    johnseghersmsft

    Joined:
    May 18, 2015
    Posts:
    28
    The staging 1.0.x previews were needed for a while with 2019.1 beta. Some of the UIElements code was finalized and moved from Experimental.* namespaces. The Addressables UI was referencing the Experimental namespaces and the only way to load Addressables properly was to use the version from staging.

    But yes, it is very non-intuitive that the 1.0.x previews are much older than the 0.8.x versions. Probably has to do with that course correction where they needed to delay 1.0.