queryFactory.template contains several methods named "Field" Unfortunately, we also have a "Field" entity in our existing generated code and if we will regenerate this with v3.5 obviously it will not compile.

How would you recommend to fix this conflict? Renaming the Entity Object is not an option (and please allow me to skip the whole reasoning for it).

Easy would be to modify the queryFactory.template file to change the name of the existing methods "Field" to something else (e.g. QueryFactoryField). I have few questions about it: 1. Could anything else in the LLBLGen owned code (compiled - SD. DLLs - or generated for our entities) be impacted by this change? Obviously we don't have any of our own code referencing this class since all existing code has been written against v3.1; 2. Can we update somehow this template in the LLBLGen installer so the modified version of this template will be deployed directly to other machines? Can we rename the executable to ZIP and update the file inside? Can this have any unpredicted effects to the install process? Or can you provide us an updated installer?

Thank you!

Using LLBLGen key words (reserved) like Field and Entity is not recommended at all. And most probably you will need to change many templates for it.

So just in case you did not know that, if the reason preventing you from renaming the entity is that you don't want to change the database schema, you can easily rename the entity in the Designer.

Our "Field" table and related entity has been working well with previous LLBLGen versions 2.x up to 3.1 which we are currently using. Only the addition of the QueryFactory (in v 3.5?) class broken the generated code. And we need to upgrade to v3.5 in order to fix an operator issue for the generated queries.

I know I can rename the Entity in the designer but then I'll have to update the references through the code and not even the nice Visual Studio functionality for that will help us in some cases. Therefore we don't want to do that either.

We're probably going to modify either the template file or the code generation tasks list (to remove the QueryFactory class from our project). First choice would be easier as we wouldn't like to start versioning LLBLGen's templates across all our development machines.

This being said, do you see anything that could go wrong with our approach?

Not at all. I think you can safely remove the QuerySpec all together, if you are not using it.

The 'Field' mehtods in the QuerySpec factory are helpermethods, so if you alter that template alone, you're set. They're not used by the framework so you can alter them safely.

QuerySpec is recommended as a query system going forward, so although you can safely remove the factory as Walaa suggested, keep in mind that some features in v4 like caching are implemented on QuerySpec / Linq and not on the lower level api.

Thank you gentlemens!