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
This will be part of v7.
Support deploying to CRM by providing an API that would support using from a command line or from a .Net app.
Should be able to call an API to publish a crm asset or plugin/workflow assembly to the CRM organization taking into account all the XrmToolkit configuration information.11 votes
The initial version of this has been released in v5. It supports merging (ILMerge) of plugin assemblies and publishing them to CRM. A future release will include the ability to deploy other assets, ie web resources etc.
Right now when you register a plugin step the name is blank. I suggest that name to be default to something.
for example if the Plugin is 'MyPlugin' and the Message is 'Update' and the entity is 'Opportunity' then default the plugin name to 'MyPlugin - Update - Opportunity'
A configurable default would be nicer (as I'm sure there are a lot of different naming standards out there)3 votes
Thanks for the suggestion! This has been implemented in v4.3 based on a hard coded algorithm. We agree that using a template would be great and so until this portion is implemented we’ll keep the status set to ‘started’.
Grid-like editor to allow bulk editing of attributes. Also allow editing all aspects of individual attributes. Allow pushing all changes to CRM at one time after all edits have been made.30 votes
This feature will be added to v5.×.
- Don't see your idea?