Is There A Way To Make Custom Package Compile Before Assets Folder?

Hello,

We're breaking up out code to packages to make it more re-usable in the "common layer". Problem is:
I used to put folders under asmdef files but not everything in the production project had asmdefs and when I managed to make it compilable it wasn't buildable in the post-build phase due to all sorts of stuff with Google Play stuff.
So I took everything out, it compiles and run again but when re-introducing the package to the project again it doesn't compile since Unity compiles the scripts under Assets first and the package afterwards but it never actually get to compile the package since it fails while compiling the scripts under Assets because they need the scripts in the package and they are now stay uncompiled.

So my question is - how can I make the scripts in my custom package (with no asmdef file) to compile before the scripts under Assets?

Using Unity 2018.3.12f1.

 

packages need an asmdef. it will not even try to compile otherwise.

also "free code" (Assembly-CSharp etc...) is always compiled last because it has implicit references to every asmdef in the project (unless you uncheck auto-reference)

 

OK, so let's try to solve it from a different angle. I put the asmdef file in my package (but not in the root because I only need the runtime scripts and not editor scripts) but it needs to refer to the Plugins folder. This is the reason why the asmdef in my package isn't truly a "standalone" because it depends on stuff (or rather the plugins are not in the scope of the asmdef if I don't give them a asmdef of their own). How can I overcome the scope problem?
If I remove the asmdef file I get many errors of the type

Code (CSharp):

1.  error CS0246: The type or namespace name 'SimpleJSON' could not be found (are you missing a using directive or an assembly reference?)

because this script sits in the Plugins folder.

 

you need to move all dependencies to asmdefs/packages first.

in your case, put

SimpleJSON

in a package with it's own asmdef, then add the reference to your asmdef (and declare the dependency in package.json too).

Unity has a compilation order that cannot break, because of auto-references:

precompiled DLL

=>

asmdefs

=>

Plugins

=>

Plugins/Editor

=>

assets

=>

Editor

and you cannot depend on something past your stage

 

I see. Well, it seems that I need to restructure then...
And just to make sure - is there no way at all that at least temporary for now, everything could sit in Assembly-CSharp including my custom package?

 

And another question, are there any ramifications for putting asmdef file inside my Plugins folder (as I try to cram as many 3rd party libraries inside)? Does it make any complications in the compilation order? And if it does, what's the sanest solution? Make another folder with any name besides Plugins and put there all the plugins that are not compiled dlls?

 

asmdefs will override the magic folder names (

Plugins

and

Editor

) for all the subfolders.
if you have an Editor subfolder and you put an asmdef, you will need a corresponding asmdef for the editor code. multiple Editor subfolder either need to be merged or be separate assemblies (2019.2 will have asmref (assembly reference) files that should make multiple folder into one assembly, but no docs available yet)

you should try to isolate pieces of code with no dependencies, and start converting those. the recommended folder structure (also used by Unity) should be like this:

Spoiler

• Assets/ or Packages/
  • <YourModuleName>
    • package.json (if it's a package)
    • Runtime/
      • YourModuleName.asmdef
      • <runtime scripts>
    • Editor/
      • YourModuleName.Editor.asmdef
        
      • <editor scripts>
    • Tests/
      • Runtime
        • YourModuleName.Tests.asmdef
          
        • <playmode tests>
      • Editor
        • YourModuleName.EditorTests.asmdef
          
        • <edit mode tests>
    • <other folders with assets (prefabs, models, etc...)>

ps: precompiled dlls and native plugins can be put in any folder, not just

Plugins/

. you should organize those too, for sanity

 

OK thank you very much @M_R .


In any case, if someone knows how to resolve this problem it could help me a lot.
I'm using Unity IAP, I've imported all the unitypackages files that come with it (IAP, Channel and UDP) and I can't compile the project. I get these errors:

Assets\Plugins\UDP\Editor\Analytics\EditorAnalytcisApi.cs(4,23): error CS0234: The type or namespace name 'Common' does not exist in the namespace 'UnityEngine.UDP' (are you missing an assembly reference?)



Assets\Plugins\UDP\Editor\AppStoreSettingsEditor.cs(15,26): error CS0246: The type or namespace name 'AppStoreSettings' could not be found (are you missing a using directive or an assembly reference?)

I have no idea why this "using UnityEngine.UDP.Common;" is nowhere to be found while "UnityEngine.UDP" namespace is totally there in the EditorAnalytcisApi.cs script.
And AppStoreSettings apparently found at Assets/Plugins/UnityChannel/XiaomiSupport/AppStoreSettings.cs .

I've put asmdefs at all the relevant places yet they do know refer to each other correctly. What am I missing?

 

I think you should use the version from the package manager, not the asset store. that is already a package so you shouldn't need to do anything else...

did you add the correct references to the asmdefs? you need to explicitly add all of them, as there is no magic here (Assembly-CSharp automatically references to Assembly-FirstPass (i.e. Plugins/) and the Editor ones automatically reference the runtime)

there is a 'references' field in the asmdef inspector. you can add other asmdefs to it. circular references are not allowed.

 

Yeah, it's was from the Package Manager.
Anyhow, I gave up. We will keep all of our code under Assets (but now a lot more organized) for the time being and when the package dependency tool will be released in 2019.2 I'll try again and hopefully other 3rd party plugins will also come in packages because Google Play Games, IronSource and another plugin really messes things up and my time to resolve these is up.

At least I've learnt from the experience