Please make the Namespace of the current "XRMBase" changable or put it fixed to Xrm.
It's pretty annoying when working with Xrm.Utility... etc. so you gotta fake it every time with declare const Xrm: XrmBase<any> or something similar

Afaik the intellisense files are created by xrmdefinitelytyped(?) and they have a setting for that but where to store the config?

I like the Custom Naming Template for Plugin Steps feature. However all of our plugin steps that run on for instance Update of a Contact Post-Operation are all named "Update - Contact - Post-Op" with no data slug listed in the settings to allow differentiation between them.

This recommendation is to simply add a {className} (similarly named) that would be the class name of the plugin that the step is for. This would allow use to differentiate steps registered for different plugins on the same entity easier.

Would be great to see at a glance the plugin message executing user as a column. This would quickly identify which messages are registered as impersonations.

Visual Studio 2022 is coming soon and currently available as Preview 2.1. Is XRMToolkit going to be supported?

Login. See the invoices, license count and license id of licenses my company has purchased so i can easily transfer license if staff leave our organisation.

Instead provide your "tools" as XrmToolbox plugin for paying customers, if the tools you sell offer a reasonable extra value compared to those already available in XrmToolbox.

Rather focussing on things XrmToolkit differentiates from any other tool.

Nodejs projects natively use npm as the package manager, which works better with TypeScript (in my experience at least). Unit testing would be made easier as well. Those that would rather use nuget should be able to use .NET Core projects, which also includes native TypeScript unit test support as described in the documentation:

https://docs.microsoft.com/en-us/visualstudio/javascript/unit-testing-javascript-with-visual-studio?view=vs-2019&tabs=mocha

it would be great if OrganizationServiceContext could be used like early bound class's with "Crm Service Util" or Entity Frameworks

how i imagine using

create OrganizationServiceContext then use the context to query (like ef or the context created when generating early bound class's with "Crm Service Util")

update multiple entities using the awesome smart change tracking

run a single context.SaveChanges() (like ef or "Crm Service Util" but with the smart change tracking keeping track of what needs changing saving)

Sometimes you don't know how the form will look like when you code, and then you might want to code defensively, could it be possible to have an execution context that allows us to do this, ie.

function OnFormLoad(executionContext: XrmBase.ExecutionContext) {
var firstNameAttribute = executionContext.getFormContext().getAttribute("firstname");
if(firstNameAttribute != null) firstNameAttribute.getValue();
}

Support PCF development which currently requires a lot of additional scripting to build/publish into CDS/XRM. This looks set to replace replace custom web resources so would be an appropriate progression for the product.

May be worth considering a change of name to CDS or PowerApps Toolkit?

Is a site license possible to purchase?

Sometimes when using ILMerge, the strong name is not valid when the dll is created. It would be a nice feature to validate the strong name first before uploading. And if the strong name is not valid, automatically resign the dll to fix the issue.

1.) Run sn -vf *.dll
2.) Confirm that the dll is either a delay or test signed
3.) Run sn -R *.dll *.snk
4.) Confirm that the dll is now valid

We would like to have crm data model to be kept in TFS including entities and fields. We want to track/version any changes on the data model, associate these changes with proper workitem in source control.

In our environment warnings are generated during deployment if any public or protected class, method, or property has no summary and param comments. We use Swagger which utilizes these comments.

For Example:

/// <summary>
/// Gets the error string.
/// </summary>
/// <returns>The error string.</returns>
/// <param name="attributeName">Attribute name.</param>
/// <param name="defaultErrorType">Default error type.</param>
protected override string GetErrorString(string attributeName, BaseProxyClass.eErrorType defaultErrorType)
{
if (_errorStrings.ContainsKey(attributeName))
{
return _errorStrings[attributeName];
}
return defaultErrorType == BaseProxyClass.eErrorType.Text ? TextError : NumberError;
}

A light versjon that only support Javascipt/TS with Vistual Studio Code - generating intel. fiels for Js/TS and with publish to CRM funksjon.

• more if you like :)

When you want to create an interface for a class you can use the helper "extract interface" on the class definition. This does not copy the leading comments used with tools such as Swagger; i.e. the comment block created with the three forward slashes ///

For example:
/// <summary>
/// Configuration manager
/// </summary>
protected readonly IConfigurationKeyManager _configurationKeyManager;

I would like the possibility to register a plugin as data provider. Data providers are used in virtual entities.

Generate POCO or DTO early binding classes which do not have any references to the SDK. Any 1:n relationships are created as Property LIST<MyEntity>. Any Optionsets are generated as enums in separate file so there are no duplicates (i.e. status and statusReason ). The ability for these POCO classes to then generate an XSD without error. At run time AutoMapper could map from POCO to ProxyClasses

It would be nice if XrmToolkit supported the concept of versioning workflow assemblies in Dynamics. If you increment the major or minor build number of a workflow assembly, you can register a new copy of that workflow assembly with that new version and then switch over the workflows to the new version at your leisure. Here's an article on how it works: https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/workflow/update-custom-workflow-activity-using-assembly-versioning