Most likely another script question

I am looking into stripping necessary inclusions for a main project for my current work project;
We have a core platform that acts as the main project and the main funnel, while there are various other projects that just act as singular scenes - these scenes are bundled and loaded through the main project.
A problem that sometimes occurs is that they hire external contractors (or well the same one in various different occasions) and they tend to use their scripts again and give the project with all of the same scripts these then need to be included in the main project so that when bundled the references line up and the actual scene runs.
Already an issue with what I may have mentioned; same scripts, yes they provide the same named scripts, global namespace however they are different in ways so when they come in their references get mixed up and some scripts end up being a different script from one of their other scenes.

So I have been attempting to tackle the root issue; the scripts, if the scripts didn't need to be included in the main project none of this would be an issue.
This has currently involved;

• Converting the scripts into text assets and bundling those (some slightly elaborate dependency check and copying them literally as .txt) then compiling them out on the other side, this had issues which the text asset would include the actual .asset YAML as the textasset.text, in which I figured out that the bundle wasn't being correctly built on occasions so that might have gone somewhere but nowhere eventually.
• Compiling scripts down into assemblies and loading them up after loading the bundle, this didn't work: the assembly that loaded was an unnamed monoassembly, i don't even know if the script was valid as the assembly was unnamed so I couldn't actually get the functionality from it despite, down at the other side of the pipe, bundling was actually constructing the correct assembly and saving the bytes seemed to work.
• Replacing the scripts that the main project knew with dlls, that required moving the scripts into a .net project and building dlls to provide said functionality... This... works, to an extent, obviously the metadata that was constructed with individual fileID's now is no longer valid and every reference to that is broken so that requires going back through the projects that used said scripts to reconnect references and write in the values.

Apparently the final bullet point has been "resolved" by the use of assembly definitions, I am currently attempting that and I guess the question now pertains to assembly definitions but I could not find a forum for that, and since its somewhat on the related pipeline of me using asset bundles I felt it would be fine here.

So, an assembly definition can be used in order to build the same references - I wouldn't need to copy every script out into a separate .net project and build dlls I'd just need to let the assembly be created and use the dll in the library folder, however that comes back to the 3rd bullet point where all the references are lost due to fileIDs.

Is there any way to use the asmdef alone as a valid "point of entry" so that when I load the bundle through the main project (without the scripts themselves existing, just the asm) the scripts still run correctly?
The answer is most likely no due to the fact the actual scripts themselves do not have any presence through the bundles being loaded and the project in question no longer knows what the scripts are it just has some definition about them, after all this isn't C++ and forward declarations arent a thing :'(.
OR
The alternative - using dlls, is there a way at all to overcome the missing references? Since this is a little better in terms of the project flow and having less collisions when loading up that contractor provided project since straight away the references could be handled a little easier as its just dropping in a namespaced dll (when it gets to it)

 

This problem is very relatable, our situation is mostly the same. By far the easiest solution is to just require your external contractors to use a new namespace for every separate 'package' that is to be included in your main app. For maintainability reasons you can then still compile these scripts to a dll and the references should remain, so they could provide you with a scene and assets and a dll and you can just drop them in your project. Just keep in mind unity versions etc. this would be the next pain point

Your first bulletpoint is also something we looked into, but its never gonna work on AOT platforms (ios) so your mileage may vary.

 

The app wouldn't be anywhere other than windows, there was a UWP requirement at one point but it was dropped due to some issues with external applications.... or something...

Yeah, telling them to use a namespace is one option but its one they were given at the start and still don't adhere, they also don't adhere to any naming convention but thats just something for me to complain about.

I tried doing the DLL approach but it would just lose the links to the scripts due to the fileID in the asset not being the same as the one it expects, with sharing the same DLL it might have the same references but would require backtracking through scenes to process. How have you managed to keep references?