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.

I use 3rd party libraries with intellisense files and need to be able to permanently mark these as not linked to CRM.

In other instances I need to be able to correct the link eg. created a new instance instead of linking to an existing instance in CRM or vice versa.

Create Javascript/Typescript classes containing entity metadata and lookup values that can be added to a Form and referenced for intellisense.

Add support for solution packager to extract files into the project after a publish to CRM - make it optional during a publish. Currently this would need to be done via creating build scripts and updating the targets. It would be nice if this was built in to CRM Solution Manager and could be controlled by the UI.

Provide the ability to add javascript calls to crm forms directly from visual studio.

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;

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

Connecting to online instances of D365 can be a little slow so waiting for this step to complete before compiling and then uploading assembly/code is time consuming. I suggesting starting the connection attempt and building the project (plugin) at the same time, once they are both complete, upload. This will save 10-15 seconds per publish which happens a ton of times over the course of a work day.

It would be great if I could Execute a CalculateRollupRequest if the field is a rollup field. Currently I have to extend the proxy class and so I could call the function. It could work similar to how lookup fields can RetrieveProxy<T> i.e. contactRecord.new_rollupfield.Rollup(OrganizationService) would execute the function.

Add Entity Metadata Repository
Instead of hardcoded metadata information inside proxy classes, it would be awesome to provide this information inside a repository.

Something like:

var entityRepositoryItem = MetadataRepository.GetEntity(param entity);
var attributeItem = entityRepositoryItem.GetAttribute(string name);

Console.WriteLine(attributeItem.Max Length);
Console.WriteLine(attributeItem.Logicalname);
...

The current intellisense feature for picklist attribute will generate something like this.
Xrm.Page.getAttribute("new_dropdownfield").setValue(912210002);

The value 912210002 makes it less readable for future maintenance. A suggestion is to rather do the following.
Xrm.Page.getAttribute("newdropdownfield").setValue(PicklistAOption1);

Define PicklistA_Option1 in the same file automatically or in an enumerations.js file that can be include.
As part of the Web Resource Minification remove this reference.

Straight forward instead of manually having to deactivate all of these workflows. Maybe there's a way to remotely deactivate them publish and reactivate them.

Add the ability to easily create/test plugins and other code. Something similar to https://github.com/daryllabar/XrmUnitTest or https://dynamicsvalue.com/home

It would be nice if the the ExtensionMethods or some other feature in the BaseProxyClass would return an option set value via text based on the [Description] in the enum. Perhaps this already exists but, I did not see it in the documentation.

Something like
OptionSetValue ov = new OptionSetValue(ExtensionMethods.GetOptionSetValue("Active"));

...so that when I commit it to source control, I can use standard diff tools to review changes

I tried using the option to auto-publish on Save, but I actually save a lot (because VS crashes hurt) and only want to incur the publish delay when things are in a particularly good state. In other development this is when I do a Build, and I do build my CRM client scripts (Typescript ftw), so my ideal would be for a build to publish files changed since the previous build. Slightly less ideal but still good: publish all of the project's checked-out files. Worst case, manually flagging files to publish works, too.

Would it be possible to add StringLengthAttributes to string properties of auto generated classes? The length should reflect the maximum length of the CRM field.

https://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.stringlengthattribute(v=vs.95).aspx

It would help much, because right now setting a value that is to long for CRM does not raise an exception but just leaves to field empty in CRM (nothing is saved).

I would like to see a feature comparison of your product vs other tools/SDK options available