Enhancer redistribution

[Randall]

http://www.telerik.com/help/openaccess-orm/visual-designer-deployment-consideration-redistributing.html contains the ominous warning:

The VEnhance.exe tool is forbidden for distribution.

Is there a way to solve our requirement (follows) without negotiating to do exactly this?

Our company currently delivers a non-ORM software solution to our customers, each of whom has added custom fields and sometimes tables to the standard database schema we provide. Both customer and 3rd parties need to be able to write plug-ins to add custom business logic and access both standard fields and tables.

As we evaluate migrating to OpenAccess, artificial fields and types seem the obvious route, except that this requires use of the Metadata API to communicate to the new fields. This is a problem because the customer/3rd party:

• has to know whether they are accessing "custom" or "standard" field when developing a plug-in.
• could potentially use the Metadata API to write to our "standard" fields and so bypass our business logic

I believe that to allow custom fields and types to be "first-class citizens" with our standard fields would require generating the entity classes and running the enhancer at each customer, each time they modify their schema. 

Is there a solution that would not require purchasing a development license for each of our customers?

Thanks,
-Randy

[Dimitar Kapitanov]

Hello Randall,
We are evaluating the possibility to provide the enhancer for shipping/bundling with third party solution, but since we never did it so far we don't have a sound procedure how to organize all. What we will have to do is:

1. Modify a bit the tool itself
2. Prepare a special EULA for redistribution

Please give me your time estimates and planning, so that I know what time we have to prepare a work-flow that can fit your needs.




All the best,
Dimitar Kapitanov
the Telerik team

[Randall]

Hello Dimitar,

To give you perspective, we are still in the technical evaluation phase with OpenAccess (vs. NHibernate, mostly), in terms of migrating our current product from an in-house framework to an ORM. Since we also want to migrate from a C++/MFC codebase to C#/WPF, this will be a rather long project.

That Telerik is showing the willingness and flexibilty to satisfy our needs and request is very encouraging and sufficient for now, I think. 

I would propose that our company do more proof-of-concept, etc, finalize our tool selections (we really really like the RadControls for WPF, especially the RadTreeListView!), and continue the discussion at that time.

Possible workflow (based on our limited understanding of the enhancer):
0. Our company deploys to customer:

• source code for the partial persistent classes representing our "standard" schema, decorated with OpenAccess attributes
• un-enhanced assemblies for most of our software product

[The remainder runs on customer machine at time of schema change]
1. Customer provides source code files for their plug-ins, containing:

• "custom" fields extending the "standard" persistent classes
• "custom" persistent types 
• "custom" plug-in business logic, presentation layer, etc.

2. Build the assemblies (might be called from within our software's bootstrapper via CSharpCodeProvider.CompileAssemblyFromFile() )

• "custom" + "standard" persistent classes to make the Domain Model
• "custom" plug-in assemblies

3. Run the enhancer on all the un-enhanced assemblies
(we could invoke enhancer from our software's bootstrapper using a passphrase, if that is desired to protect intellectual property)
At this point, we should be ready to load the assemblies and run!

Thanks again,
-Randy

[Larry]

Dimitar,

I have a set of requirements similar to Randall's.  We are currently working on a software package using OpenAccess for our ORM solution.  We have requirements to allow administrators to modify our domain model at runtime.  We had decided to use the VEnhance/VSchema tools to achieve this until we saw the "ominous warning" referenced by Randall above.

Our desired way of handling this would be to augment our standard model classes by generating partial classes based on user actions (adding properties, etc.) and then compile unenhanced assemblies.  We would then need to enhance the assemblies and update our database based on the model changes. 

Please provide feedback after your evaluation on the possibilities for redistribution.


Thanks,
Larry

[Jan Blessenohl]

Hi Larry,
Do you really want your customer to change your code?
OpenAccess has a feature named Artificial Fields/Artificial Types, where you can add fields or complete new types by just describing them and using special access methods. This feature is used by SiteFinity to dynamically adding fields to existing types (and columns to tables) if the end user needs more data.
Maybe you want to have a look.

Regards,
Jan Blessenohl
the Telerik team

[Randall]

Hello Jan,

In our environment, yes, we absolutely want our customers to extend the code that generates the assembly for our data model, expressly so they do not have to use the Artificial Types/Fields API.

We want our development programmers, our in-house customizers, 3rd party add-on developers and even (where capable) customers to perform application programming with the same set of methods. In addition to the maintenance and training benefits of a common programming model, we want all these developer groups to benefit from the compile-time checking of tables/fields that an ORM normally provides. 

In summary, we very much desire and would value this capability.

Thanks,
-Randy

[Jan Blessenohl]

Hello Larry,
We are offering an OEM license now. If you have such a request please contact our sales department directly.

Greetings,
Jan Blessenohl
the Telerik team