This is the documentation site for Kipon.Xrm.Cmd (a small toolbox to support Dynamics 365 CE development related tasks.)
You must create a .NET framework project, because sharing files over the content folder is not support for .NET Core. But the Kipon.Xrm.Tools does not need to live within your actual target project because it is just a command line tool that can do the task of solving common "generate source for metadata" and "deploy source to Dynamics 365 CE". The tool it self does not add anythings else beside som configuration templates for each tool supported.
- Create an .NET Framework project. It can be a commandline tool or a class library, ex. .NET 4.7.2 framework. (it must be .NET Framework, but the version is less important)
- Now install the Kipon.Xrm.Tools nuget package within that project.
- After install (Microsoft.CrmSdk.CoreTools will be installed as well), you have a folder bin\coretools within that project.
Here you have Kipon.Xrm.Cmd executable. This is the entrypoint for the tools offered by this package.
WebResources - generate d.ts for your forms, and deploy scripts to Dynamics 365 ce web resource, and components to solutions.
If you are writing webresources in typescript and uses the @types/xrm types to help you with intelicense while doing development, this is the framework for you to go one step futher. This tool allow you to generate .d.ts files that match your Dynamics 365 CE entityforms.
If you are new to @types/xrm, and this is your first typescript based webresource library, follow these simple steps:
- Create a new project of type ASP.NET Core
- Add npm support to your project
- Add @types/xrm package to your project
Now your solution is ready for typescript based webresources.
This generator tool is for Dynamics 365 CE forms what Data EntityContext (CrmSvcUtil.exe) is for the database. You will work with strongly typed forms, that only have attributes and controls according to the actual form, and if you make changes to the form in Dynamics 365 CE, simply regenerate the .d.ts files with this tool, and the ts compiler will guide you to places where attributes or controls has been remove, because it will generate compile errors in you IDE.
You must setup a filter.xml in the root of your webresources project:
[filter.xml]
<webresource>
<forms namespace="Kipon.Forms" typings="Scripts\typings\">
<form entitylogicalname="account" title="Account" name="Account" />
<form entitylogicalname="account" title="Sales Insights" name="SalesInsights" />
<form entitylogicalname="contact" title="Contact" name="Contact" />
<form entitylogicalname="contact" title="AI for Sales" name="AIforSales" />
</forms>
<deploys ..>
...
</deploys>
</webresource>For each form, add a form tag to the forms container, specifying the entitylogicalname, the title of the form, and the TypeScript conformed name to be used the generating the .d.ts fil for the form.
the Above definition will generate d.ts files for the account entity, form Account, and form SalesInsights, and for the contact entity it will generate Contact and AiForSales form definitions. Be aware the the word "Form" wil be added to the end of the interface.
After the d.ts file has been generated, it can be imported and used within your forms:
/// <reference path="../../node_modules/@types/xrm/index.d.ts" />
/// <reference path="../typings/Kipon.Forms.d.ts" />
module Kipon.Account {
var Form: Kipon.Forms.account.AccountForm;
export function onLoad(ctx: Xrm.Page.EventContext) {
Form = ctx.getFormContext();
var s = Form.getAttribute("name").getValue();
var p = Form.getAttribute("donotemail").getValue();
Form.ui.tabs.forEach(r => {
});
Form.ui.tabs.get("SUMMARY_TAB").sections.get("SOCIAL_PANE_TAB").setVisible(false);
}
}Above code is just to demonstrate that "casting" the formcontext into a specific interface (Kipon.Forms.account.AccountForm) allow us to work on the formcontext business-as-usual, if you are using @types/xrm, but the difference is, if you address attributes through Form.getAttribute("xxx") or Form.getControl("xxx") that does not sit on the form, you will get compile time errors.
On to of that, you IDE can give you intelise when working with the Form instance. It is from a development perspective easer to work with, and causes fewer bugs, and help you keep your code in sync. with whatever changes are made to the form through the Dynamis 365 CE customization interface.
The files generated is pure d.ts files (interface only), so it will have zero impact on the size of the scripts deployed to the Dynamics 365 CE platform
Assuming the filter.xml is hosted in the root of you webresource project:
The folder must contain a folder structure before you generate correspinding to the typings attribute of the forms tag. this folder is NOT created on the fly
[Kipon.Xrm.Tools project folder]\bin\coretools\Kipon.Xrm.Cmd wr-generate "/connectionstring:[Dynamics365CEConnectionString]"
[Dynamics365CEConnectionString] supported the Dynamics 365 CE Tools pattern for connectionstring.
The generated d.ts file is added or updated in the typings folder.
The Kipon.Xrm.Tools can help you deploy your "code-managed" webresource into your Dynamics 365 development instance.
This makes a lot of sence if you are using the above "generate" tool to write typescript forms based on strongly typed formdefinitions.
First you need to configure what to deploy. This is done within the shared filter.xml til in the deploys section of the xml:
[filter.xml]
<webresource>
<forms ..>
---
</forms>
<deploys managed-solution="WebResourceManagerKipon">
<solutions>
<solution name="KiponToCustomer"/>
</solutions>
<deploy file="Scripts/Forms/Account.js" name="kipon_/Forms/Account.js" description="Form script for the standard account form" />
</deploys>
</webresource>You should setup an unmaned solution in your development instanse that has the single purpose of hosting all webresources that is deployed from you webresource source projekt. In ahove example i have named that solution [WebResourceManagerKipon]. This solution should be "owned" by the Kipon.Xrm.Tools deployment context. This allow the tool to cleanup if scripts are removed.
If you need the scripts to be deployed in additional solutions, (ex. thouse you use to move the DEV to TEST and PROD environments), simply add more solutions names under the solutions container in the xml.
The difference between the managed-solution, and the list of solutions is, that this tool assume to have full control on all elements in the "managed-solution", while it does not assume anything about elements in the solutions list, beside the fact that webresources deployed through this tool, also need to be added to these solutions.
[Kipon.Xrm.Tools project folder]\bin\coretools\Kipon.Xrm.Cmd wr-deploy "/connectionstring:[Dynamics365CEConnectionString]"
[Dynamics365CEConnectionString] supported the Xrm.Tools pattern for connectionstring.
This will create/update webresource mentioned in the deploy section, delete components that are in the WebResourceManagerKipon that is no longer mentioned in the deploys section, and finally attach the webresources to the solutions.
Finally the tool will publish all resource that was created or updated in the process.
Instead of deploying each and every javascript as a separate file, you can organize the scripts in "natural" script containers, describing the dependencies within the root script.
/// <reference path="../../node_modules/@types/xrm/index.d.ts" />
/// <reference path="../typings/Kipon.Forms.d.ts" />
//#include Scripts/Services/AccountService
module Kipon.Account {
var Form: Kipon.Forms.account.AccountForm;
export function onLoad(ctx: Xrm.Page.EventContext) {
var ac = new Kipon.AccountService().getSomething();
}
}Take a look at above example. In the code i need to work with a "generic" service that can be used cross form scripts, ex. to fetch som account data. The AccountService is a typescript that will be compiled into AccountService.js, and normally we would deploy this script to Dynamics 365 CE, and then include both the AccountService.js script and the Account.js on the form.
But instead of using such deploy model, i can ask the deployment tool to merge the scripts into a single script that is merged and deployed. That way I only need to deploy the Account.js script, and the AccountService will be embedded in any formscript adding the above include.
//#include also works for nested scrpts. So if the AccountService script also have includes, these will also be expanded into the single script deployment Account.js
This tool is used to generate plugins and deploy the plugins when you are using the Kipon.Solid.Plugin framework. You do NOT need to install this package if you use the Kipon.Solid.Plugin nuget package. Everything you need is already included in that package.
You can use the Kipon.Xrm.Tools to generate entites for non Kipon.Xrm.BasePlugin, with a very simple filter mechanism. This is convinient, if you have old projects with strong entity type generation, but you wish to start filter entities out, because you upgraded to a Dynamics 365 CE version that adds way to much, if you just generate everything.
The filter.txt file should be placed in the folder from where you run the CrmSvcUtil command (not nessesarrely the folder where you host the CrmSvcUtil.exe), and have an entity name on each line. You can state all entities matching a start pattern by proiding all: keyword infront, ex
[filter.txt] all:kipon_ contact account task
This will limit genration of entities to entities starting with kipon_, and it will also generate account, contact and task.
On the command line prompt, you specify the filter same way as for plugins:
(assuming you generate command is hosted in a folder a single level down from the root of your plugin/tooling project)
[Kipon.Xrm.Tools project folder]\bin\coretools\CrmSvcUtil.exe [other parameters] /codewriterfilter:Kipon.Xrm.Tools.CodeWriter.PlainTxtCodeWriterFilter,Kipon.Xrm.Tools
Installing the kipon.xrm.tools package ensure that the filter mentioned above is in the coretools folder.
MIT (c) Kipon ApS, 2019,2020,2021