I suggest you ...

Provide NamingServiceExtension for proxy classes

Currently it is not possible to adapt the name of proxy classes during generation.
Please provide an extension to provide custom names for proxy classes and properties.

Some generated names does not fit our naming conventions. For example special chars in german ("ß", "ä","ö" ...) or properties which will start in lower case or underscores in names.

It would be awesome to have the possibility to extend the INamingService implentation of XrmToolKit.

67 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Holger Hoffmann shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Filip commented  ·   ·  Flag as inappropriate

    This would also be useful to resolve naming conflicts like for some reason the xrmtoolkit generates the same name for the a lookup field twice, once to create a strong typed property (example: public Contact ParentSupervisor) and another for the entity reference to that same lookup (example: public EntityReference ParentSupervisor).

    Also, if an optionset has a silly name in it like '---------' which some genius used as a ghetto seperator, this now generates to an empty enum name for that value. Being able to control name generation would be immensely useful.

  • Holger Hoffmann commented  ·   ·  Flag as inappropriate

    It would also be necessary to have an option to skip the automatically generated BasedProxyClass.
    If you providing the BaseProxyClass by a NuGet package or other project you don't need to generate it every time you add new proxy class. The BaseProxyClass is located in another assembly and should not be added to the project which contains domain/solution specific proxy classes.

  • Holger Hoffmann commented  ·   ·  Flag as inappropriate

    Another issue occurs if you are using multiple Assemblies/Projects to split your code in logical parts.
    If your using a base library which contains the BaseProxyClass it will not possible to use this proxy class in another project.
    If you generate a proxy class in this scenario then required namespaces are missing and must be included manuely in each generated proxy class. This happens because the namespace of the base library and the project containing generated proxy classes are different.

    Please provide a configuration to define adtional namespaces to include in generated proxy classes.

    The issue with INamingService could als be solved be providing a configuration based mapping to define different names for classes and properties.

    At the moment the generation of proxy classes is not usable for projects. It may works for a single small project, but for companies with multiple projects and base libraries it's not comfortable.

    Any feedback would be nice.

Feedback and Knowledge Base