Introducing Embedded References for plugins

[Mike.Sheen]

One of the things we have introduced into build 07.00.147.00 of Jiwa is Embedded References.

This is a new tab on the plugin maintenance form, and allows you to reference assemblies (dll's) not in the GAC, and not in the Jiwa program files folder. This allows you to embed third party (or your own) assemblies in the plugin, and allows you to use those assemblies in your code.

We store the binary image of the embedded assemblies in the database with the plugin, and write those to the file system on login, and add the reference to the plugin assembly automatically.

Embedded References

We found during development of a plugin which talks to a REST API leveraging Service Stack that we needed to have a few 3rd party assemblies referenced by the plugin. This plugin integrates to a 3PL (third party logistics) and I needed to send orders, receive GRN's, et cetera using the ServiceStack libraries. So, we added the ability to reference those ServiceStack assemblies and do all the deployment so the plugin is able to be exported, imported and run without the need to install a 3rd party component.

So - the end result is our plugin uses 3rd party assemblies, and we don't need to worry about deploying those on the client machine - the plugin framework takes care of all that.

Showing code using 3rd party embedded reference

I hope this is of some value to those developing plugins

[perry]

NICE!

[SBarnes]

Will this support a form in a DLL that could be "exposed" similar to what could be done in versions 6?

[Mike.Sheen]

Will this support a form in a DLL that could be "exposed" similar to what could be done in versions 6?

Certainly. The assembly embedded can be any .NET assembly. You can embed an assembly which is a form, and in the same plugin instantiate and display that form.

We added embedded assemblies to facilitate the use of 3rd party components or frameworks - we would prefer if plugin developers did not use this as a method for embedding their own assemblies as an IP protection strategy - if the customer owns the code, then we don't have a problem with that - but if a 3rd party developer makes a plugin and it uses a custom built assembly for a customer then we don't like to see that as an embedded reference.

We've had situations previously in version 6 where contracted 3rd parties wrote DLL's which breakout script invoked, and then the developer went AWOL and the customer was left with an unmaintainable customisation which then had to be redeveloped from scratch. Sure, it could be argued it was the responsibility of the customer to put an agreement in place (code in escrow or similar) to protect against such scenarios, but most customers do not consider such things.

Our policy is we don't want customers with plugins using embedded assembly references which we cannot step in and maintain should the author abandon the customer. Using commercial or open source embedded references is welcomed, however.

If you're going to write an assembly and embed it for your own use - and not sell or implement it at another customers site - then that's also welcomed.

Our aim with this policy is to protect the customer. If you want to use a custom built assembly as an embedded reference for a customer, then you should put an escrow agreement in place with the customer for that source code.

[SBarnes]

Hi Mike,

I wasn't actually thinking of this as an IP protection strategy but rather if you needed a screen to be able to operate from within Jiwa and outside of Jiwa to avoid code duplication or the other option I was thinking of was to be able to create a screen to capture and hide details of datbases logins such as for the wages interface you and I had discussed in another post.

I agree fully with your comments having been recently in the position of having had to use Redagte's Refelector to recover code for functionality that was written by a programmer who is now "long gone".

This does however raise one other point which is the is to do with the use of 3rd party licensed controls / components where years later getting a copy of the exact version if any from the company that produced it could become impossible. I have always here thought it technically best for the company comissioning the work to purchase a copy of the libraries themselves if they are commercial but obviously this can increase costs what is Jiwa's stance here?

[Mike.Sheen]

This does however raise one other point which is the is to do with the use of 3rd party licensed controls / components where years later getting a copy of the exact version if any from the company that produced it could become impossible. I have always here thought it technically best for the company comissioning the work to purchase a copy of the libraries themselves if they are commercial but obviously this can increase costs what is Jiwa's stance here?

Interesting question!

I think the safest route would be for the customer to purchase the 3rd party components themselves. But even then there is no guarantee that after revisions and updates the customers copy of the 3rd party component is the same as what their customisation uses - and after a while that specific version of the component might no longer be available.

3rd party components I don't see as being that big of a deal in the customisation maintenance landscape - if you can't get that specific version, you can get a new version which usually is fairly compatible, or a competing product. For instance - in Jiwa we use Farpoint Spread 8 for the grids, but on any given form we could change that to use the Infragistics grid in a matter of minutes of coding time... So If Farpoint Spread was discontinued, and we lost our installation package then we would be able to migrate to another grid component quite easily.