v.3.5 August 8th, 2012

What is the particular order for the entities in <RootNameSpace>.EntityType enum?

It seems to be .SortBy(e => e.GroupName).ThenBy(e => e.Name), but it doesn't match always, and I need it to set the value in a static URL (eg. generated web.sitemap : I cannot reference the enum in a siteMapNode's URL)

If it is not ordered, could it be changed in the next version, please?

TIA

Jose

As far as I know and as far as I can see it's ordered alphabitcally. Can you give examples how it this is not the case (sometimes)?

OK. It seems to be a bug related to a GroupName been null or empty. If the GroupName is always set, the sorting is GroupName).ThenBy(Name)

Example: See Group division of entities' list in attached image. And look for the order of ServiceEntity in the generated enum:

    public enum EntityType
    {
        ///<summary>Address</summary>
        AddressEntity,
        ///<summary>Channel</summary>
        ChannelEntity,
        ///<summary>Communication</summary>
        CommunicationEntity,
        ///<summary>MnCommunicationResponse</summary>
        MnCommunicationResponseEntity,
        ///<summary>MnCommunicationSuscriberResponse</summary>
        MnCommunicationSuscriberResponseEntity,
        ///<summary>MnSubscriberCommunication</summary>
        MnSubscriberCommunicationEntity,
        ///<summary>MnSubscriberService</summary>
        MnSubscriberServiceEntity,
        ///<summary>Response</summary>
        ResponseEntity,
        ///<summary>AdministradorProfile</summary>
        AdministradorProfileEntity,
        ///<summary>AnonimoProfile</summary>
        AnonimoProfileEntity,
        ///<summary>BaseProfile</summary>
        BaseProfileEntity,
        ///<summary>CallCenterProfile</summary>
        CallCenterProfileEntity,
        ///<summary>ConfiguracionEnvioMail</summary>
        ConfiguracionEnvioMailEntity,
        ///<summary>DeudaProfile</summary>
        DeudaProfileEntity,
        ///<summary>Log</summary>
        LogEntity,
        ///<summary>PersonalData</summary>
        PersonalDataEntity,
        ///<summary>Rol</summary>
        RolEntity,
        ///<summary>SavedLink</summary>
        SavedLinkEntity,
        ///<summary>UsuarioProfile</summary>
        UsuarioProfileEntity,
        ///<summary>Service</summary>
        ServiceEntity,
        ///<summary>Subscriber</summary>
        SubscriberEntity,
        ///<summary>Webcallback</summary>
        WebcallbackEntity,
        ///<summary>WebcallbackStatusType</summary>
        WebcallbackStatusTypeEntity
    }

They're sorted on full name, which is <groupname>.<entityname> if groupname is set, or <entityname> if groupname is empty (so no prefix dot)

I think I see what's the problem: the '.' isn't a divider of course, the groupname.entityname is simply showing up inside the list of names of the group without a name. It should have done sort on group -> then on name.

The error is on line 5120 of the TDL interpreter (it's a big class ) There it should have done the sorting first on groupname then on name. We can't change this in the middle of the version as the enum values change which might break applications.

We'll fix this in v4. If you need this, you can change this in the tdl interpreter yourself, it's stable (I don't expect bugfixes in that class till v4 is released)

OK. Then it is not a bug. It seems to me perfectly fine as it is. Where I thought it was...

    var entities = _executingGenerator.Entities
            .OrderBy(e => e.GroupName)
            .ThenBy(e => e.Name);

... it is:

    var entities = _executingGenerator.Entities
            .OrderBy(e => string.IsNullOrEmpty(e.GroupName) ? e.Name : e.GroupName + '.' + e.Name);

If you decide to change it in the next release, it's ok too. I'd only ask for a notice in the "breaking changes from previous release". Regards.

For a new version, it's not a breaking change, as the code has to be recompiled (all of it). The problem is with current code, when I change it now in v3.5 and people regenerate the generated code/recompile that and drop that dll into the folder of their binary executable: then it will break the executable. So I can't fix it in v3.5, but will fix it in v4. If you need it, you can alter the interpreter in v3.5 for the time being. It's indeed doing groupname + . + element name, and it will in v4 sort on groupname, then on element name.

Perfect (as always) then