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.
This will be part of v7.
Looking for some feedback on how this might be accomplished. Initial plans are to provide an interface for the naming service that would look something like this:
public interface IProxyClassNamingService
void BeforeProcessEntities(IEnumerable<EntityMetadata> entities); // To be run at the beginning of the process
void BeforeProcessEntity(EntityMetadata entity); // To be run before processing a single entity
string GetNameForAttribute(EntityMetadata entity, AttributeMetadata attribute);
string GetNameForEntity(EntityMetadata entity);
string GetNameForOption(OptionSetMetadata optionSet, OptionMetadata option);
string GetNameForOptionSet(OptionSetMetadata optionSet);
string GetNameForRelationship(EntityMetadata entity, RelationshipMetadataBase relationship);
string GetNameSpaceForEntity(EntityMetadata entity);
string GetNameSpaceForOptionSet(OptionSetMetadata optionSet);
Would this cover everyone's needs?
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
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
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.