Thanks, this resolves the schemaname issue, but couple of new more issues now: 1) 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity2, string)' is inaccessible due to its protection level Previously, llbl was generating [EditorBrowsable(EditorBrowsableState.Never)] public override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) but, with v 3.1 it is generating, protected override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) similar with one more function "UnsetRelatedEntity".

2) '<Pname>.DAL.EntityClasses.ServiceIndustryFieldsEntity' does not contain a definition for 'ObjectID' and no extension method 'ObjectID' accepting a first argument of type 'PricingTool.DAL.EntityClasses.ServiceIndustryFieldsEntity' could be found (are you missing a using directive or an assembly reference?) Did a little research on this one too, and it looks like that we are missing public virtual Guid ObjectID { get; set; } in EntityBase2 of the ORMSupportClasses in new llbl file.

daelmo wrote:

ULPSR wrote:

Yes, we have an entity called validator. The generated code this.Validator = validator; throws error in the llbl file.

In What Entity are you putting that code (this.Validator = validator)? I guess this.Validator is an ValidatorEntity, but validator is an IValidator, that's why the compilation error, coz there is a property in all entities called Validator, but maybe you have a related entity in this that points to a ValidatorEntity.

Is there any chance you change the related entity name Validator to something else (like TheValidator)?

I hope that makes sense. If you still run into troubles, please post you llblgenproj file so we can test it.

This problem still persists, we have a table name "validator" and is being refenrenced at many places. It throwing error in 2 out of 5 files which have validator as Foreign key. Do we have any alternate solution to changing the table name?

ULPSR wrote:

daelmo wrote:

ULPSR wrote:

Yes, we have an entity called validator. The generated code this.Validator = validator; throws error in the llbl file.

In What Entity are you putting that code (this.Validator = validator)? I guess this.Validator is an ValidatorEntity, but validator is an IValidator, that's why the compilation error, coz there is a property in all entities called Validator, but maybe you have a related entity in this that points to a ValidatorEntity.

Is there any chance you change the related entity name Validator to something else (like TheValidator)?

I hope that makes sense. If you still run into troubles, please post you llblgenproj file so we can test it.

This problem still persists, we have a table name "validator" and is being refenrenced at many places. It throwing error in 2 out of 5 files which have validator as Foreign key. Do we have any alternate solution to changing the table name?

The problem is not at the entity name, but in the navigator name of the related entities. For example: you have a ValidatorEntity, you also have AbcEntity which has reference (relation) to ValidatorEntity. So the navigator for AbcEntity is named "Validator". So you end up with a AbcEntity.Validator object in AbcEntity. That causes an ambiguity problem. For instance, in InitClassEmpty method of every entity you have this line:

this.Validator = validator;

And in that place -I guess- is where you are getting the compilation errors.

So, to fix it you must change your navigator names in LLBLGen Designer, for instance for AbcEntity, for Validator navigator you should rename it to something like TheValidator.

This is the only way I can thing of. The other hard way could be changing the templates, but I don't think that is wise as you will have to maintain them, and maybe you have to do a lot of changes.

Consider my workaround. You don't have to change the table name or the entity name, just change the navigator names. Then run some refactoring process to update your code.

daelmo wrote:

ULPSR wrote:

daelmo wrote:

ULPSR wrote:

Yes, we have an entity called validator. The generated code this.Validator = validator; throws error in the llbl file.

In What Entity are you putting that code (this.Validator = validator)? I guess this.Validator is an ValidatorEntity, but validator is an IValidator, that's why the compilation error, coz there is a property in all entities called Validator, but maybe you have a related entity in this that points to a ValidatorEntity.

Is there any chance you change the related entity name Validator to something else (like TheValidator)?

I hope that makes sense. If you still run into troubles, please post you llblgenproj file so we can test it.

This problem still persists, we have a table name "validator" and is being refenrenced at many places. It throwing error in 2 out of 5 files which have validator as Foreign key. Do we have any alternate solution to changing the table name?

The problem is not at the entity name, but in the navigator name of the related entities. For example: you have a ValidatorEntity, you also have AbcEntity which has reference (relation) to ValidatorEntity. So the navigator for AbcEntity is named "Validator". So you end up with a AbcEntity.Validator object in AbcEntity. That causes an ambiguity problem. For instance, in InitClassEmpty method of every entity you have this line:

this.Validator = validator;

And in that place -I guess- is where you are getting the compilation errors.

So, to fix it you must change your navigator names in LLBLGen Designer, for instance for AbcEntity, for Validator navigator you should rename it to something like TheValidator.

This is the only way I can thing of. The other hard way could be changing the templates, but I don't think that is wise as you will have to maintain them, and maybe you have to do a lot of changes.

Consider my workaround. You don't have to change the table name or the entity name, just change the navigator names. Then run some refactoring process to update your code.

Previously also, we were using the same entity name without any issue. Instead of code this.Validator = validator; we had base.Validator = validator; So, why sudden change to this now?

The change is due to the way Navigators are named in the designer, mainly for readbility of the code. It's unfortunate that it clashes with the name of one of your entities, but as David pointed out there is a farily simple workaround.

Matt

MTrinder wrote:

The change is due to the way Navigators are named in the designer, mainly for readbility of the code. It's unfortunate that it clashes with the name of one of your entities, but as David pointed out there is a farily simple workaround.

Matt

I changed the navigator name and it worked fine. Thanks for helping out.

Remaining issues, really appreciate your continous support (want to get done with this so that we can have the new license deployed asap):

ULPSR wrote:

Thanks, this resolves the schemaname issue, but couple of new more issues now: 1) 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity2, string)' is inaccessible due to its protection level Previously, llbl was generating [EditorBrowsable(EditorBrowsableState.Never)] public override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) but, with v 3.1 it is generating, protected override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) similar with one more function "UnsetRelatedEntity".

2) '<Pname>.DAL.EntityClasses.ServiceIndustryFieldsEntity' does not contain a definition for 'ObjectID' and no extension method 'ObjectID' accepting a first argument of type 'PricingTool.DAL.EntityClasses.ServiceIndustryFieldsEntity' could be found (are you missing a using directive or an assembly reference?) Did a little research on this one too, and it looks like that we are missing public virtual Guid ObjectID { get; set; } in EntityBase2 of the ORMSupportClasses in new llbl file.

I'm curious why you are getting this. It looks like like you are using those constructs at code, but that's very unlikely.

So. I think it would be a good idea you send us your code, so we can help you a bit with this and can move on. Just make a zip file containing you .llblgenproj file, your LLBLGen generated code, and the projects you need to compile with the new version. Don't include .dlls or bin folders. If you can make this zipped file less or equal 2MB, then open a private thread (HelpDesk forum) and attach it there. Let us know if this is possible.

It wont be possible to send over the code(due to security issues) but can send the .llblgenproj file and llbl generated code for sure if that helps.

ULPSR, you keep running into the same issues. They are all caused by: - some files are not overwritten AND / OR - the references to the runtime libraries are WRONG.

So to get the generated code compiled so you can migrate your own code: generate into an empty folder and compile that project. Then use the generated vs.net projects in that new folder in your solution instead of the old one.

If you had a lot of custom code in the generated code, then that's a problem, if you didn't, then this is the easiest.

Otis, really appreciate the cooperation from your side and understand the concern. Initially, we were running into two issues named by you but that is all cleared up and working fine. The recent issues are all changes which have been done in the newly released v 3.1 of the LLBL. The issues pointed out in above have nothing to do with reference. They are both to do with the assembly file "SD.LLBLGen.Pro.ORMSupportClasses" definitions which might have been changed in LLBL. I tried the method mentioned by you to create a new folder and generate the new files. We have custom generated code also, so it won't be the easiest. We still get the issues mentioned below. Let us know how can we assist you best in helping us. I have attached the ORM support dll file that we are referencing so that you can recheck if this is not the correct dll file.

1) 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity2, string)' is inaccessible due to its protection level Previously, llbl was generating [EditorBrowsable(EditorBrowsableState.Never)] public override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) but, with v 3.1 it is generating, protected override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) similar with one more function "UnsetRelatedEntity".

2) '<Pname>.DAL.EntityClasses.ServiceIndustryFieldsEntity' does not contain a definition for 'ObjectID' and no extension method 'ObjectID' accepting a first argument of type 'PricingTool.DAL.EntityClasses.ServiceIndustryFieldsEntity' could be found (are you missing a using directive or an assembly reference?) Did a little research on this one too, and it looks like that we are missing public virtual Guid ObjectID { get; set; } in EntityBase2 of the ORMSupportClasses in new llbl file.

ULPSR wrote:

Otis, really appreciate the cooperation from your side and understand the concern. Initially, we were running into two issues named by you but that is all cleared up and working fine. The recent issues are all changes which have been done in the newly released v 3.1 of the LLBL. The issues pointed out in above have nothing to do with reference. They are both to do with the assembly file "SD.LLBLGen.Pro.ORMSupportClasses" definitions which might have been changed in LLBL. I tried the method mentioned by you to create a new folder and generate the new files. We have custom generated code also, so it won't be the easiest. We still get the issues mentioned below. Let us know how can we assist you best in helping us. I have attached the ORM support dll file that we are referencing so that you can recheck if this is not the correct dll file.

It's the v3.1 file. However if some files in the generated code project weren't overwritten, they might use constructs not available anymore in v3, hence my request to generate in an empty folder. If you generate code using v3.0 (as the topic title suggests) it's not the right assembly. However, the issues below aren't related to that.

1) 'SD.LLBLGen.Pro.ORMSupportClasses.EntityBase2.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity2, string)' is inaccessible due to its protection level Previously, llbl was generating [EditorBrowsable(EditorBrowsableState.Never)] public override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) but, with v 3.1 it is generating, protected override void SetRelatedEntity(IEntity2 relatedEntity, string fieldName) similar with one more function "UnsetRelatedEntity".

2) '<Pname>.DAL.EntityClasses.ServiceIndustryFieldsEntity' does not contain a definition for 'ObjectID' and no extension method 'ObjectID' accepting a first argument of type 'PricingTool.DAL.EntityClasses.ServiceIndustryFieldsEntity' could be found (are you missing a using directive or an assembly reference?) Did a little research on this one too, and it looks like that we are missing public virtual Guid ObjectID { get; set; } in EntityBase2 of the ORMSupportClasses in new llbl file.

WHere do you get these errors, in your own code? Or in the generated code? Or in the code you added to the generated code? Please be specific, as it's very important to know where these errors occurred, as we think it's inside the generated code and specifically the code we generate, which is impossible (as we would notice it right away in our generator tests)

We had written code to use the llbl generated files. These errors are coming in the code written by us which were working with the previous version of llbl files. We were using some properties generated in your llbl files which are not there anymore. There has been change in the ormsupport dll which has changed the protection level for the first issue and removed objectid variable for the second issue.

You can workaround the ObjectId issue, by creating a property in the CommonEntityBase that return the ObjectId ref: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=18345&StartAtMessage=0&#102711

Similarly for the protected methods, you can use wrapper public methods in the CommonEntityBase as well.

Make sure your code is written in another file (partial class file), in order to avoid being overwritten when re-generating code.