Search Unity

Question Some custom namespaces and classes can't be accessed by other scripts somehow...

Discussion in 'Scripting' started by Igor_Vasiak, Jul 4, 2020.

  1. Igor_Vasiak

    Igor_Vasiak

    Joined:
    Dec 13, 2016
    Posts:
    44
    Hey, I'm Igor. I'm finding this issue where a tool of mine (which I've developed a while ago) can't be detected by other scripts at all, both scripts and namespaces. I'm sure it's not a folder naming problem since they're all inside folders named "Scripts", only in different places. This is the folder structure I have:

    • Assets
    • ---My Tools
    • ---|---My Library
    • ---|---|---Editor
    • ---|---|---Scripts - Some of the inaccessible scripts are here
    • ---|---Object Pooler
    • ---|---|---Editor
    • ---|---|---Scripts - The rest of the inaccessible scripts are to be found here
    • ---Scripts - The scripts that can't access the tools lie here
    It's really weird, and that's only happened to me before when I accidentally named the root folder (My Tools) to any of the sensible names.

    All scripts are included in the propper .csproj file, a .asmdef just for them. Both "My Library" and "Object Pooler" have separate .asmdefs for their Editor and Scripts folders, totalizing four definition files. The issue persists even when not using any custom .asmdefs.

    The scripts between both tools do communicate with each other, even when using no .asmdefs.

    Note: If I drag any of the scripts found at those folders to the main Scripts folder, it seems to work fine. But this isn't optimal for my current situation. Also, dragging the script that has errors to any of the other Scripts folders does not fix it.

    Now, why? And how do I solve this, if at all? Thanks for your consideration.

    Update #1: I feel I should clarify some things:

    1. The version of Unity I'm using is 2019.3.3f1.
    2. I can't create a simplified project and upload it.
    3. The project is sitting in a secondary HDD.
    4. I did try to delete the Library folder with no success.
    5. Creating a script in a separate Scripts folder in the original project in which the tools are being created does work. I can't use that project because it's just that: a project to create tools and later upload to the Asset Store.

    Update #2:

    I found a kind of solution, but I'm not sure how often it would work, if at all in reality. Either way, here you have what I did.

    I created another project, this time in my main SSD, and with the same name. Enter Unity and, because of the version of Unity I'm using, I'm greeted with the usual Visual Studio Code 1.1.4 package out of range exception. I updated it to 1.2.1, which always works fine. Then, I rebooted Unity, and the error message was gone.

    Next, I imported the tools, the exact same way I did before, by dragging them over. The scripts successfully compiled, but I wasn't expecting anything else. Then, I created a Scripts folder directly under the usual Assets folder and created a script under it. Enter the script, and enter VS Code, there was a problem. Once VS Code finished loading, I tried to write a Using statement, only to find myself greeted by... no MyTools namespace found. Then, just as a control, I tried it with the regular UnityEngine namespace and... nothing. Hmm... very weird.

    "Great. Now VS Code is broken." Thought I. But then, something else came to my mind, something I had already tried before. "It was in a different hard drive, though." I then proceeded to delete the .csproj files and the solution, and reboot both Unity and the IDE. And, what do you know, it suddenly started working!

    My thought process to this was: if Unity had thrown an error because he couldn't properly create a solution, then, well, it had to recreate it. What a better way to trigger it than brute force, ay?

    Just to be clear, yes, I did try it on the other project. Now, I'm not sure why wouldn't it work, but I know it didn't. One way or another, it works just fine now. That is... for now. Who knows what else might be lurking, waiting just for the right moment to cause another bug.
     
    Last edited: Jul 5, 2020
  2. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,909
    Is your plain old scripts folder using an asmdef too? I thought if you use asmdefs anywhere your whole project needs to use them in order to even depend on the assemblies.
     
  3. Igor_Vasiak

    Igor_Vasiak

    Joined:
    Dec 13, 2016
    Posts:
    44
    No, it doesn't use any. But the issue persists even with no .asmdefs anywhere at all.
     
  4. Laicasaane

    Laicasaane

    Joined:
    Apr 15, 2015
    Posts:
    361
    It might be silly but have you tried: close Unity, delete Library folder in the project, open the project again?
     
  5. Igor_Vasiak

    Igor_Vasiak

    Joined:
    Dec 13, 2016
    Posts:
    44
    As a matter of fact, yes, I have. Unfortunately, it didn't work. :(
     
  6. Laicasaane

    Laicasaane

    Joined:
    Apr 15, 2015
    Posts:
    361
    If your project is private, you should create a simplified and reproducable version so we can help you properly. Without an actual project, it's hard to say anything because according to your OP description, there shouldn't be any problem at all, at least when you fully use asmdef.
     
  7. Igor_Vasiak

    Igor_Vasiak

    Joined:
    Dec 13, 2016
    Posts:
    44
    That's unfortunately impossible.
    Again, it doesn't matter if I use full .asmdef, none at all, or an in-between solution. It will always - ALWAYS - give me errors saying the namespace can't be found, and therefore its scripts can't be found.