Package Manager and assembly definitions

[metamorphling]

Are there any plans for moving onto unity's new package management system and usage of assembly definitions? Nothing urgent here, just an enhancement idea.
Tried to move "Demigiant" into "Packages", added packages.json and registered it with manifest - so far works well. Utility Panel is dead though, probably it wants dotween folder to be at hardcoded place?
I'm sure you are really busy, but just for the record dropping a few links on what I am talking about

https://docs.unity3d.com/Packages/com.unity.package-manager-ui@1.7/manual/index.html
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

Besides utility panel, as to what I had to do to make assembly definitions work with DOTween:

1. Create core asmdef file in "Modules" folder
   Seeing how project went modular way, there is a potential to breakdown every module into it's own folder and give asmdef file for every folder. That way switching modules will be as easy as having a core asmdef which adds/removes references to module assembly definitions.
2. Put scripts from "DOTweenPro" into "DOTweenPro/Scripts" and create pro asmdef file in Scripts
   For some reason if I created asmdef in DOTweenPro as is some strange errors were popping up, got the feeling asmdef was fighting dll.
3. Reference both core and pro asmdefs from source code

[Demigiant]

Ahoy!

Thanks a lot for the investigation on the matter: I will keep these info as a precious reference :) I'm waiting for Unity 2018.3 which will finally make the package manager available to everyone, and then I'll implement it for sure.

Cheers,
Daniele

[metamorphling]

It is highly recommended that you use assembly definition files for all the scripts in the Project, or not at all. Otherwise, the scripts that are not using assembly definition files always recompile every time an assembly definition file recompiles. This reduces the benefit of using assembly definition files.

Important point, to support both methods it would be cool to have a checkbox in settings menu. Like, "Use Assembly Definitions". Since .asmdef files are plain text files, they can be generated and deleted with ease,

[laicasaane]

I'm maintaining a multiple projects setup that has a copy of DOTween in each sub project just because of the utility panel problem. So I hope this feature would be done the sooner the better. No pushing from me, though, just hope so.

[Demigiant]

I plan to finally experiment with asmdef today, but not on Package Manager to be honest :B It still seems very alpha so I'm verging on the side of "let's postpone that more".

@laicasaane can you explain me more? I'm not sure I understood everything of the setup and of the problem there :B

[laicasaane]

@Demigiant My project has been divided into 3 sub projects inside it, 1st is the core, 2nd is for the players, 3rd is for the content makers. All of them use DOTween and other libraries. Others can be made into local packages just fine, but DOTween couldn't. Actually I had reported that issue here #238

I know there wouldn't be any issue in runtime, and this only affects the Unity editor. But I really don't like errors and exceptions appear even in the editor, so I've to put a copy of DOTween in each sub project to avoid this exception.

[metamorphling]

I too had some problems trying to isolate dotween into a package for multiple projects environment. Don't have a playground at hand, but if I remember correctly the cause of the problem was something like hardcoded paths for some elements of the plugin. As in, trying to access files(settings or editor images?) from the "Assets/smthsmth" while real path for package is under "Packages/PackageName/Assets/smthsmth". Setting paths to resolve for Assets and Packages respectively, depending on if dotween integrated or plugged with project, should solve the issue. Another possibility of what might go wrong is Resources.Load api, since if there are a few packages/projects with same files it does not differentiate of what to use and things may go wrong.

I feel like this is actually a common problem for plugin makers this days. Unity is halfway onto breaking engine parts into packages, while some users are jumping ship and divide environment too. At this point I can only advice this approach to those who do not use plugins, have no plans to add them midway(which is hard to anticipate) or use them selectively - only tested and confirmed stuff. Meanwhile, let's hope DOTween will be able to support new approach sooner than later ;)

[Demigiant]

Ah! Thank you both for the info. I was going to post a new version with auto-asmdef creation which I just finished, but after reading what you wrote I'm going to try and at least implement a way to find DOTweenSettings in any folder, so even if I don't do Package Manager myself it should work for you. Back in a short while, I hope :P

[Demigiant]

Ok I created an external DOTween package and tried until now to make it work, but I finally had to ragequit :B I managed to get all references correctly, but the problem is that I also need to modify files via the editor, and it's a complete mess. I experimented but the lack of documentation is too great, so I'll postpone this for the day Unity decides to make Package Manager a little more open, sigh :|

In the meantime, here's v1.2.225, where I added a button in DOTween Utility Panel to create the asmdef files. It creates one for the modules and one for DOTweenPro loose scripts (if present). I managed to create DOTweenPro's directly in the DOTweenPro folder by manually adding references to the asmdef json when it's created.

[LittleBigMonkey]

So any news on this ?

[cg-adam]

Any updates on this? Would be great to have this as a package.

[Demigiant]

Ahoy! The documentation remains too intricate (for the things I need to do with DOTween), so until Unity officially allows the implementation of external packages with at least some API I'm postponing this :|

[LittleBigMonkey]

Hi ! I'm using Git packages for most plugin I use in every project. It's sooo useful and easier to maintain. It's not too hard to use, you should look at it to make your plugin compatible. It would be awesome to not import it in every single project...