How to rereference Monoscripts In Assemblies to Assetbundles

Questions & Answers
1

Assemblies can now contain Monobehaviour! Thats great! So what I'll like to do is the stream in Assetbundles with prefabs and assemblies containing monobehaviour scripts for the respective prefabs. The reason being we want to delegate different modules of a game to different people. Its also alot neater. And the final but most important reason is we're hoping to not have to rebuild the main scene (or any other completed scenes) over and over again while introducing new logic or modules to the game.

So far this is what I've tried:

  1. I stream in a scene with the assetbundle. (Nothing happens)

  2. Then I copy and paste the dlls for the prefabs into any part of the "Assets" folder, held by a "Plugins" folder. POP! all the monoscripts suddenly get rereferenced and everything works fine!

  3. I try to build the project.

  4. In the build project i stream in the assetbundle.

  5. Then i try to dynamically load the DLL in script with AngryAnt's blog (nothing happens) (Oh the interesting part is upoon downloading the assembly, i tried to involke a method to print a statment and it works fine! =) Seems like the only remaining problem I have is the referencing of the scripts correctly which can be magically done right in editor mode but not during an executable's runtime... )

  6. In my desperation I tried to just copy and paste the dll into the "managed" folder but nothing happens also.

Anyone with any thoughts on how to proceed from here on?

3

angryant's solution is old and was good in those times that we could not have components in dlls. now you can put your monobehaviour in a dll and download it at runtime and then load it as an assembly in your code and then just use AddComponent without any additional framework/script. use Assembly.LoadFrom to load your assembly at runtime and then use addComponent. it's much easier.

2

Hi all, I've somewhat created a work around framework using hydra. Its a little complicated and quite a bit of work but if anyone's interested here's how it goes in a super nutshell:

.1. Built my owh little frame work layer on top of the monobahaviour. This is to control basic set-up stuff on each script. Then compiled everything into a .dll (I've found that not only can unity take in monobehaviour in their dlls, they can even be put in namespaces =) )

.2. Created what i call and "Orchestrator" script.

This is an important script that is in control of all incoming sub modules. It loads asemblies and set-up prefabs for its particular module. Foreach loaded module, I'll have an extended of this orchestrator and call it "WidgetOrchestrator". We only need 1 of each of these classes.

.3. Build my main module and include a "MainOrchestrator" script.

This is the boss controlling all of whats coming in. It currently pools the website for available modules and displays them for all to see. This is important and super cause by pooling whats available means we no longer need to internally change the codes of the main programming to include how to both realise the existance of now modules and use them.

.4. Create the web-server as mentioned above to pool data and download the assemblies and assetbundles.

////////////////////////////////

Those are the few critial steps in a nut shell. The DISADVANTAGES of this are can be pretty compelling: i. I feel that it breaks the idea flow of how unity supposed to be used especially the ability to attach scripts just by dragging and dropping (However, this was our problem in the first place. These scripts we dragged in just didnt work when we want them to dynamically load them).

ii. This idea is pretty complicated and its harder to check for bugs when theres some kind of error.

iii. The set up and deployment can be quite a hassle. You need to build an asstbundle, an assembly, write up meta files, build up your server (But then again even if scripts could be directly attached we still had to do all these anyway).

iv. An additional learning curve on how to proceedurally do things based on the framework you or I have designed to handle this.

The ADVANTAGES of this

i. Dynamic loading of now modules, logic and everythign which is what we've all been looking for.

ii. Never ever needing to rebuild your main project again.

iii. Able to divide work in a team to members can idependently work on their modules with a "sandbox" scene.

iv. Direct and immediate version upgrading since all data is directly pooled in from the web server.

v. No Down time to server and applications!

I know the steps above are like super vague so if any one is really interested i'm willing to share some of my codes with you all. Just comment me for them. Also, i thik it ll still be better for the all of us of the bundles could just contain the scripts and load them right so I'm still really open to better answers for this.