Is LLBLGenProEntityName property missing in v3?

Posts   
 
    
kacha07
User
Posts: 45
Joined: 23-May-2010
# Posted on: 20-Jul-2010 23:16:28   

I'm having a lot of compilation errors because this property seems no longer available in the generated code for v3.0. ¿Is there a way to include it again?.

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 20-Jul-2010 23:41:17   

I don't think so - should still be there as a property on the IEntityCore interface. Can you show us the code you are using...?

Thanks

Matt

kacha07
User
Posts: 45
Joined: 23-May-2010
# Posted on: 21-Jul-2010 04:00:03   

Up to v2.6 the following code used to compile:


Dim p as ProductEntity
Debug.Print p.LLBLGenProEntityName

Now the above code doesn't compile anymore, unless you explicity cast de ProductEntity, e.g.:


Dim p as ProductEntity
Debug.Print DirectCast(p, IEntityCore).LLBLGenProEntityName)

I'm not willing to cast each reference to that Property along the code (the same happen with ObjectID property). The only way I found to overcome this issue is to define those properties in the CommonEntityBase class.



     ' __LLBLGENPRO_USER_CODE_REGION_START CustomEntityCode
        Public ReadOnly Property LLBLGenProEntityName As String
            Get
                Return (DirectCast(Me, IEntityCore).LLBLGenProEntityName)
            End Get
        End Property

        Public ReadOnly Property ObjectID As Guid
            Get
                Return (DirectCast(Me, IEntityCore).ObjectID)
            End Get
        End Property

        ' __LLBLGENPRO_USER_CODE_REGION_END

Thanks for your support

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 21-Jul-2010 10:34:52   

You could also create this as an extension method to avoid having to modify the templates or the generated code - they are great for adding functionality to otherwise sealed classes.

Matt

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39833
Joined: 17-Aug-2003
# Posted on: 21-Jul-2010 11:30:00   

The addition to the commonentitybase is indeed a workaround to avoid a lot of casts. We moved the properties/methods to the interface explicitly because that cleans up the api a lot in every day usage of an entity (as these framework specific values aren't used much outside every day usage, as they're mainly for the framework.)

Frans Bouma | Lead developer LLBLGen Pro
kacha07
User
Posts: 45
Joined: 23-May-2010
# Posted on: 21-Jul-2010 20:21:49   

Yes indeed aren't every day usage methods/properties, but in my case I use a lot of them in generic routines.

Maybe you can consider add these methods/properties in the ComomEntityBase templates in order to decrease the breaking changes required to migrate the code. I actually have a lot of work converting the PredicateFactory.CompareValue/Range/Between/etc methods. I came from the .net framework 1.1 and have a really lot of them rage

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39833
Joined: 17-Aug-2003
# Posted on: 22-Jul-2010 10:21:43   

kacha07 wrote:

Yes indeed aren't every day usage methods/properties, but in my case I use a lot of them in generic routines.

Maybe you can consider add these methods/properties in the ComomEntityBase templates in order to decrease the breaking changes required to migrate the code.

That wouldn't make much sense, as they're then again visible in the list of members in intellisense in all cases: we then could also define them again as they were on the base class.

I actually have a lot of work converting the PredicateFactory.CompareValue/Range/Between/etc methods. I came from the .net framework 1.1 and have a really lot of them rage

I can understand that that's a tough job, we had to do that too in our unittest projects. But it was inevitable that this day would come considering they were marked as deprecated many years ago (if I recall correctly with 2.0)

Frans Bouma | Lead developer LLBLGen Pro