Suggestion for Framework / libraries

[Inrego]

Here is my suggestion to proper implementation of libraries/frameworks. Me and a few other devs have discussed it in the skype channel. Quite a few developers agree that this would be a very welcomed addition. Currently the only way to share things properly between products like this would allow, is by either
a: Having all source code as resources, and then compile it at runtime. This means there's not obfuscation what-so-ever, and it adds to startup-time (both because raw source files are bigger than pre-compiled assemblies, and because it has to compile the files at HB startup)
b: Use reflection for EVERYTHING. I suppose the performance issues in this is obvious.

Anyway, here's my suggestion for implementation of proper support - written in a kind of step-like format:

1. A new category Honorbuddy > Frameworks. We can upload a product to this category. It will not be visible to users on the store.
2. On the product page, We can choose products from the frameworks category that are uploaded by ourselves, like in this screenshot: http://i.imgur.com/GX3IAtC.png
3. When the compiler compiles a product, it will check for referenced frameworks, grab their assemblies and add them as reference before compiling.
4. Client receives compiled products + any referenced framework assemblies.
5. Would like your input on possible solutions to make sure breaking changes in a framework doesn't break the products using them. For example marking an upload as having breaking changes, which will force pending updates to products referencing the framework to be approved at the same time. This example was just to emphasize the problem at hand, and it's probably not the best solution, but would love to hear your ideas.

It should be pretty simple to implement I think, and it has a few benefits:

• Framework code is in one place. This means a change to the framework needs to be uploaded once, not 6 times for 6 products (so shorter moderation queue, and much easier to maintain for developers).
• No "duplicate" types. An initializer that hooks to events will only be fired once, since the framework type is only introduced once and reused by the products that reference it (as is expected by referenced assemblies)
• Property values in the framework can be shared between products using the framework. So keeping a blacklist in a framework can make sense to be shared across multiple plugins/botbases.

 

[handnavi]

+1 from my side. I also need this.

 

[Studio60]

+1 from me too. It would solve a few problems I am facing right now.

 

[@alisha]

+1 Support of libraries for reference instead of merging them into one assembly will be great

 

[Inrego]

I just had an idea for ensuring no breaking changes on framework update.

When uploading a new version of a framework, it will trigger recompile of products referencing the framework. If any products fail to recompile, the new version will not enter the approval queue until these products have a new update pending aswell. These products would then be approved as a bundle so the changes are pushed at the same time.