Tuesday, October 8, 2019

How to Enable PCF Components for Older Canvas Apps

The Backstory

I wanted to try and embed a browser into one of my existing canvas apps but ran into a snag.  I followed the instructions in the docs on enabling PCF components (https://docs.microsoft.com/en-us/powerapps/developer/component-framework/component-framework-for-canvas-apps) but I could only input Canvas based components, not PCF components because the "Import Components" "Code (experimental)" tab wasn't showing up even after I turned on the components preview option for the app:

I was able to eventually get the PCF Components to show up, but that required me to turn on every single preview/experimental feature of the app.  I was concerned that maybe this was because my app was running on an old version of Canvas Apps, so I upgraded by App to the latest version of the app, and PCF components were still not showing up (Again, never had any problem with Canvas components showing up).  I then proceeded to add every single experimental feature in the app settings, and again, the PCF components tab showed up, but when I imported the app into a new environment, the "Explicit Column Selection" feature broke the app.  Turning off this feature removed my PCF control from the app, so I was in a no-win situation.

To test my theory that the issue was because my app had some legacy bloat which was causing it to fail, I created a brand new app, and the PCF components showed up exactly as expected.  I then extracted my app using the CanvasApp Packager (https://github.com/daryllabar/CanvasAppPackager) and compared the differences in the extract json and found the fix!

Actual How To

To get get the PCF Controls experimental feature to show up in your older canvas app follow these steps:

  1. Export your app from the make.powerapps.com site to your machine.
  2. Unpack the app using the CanvasApp Packager (https://github.com/daryllabar/CanvasAppPackager).
  3. Open the Extract\Apps\<App Name>\Properties.json file.
  4. Search for the AppPReviewFlagsKey array.
  5. Add "nativecdsexperimental" to the end of the array e.g. "AppPreviewFlagsKey":["delayloadscreens","componentauthoring", "nativecdsexperimental"]
  6. Pack the app using the CanvasApp Packager.
  7. Import back into your make.powerapps.com environment.
  8. Enjoy being able to select your PCF components in your older Canvas App!

Saturday, May 11, 2019

Negotiating the CDS/CRM/Xrm Plugin Trace Log Length Limitation

With the Dynamics 365 CRM 2015 U1 update, the Plugin Trace entity was added to the platform.  This provided an OOB implementation for the ITracingService (although it only works in Sandboxed plugins) to log to that was a much needed addition to the platform.  Over time, my dependency and use of the ITracingService within the DLaB.Xrm library has greatly increased.  By default, the plugin base auto logs the name of the plugin that is executing, the start and stop time, each IOrganizationService call that is made, and on exceptions, the entire plugin context to make debugging easier.   With all of this logging, it is becoming more and more common for plugins to exceed the 10,240 character limit.  This results in the beginning of the trace log getting truncated.

So what’s the solution?  You could completely abandon the built in ITracingService, and trace to Application Insights.  As much as I love that solution, for anything but large CRM/CDS implementations it may be overkill.  With the assumption that most of the time, the information that is helpful for debugging will be at the beginning or the end of the trace, I’ve updated the default ITracingSevice in the DLaB.Xrm library, when in cases of the tracing being longer than 10,240 characters, to retrace the first 5,120 characters, and then retrace the last 5,120.

Let’s take a look at the implementation:
public class ExtendedTracingService: IMaxLengthTracingService
    private ITracingService TraceService { get; }
    public int MaxTraceLength { get; }
    private StringBuilder TraceHistory { get; }
    public ExtendedTracingService(ITracingService service, int maxTraceLength = 10244) {
        TraceService = service;
        MaxTraceLength = maxTraceLength;
        TraceHistory = new StringBuilder();
    public virtual void Trace(string format, params object[] args) {
            if (string.IsNullOrWhiteSpace(format) || TraceService == null)
            var trace = args.Length == 0
                ? format
                : string.Format(format, args);
        catch (Exception ex)
            AttemptToTraceTracingException(format, args, ex);

    /// <summary>
    /// If the max length of the trace has been exceeded, the most important parts of the trace are retraced.
    /// If the max length of the trace has not been exceeded, then nothing is done.
    /// </summary>
    public void RetraceMaxLength()
        if(TraceHistory.Length <= MaxTraceLength)
        var trace = TraceHistory.ToString().Trim();
        if(trace.Length <= MaxTraceLength)
            // White Space 
        //Assume the three Traces will each add New Lines, which are 2 characters each, so 6
        var maxLength = MaxTraceLength - 6;
        if(maxLength <= 0)
        var snip = Environment.NewLine + "..." + Environment.NewLine;
        var startLength = maxLength / 2 - snip.Length; // Subtract snip from start
        if(startLength <= 0)
            // Really short MaxTraceLength, don't do anything
        Trace(trace.Substring(0, startLength));
        Trace(trace.Substring(trace.Length -(maxLength - (startLength + snip.Length))));
The ExtendedTracingService wraps the default ITracingService from the platform, and then on calls to trace, it intercepts the call, and adds the trace to an in memory StringBuilder first, before actually tracing the call.  The final step in the plugin base is to then call RetraceMaxLength().  This will check the length of the StringBuilder, and if it’s over the max length, trace the first part of the traces, and then the last part, with an “…” in the middle to serve as a “Snip” statement.

If you’re already using the DLaB.Xrm.Source library, get the latest (>= version from NuGet, and enjoy ensuring you always see the beginning and end of reach trace.  If you’re not using the DLaB.Xrm.Source Library, why not? It’s free, open source, and because it’s a source only NuGet package, doesn’t require ILMerge when being used from a plugin.  You can even use the Visual Solution Accelerator in the XrmToolBox to bring it into your existing CRM/CDS VS solution.

Here is an example log: (I’ve removed a great deal of text, just notice that the “…” serves as the signal that the trace was too long, and the middle portion has been truncated)

Starting Timer for Execute Request for dlab_LeadSearch with * Parameters *,     Param[IsMovers]: False,     Param[PhoneNumber]: 5553214321.
Timer Ended (  0.096 seconds)
Starting Timer: IsRejectedOrCreateLead
Partner Not First Party
Lead validations:
is 30 Days Logic: True
is Same Day Inquiry: True
is rejected: True - 30 Day Lead Logic
Timer Ended (  0.000 seconds): IsRejectedOrCreateLead
Starting Timer: is30DaysLogic
Timer Ended (  0.000 seconds): is30DaysLogic
Starting Timer for Create Request for dlab_leadqualifier with Id 00000000-0000-0000-0000-000000000000 and Attributes     [dlab_name]: Homer Simpson
     [dlab_azureid]: 317578
     [dlab_5daylogic]: 0
     [dlab_7daylogic]: 0
     [dlab_14daylogic]: 0
     [dlab_30daylogic]: 0
     [dlab_30daylogiccurrent]: 1
     [dlab_jornayalogic]: 0
     [dlab_dayslogic]: 0
     [dlab_existinglead]: True
Timer Ended (  0.033 seconds)
Start of isUpdatePath - 2019-05-11-07:32:41 407
Starting Timer for Update Request for lead with Id c97e6f52-6431-e911-8190-e0071b663e41 and Attributes     [trans
    Param[skipExport]: False
     Param[primaryPhoneDnc]: False
     Param[secondaryPhoneDnc]: False
* Output Parameters *
PostEntityImages: Empty
PreEntityImages: Empty
* Shared Variables *
     Param[Example.Xrm.LeadApi.Plugins|dlab_createLeadRequest|PostOperation|00000000-0000-0000-0000-000000000000]: 1
Has Parent Context: False
Stage: 40   

Tuesday, November 13, 2018

How To Fix Email Always Being Dirty

Recently, some customers complained that the email form was always showing as dirty.  Normally this happens when something is triggered post save that makes the form dirty again, and tracking it down can be difficult.  The simplest thing (assuming you have some JS executing on the on save) is to put a break point in the on save, and see what attributes are dirty in the console window:
Xrm.Page.getAttribute().map(function (a) { return a.getIsDirty() + " - " + a.getName(); });
The other option is to look at the requests either in the F12 Developer Tools, or in Fiddler, and see what data is being sent to the server.  In this case though, the only field that was being marked as dirty was the description, but I couldn’t visually see any changes that were occurring.  The description in the email in this case contained some html that was inserted via a signature template, so I decided to see if there was anything in the html that was different, so I edited the JS to include storing the description in a class level variable that then could be used to compare with the current value in an on change event.  Sure enough, there were some differences in the html.  The spaces after semicolons and colons in tags were being removed, as well as quotes around numbers (ie. size=”3” –> size=3).  Finally I also noticed that blank characters were being encoded differently as well (“&#160;” vs “&nbps;”).  After a good deal of trial and error, I finally came up with this supported solution (Note, this type of solution can be applied to any situation where you want to ignore formatting differences.  Also, this is for an 8.2 CRM instance, so if this issue occurs in the new UI for CRM, you’ll need to access the context in the correct manner): 
var serverEmailDescription = "";
var ignoreDescriptionUpdates = true;
 * When dealing with html in the body, the form will format it differently than the server, resulting in some changes happening post save.
 * This then shows up as the field being dirty, but saving it again, will update the format again, and cause it to still look dirty
 * Fix is to mark it as submitmode = never if it isn't really dirty.  This will prevent the form from looking like it needs to be saved.
function handleDescriptionAlwaysBeingDirty() {
    var description = Xrm.Page.getAttribute("description");
    if (!description) {
    serverEmailDescription = removeServerDifferentFormatting(description.getValue());
    Xrm.Page.getAttribute("modifiedon").addOnChange(function() {
        serverEmailDescription = removeServerDifferentFormatting(Xrm.Page.getAttribute("description").getValue());
        ignoreDescriptionUpdates = true;
        setTimeout(function() { ignoreDescriptionUpdates = false; }, 1);
    setTimeout(function () { ignoreDescriptionUpdates = false; }, 1);
function removeServerDifferentFormatting(v) {
    // Some Html Tags get surrounded with \"
    // Some spaces are added for ";" and ":"
    // Blank spaces are encoded differently
    return v.replace(newRegExp(": ", "g"), ":")
        .replace(new RegExp("\\\"", "g"), "")
        .replace(new RegExp("; ", "g"), ";")
        .replace(new RegExp("&#160;", "g"), "&nbsp;");
function submitIfActuallyDirty() {
    var att = Xrm.Page.getAttribute("description");
    var description = removeServerDifferentFormatting(att.getValue());
    if (ignoreDescriptionUpdates) {
        serverEmailDescription = description;
    if ((description === serverEmailDescription) === (att.getSubmitMode() === "dirty")) {
        att.setSubmitMode(description === serverEmailDescription ? "never" : "dirty");
The main function is the handleDescriptionAlwaysBeingDirty function, which is called onLoad of the form.  It ensures that the description field is on the form, and then adds an onChange function to the modifiedOn and description attributes.  It also caches the initial value of the description, as well as setting the submit mode to “never”.
The modifiedOn attribute will get updated by the server post save, so the function can be used to store what the value of the description field was just after saving.  Due to the issue of the formatting being different, I first attempt to replace anything that would be different between how the server stores the format, and how the client framework updates it post save, before caching the description. 
Whenever the description is updated, either via a user, or post save, the formatting is normalized to compare it with the normalized cached version to see if it truly has changed.  If it has, the submit mode is changed from “never” to “dirty”.  The submit mode is updated for two reasons:
  1. There is no supported method to update the IsDirty flag.
  2. When an attribute isn’t set to be submitted, the form doesn’t check to see if it’s dirty when showing the “Unsaved Changes” text in the lower right hand corner of the screen.  This solves our infinite loop issue with the description always being updated!
Please note, this is not a perfect solution.  If someone edits the description of the e-mail and adds a space after a colon or a semicolon, the change won’t be registered,  Also the function removeServerDifferentFormatting may not include all of the possible formatting changes.  But it works on my machine and resolves the current issue at hand, and hopefully it is helpful for you as well!

Wednesday, September 12, 2018

Tell Your Code To Debug When You’re Good And Ready!

When doing dev work for the Early Bound Generator I frequently have to kick off a process in the XrmToolBox, and then attempt to attach my debugger as quickly as possible.  This is a really annoying race condition, and if I’m using local metadata, a race that I don’t usually win.  I can’t believe I hadn’t thought of this before, and for all I know the pattern exists else where in the wild, but it made my “attach to process to debug” workflow a guarantee, rather than a race:

if (ConfigHelper.GetAppSettingOrDefault("WaitForAttachedDebugger", false))
    while (!Debugger.IsAttached)
        Console.WriteLine("[**** Waiting For Debugger ****]");

The ConfigHelper is a helper class in the DLaB.Common that will look for the given AppSettings in the Config file, and if it doesn’t exist, default to the given value (“false” in this case).  So if I add an AppSetting to “WaitForAttachedDebugger” in my config, then my app will wait until a debugger is attached, checking indefinitely every 3 seconds to see if I’ve finally attached it. 

If you found this helpful, make sure to check out, my Raise The Bar video series

Happy coding!

Monday, August 28, 2017

Debugging Quick Create Form Parameters

I’ve been working with Microsoft CRM since the release of CRM 2011 (Yes, I know it’s now called Dynamics 365 for Customer Engagement, but just like Jar Jar Binks, let’s just pretend that didn’t happen).  But every now and then it forces me to peel back a few more layers to reveal something new that I’ve never known before.  This is the story of one of those “special” times.

TLDR: When adding form parameters to a quick create form, add them to the default main form as well.  Not doing so will cause your quick create form to throw a server side error and not load.

The Task

I recently received a fairly straight forward task: use the zip/postal code from the parent form (the form from which the quick create is opening from) to populate the tax rate on the quick create.  At least those were the fairly straight forward business requirements.  In order to implement it, I had to trigger a call on load of the Quick Create Form to auto-populate a field based on the results of a CrmWebApi query that used the value of a zip code field on the parent in the query filter.

So the first question was how to get access to the parent form’s attribute.  There are 3 basic options:
  1. Setup a field mapping in the entity relationship
  2. Pass in the value as a query string parameter
  3. Perform a call to the server from the onLoad of the quick create form, to query the data.
Option 1 was codeless, but I didn’t need the zip code field on my quick create entity and I avoid adding data that further denormalizes CRM, so it was at best, a last option.

Option 2 made sense, I just wasn’t sure if CRM supported adding parameters to a quick create form.

Option 3 was doable, but I’d have to make another call to CRM which I also avoid doing.

I quickly opened up the quick create form and saw that it did indeed allow adding parameters, so Option 2 became my saving grace.  I added “DLaB_ZipCode” as a form parameter to the quick create form (who am I kidding?  I totally didn’t read the requirements and attempted just “ZipCode” only to receive a nasty error that an underscore was required), and updated the Xrm.Utility.openQuickCreate call site to include the new “DLaB_ZipCode” parameter".

Finally I updated the onLoad of the quick Create form to get the newly added form parameter, and use it to query the CrmWebApi for the tax rate:

It Works On My Machine

I tested the new functionality by triggering the quick create form, and verifying that I did get the correct tax rate.  Everything worked smoothly, so I pinged my BA and told her it was ready for testing, and went onto my next task.  She ran through a couple quick tests as well and also declared it “programming complete.”  The next day during our daily stand up, a new BA to the project, we’ll refer to him as “Roger”, complained that he couldn’t get that particular quick create form to load.  I quickly ran another test on my machine and it still worked fine.  I asked Roger to test again; still broken for him…  weird. “Hmm… must either be a user issue, or a machine issue… “ I thought to myself.  It also didn’t help that the error was less than helpful: “Error: An Error has Occurred”.  I downloaded the log file but it too lacked anything helpful.  I then asked the original BA to try logging in on Roger’s machine and seeing if she should access the form from there.  A quick log off/log on later, and the results were unchanged.  Roger’s machine was still getting an error.  On a whim, after receiving the error on Roger’s machine, the BA cleared her browser cache, and discovered she was getting the error now as well.  I then opened up an incognito window and found that yes, I was now receiving the error as well.

Spinning A Web

My first assumption was that there was a JavaScript error occurring somewhere.  After diving down a couple rabbit holes, I was unable to find any errors being thrown that I could step into and debug. 

I then decided I must have the parameter name wrong somehow, so while debugging I cleared the parameters array that was being passed into the the openQuickCreate call.  This resulted in the form loading just fine but sans tax rate, obviously.  I closed the form and tried to open it again, this time leaving the zip code in the parameters, and to my dismay it opened just fine, with the correct tax code!  “What sort of magic is this?” I said to myself.  I asked Roger to test it on his machine again, but, even though I managed to fix the problem on my machine, he was still seeing the error.

Ok, so something must be getting cached on my machine that somehow allows the parameter on the form.  I started up a new incognito session and this time, after triggering the quick create from, I typed “localStorage” in the console window and hit enter:
I had never actually done that before and had no idea what I was looking for.  I took note of the 15 items in the storage, and then triggered the openQuickCreate call once more, but this time I removed the zip code parameter.  I once again spit out the localStorage and noted that now there were 18 items in the storage.  Doing a quick visual comparison one of the new keys stood out to me:

LocalStorageCache/EntityDefaultForm/DLaB_Payment: “5F5CC9D7-1E84-4381-AA14-32EA68536233”

Squashing The Bug

Apparently CRM was failing to cache the default entity form.  I then took a wild guess, and added the form parameter to the default main form for the entity and retriggered my test.  No error!  After another request to Roger to test it on his machine, it was confirmed that the bug had been resolved!  I then kicked over the trash can next to my desk in sheer joy and nearly gave my BA a heart attack…  I wouldn’t recommend that.

So What Happened?

Apparently before opening the Quick Create form, CRM attempts to load the default form.  This will cause the default form id to get cached in the localStorage.  Since my BA and I had both already cached this value in my localStorage before adding the “DLaB_ZipCode” form parameter, we didn’t have any issues after it was added.  Since Roger was new to the project, he had never cached the value and since I hadn’t added the “DLaB_ZipCode” parameter to the default form, he was getting the server error.  Adding the form parameter to the default form allowed the initial lookup of the default form to be successful and prevented the error from occurring. 

So if you’re adding form parameters to a quick create form, always remember to add them to the default form as well, even if it “works” on your machine…

Friday, August 4, 2017

TypeScript Makes Writing Cleaner Code Easier


Clean Coders know that Boolean Arguments can be dangerous and as a general rule, should be avoided.  I had this thought in mind when writing a TypeScript unit test recently.  I had this bit of code which is rather ugly and not immediately obvious what it was doing.
getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(1));
await Payment.setPayments("");
CommonLib.setValue(Payment.fields.paymentMethod, 1);
The fakeResponseWithPaymentCount sets the getPaymentMethodsSpy to generate the given number of fake existing payments for a count (1 in this case) as a response from the custom action, GetPaymentMethods.  Each odd numbered payment is a bank, and each even numbered one is a credit card.   So for this snippet, line 1 fakes a response of 1 Bank Payment, line 2 sets the Payment on the form, and line 3 selects that payment as the payment to use.  Simple right?  Not.  Good luck remembering this and re-creating it for processing a Credit Card.
So how does TypeScript here help make this cleaner?  Before we get there, lets do the obvious first step and refactor these statements out to a method:

async function selectExistingPayment(isBank: boolean) {
    getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(2));
    await Payment.setPayments("");
    CommonLib.setValue(Payment.fields.paymentMethod, isBank ? 1 : 2);
This is way more usable, except when I’m looking at a calls site for it, it’s still really not clear:
What does false mean?  Don’t select it?  Sure, you could create an enum and define “credit card”, and “bank” as the two options, but this is just a unit test helper method.  I’m not exposing it anywhere, and even if I did, that’s a lot of extra work (Ok, so it’s a tiny bit of work, but it can feel like a lot #1stWorldProblems).  The simple solution TypeScript offers is string Union Types.
async function selectExistingPayment(type: "CC" | "BANK") {
    getPaymentMethodsSpy.and.callFake(() => ActionsStubs.GetPaymentMethods.fakeResponseWithPaymentCount(2));
    await Payment.setPayments("");
    CommonLib.setValue(Payment.fields.paymentMethod, type === "BANK" ? 1 : 2);
So now the calls sites look like this:
Extremely readable as to what I’m doing, and you get compile time error checking that "Dad" (or any other values besides "CC" and "BANK" ) is not a valid Existing Payment Method!

Monday, July 31, 2017

How To Define Custom Action Parameters For Plugin Contexts

In my previous post “I’ve Been Doing Plugin Parameters Wrong For 7 Years”, I walk through IMHO the correct way to access parameters from the requests coming in for standard Dynamics 365 for Customer Engagement (hereafter referred to as CRM) Messages.  Applying the same logic for custom action plugins was a little more complicated because naturally, there are no message classes in the SDK for custom actions.  The CrmSvcUtil does generate early-bound classes for custom actions, which work fairly well for input parameters since they are editable, but response parameters by default are read-only.  So any attempt to set a value in the response via the parameter property, is not allowed.  There is also no defined list of parameter logical names, which could be used to set the values in the response context in a late-bound manner.

So, how does one work around the read-only response parameters and lack of a defined list of parameter logical names?  By extending CrmSvcUtil to make the read-only fields editable, and to generate a list of parameter logical names.  This isn’t very simple to do since you have to work directly with the DOM (no, not the html DOM, the C# DOM, it’s way less fun).  The good news is I have already done this, and provide it as a set of options in the Early-Bound Generator (If you aren’t already using the Early-Bound Generator, just download it from the Plugin Store within the XrmToolBox).  On the Actions Tab, just check “Generate Attribute Name Consts” and “Make Responses Editable”:


With those two options checked, when actions are generated, responses will be editable, and both request and response classes will contain a static class with consts for each parameter.  The absolute simplest and most immediate method of taking advantage of these generated action request/response classes would be to manually create them in the plugin like so:

public void Execute(IServiceProvider serviceProvider)
    var context = (IPluginExecutionContext) serviceProvider.GetService(typeof(IPluginExecutionContext));
    var request = new your_CustomActionRequest
                      Parameters = context.InputParameters
    var response = new your_CustomActionResponse
                       Results = context.OutputParameters

    // Use the Request and Response Properties
    response.Result = Process(request.SomeInputValue);

This isn’t horrible, but if you call any other methods, you’ll probably end up passing in the context and the request and/or response to that method.   The request and the response truly are part of the context, so if would make sense if we can make them just appear as a part of the context.  This can be done by creating your own custom context class:

public class ActionContext<TRequest, TResponse> : DLaB.Xrm.Plugin.DLaBExtendedPluginContextBase
    where TRequest : Microsoft.Xrm.Sdk.OrganizationRequest, new() 
    where TResponse : Microsoft.Xrm.Sdk.OrganizationResponse, new()
    public TRequest Request { get; set; }
    public TResponse Response { get; set; }
    public ActionContext(IServiceProvider serviceProvider, DLaB.Xrm.Plugin.IRegisteredEventsPluginHandler plugin) : base(serviceProvider, plugin)
        Request = new TRequest
            Parameters = PluginExecutionContext.InputParameters
        Response = new TResponse
            Results = PluginExecutionContext.OutputParameters

*Note* I’m using the DLaBExtendedPluginContextBase as my base class since this exposes all the IPluginExecutionContext methods for you (this is available on Nuget DLaB.Xrm.2015/2016). If you don’t want to use that, your ActionContext base class will need to implement the IPluginExecutionContext interface. 

Now our plugin code can be written with even less keystrokes:

public void Execute(IServiceProvider serviceProvider)
    var context = new ActionContext<your_CustomActionRequest, your_CustomActionResponse>(serviceProvider, this);

    // Use the Request and Response Properties
    context.Response.Result = Process(context.Request.SomeInputValue);

It might even make sense to create your own specific action context class to perform additional validation.  This would technically be cleaner code as well, since the context should be responsible for determining if it’s valid, not the plugin.  For example, here is a Custom Action class for processing payment that performs some validations:

using System;
using Consoto.Xrm.Plugin;
using DLaB.Xrm.Plugin;
using Microsoft.Xrm.Sdk;
using Input = Consoto.Xrm.Entities.cnst_SubmitPaymentRequest.Fields;
namespace Consoto.Xrm.ExternalRest.Finance.Actions
    public class SubmitPaymentContext : ActionContext<Entities.cnst_SubmitPaymentRequest, Entities.cnst_SubmitPaymentResponse>
        public const int CreditCardPaymentType = 1;
        public const int BankPaymentType = 2;
        public SubmitPaymentContext(IServiceProvider serviceProvider, IRegisteredEventsPluginHandler plugin) :
            base(serviceProvider, plugin)
            switch (Request.paymentType) {
                case CreditCardPaymentType:
                case BankPaymentType:
                    throw new InvalidPluginExecutionException($"Payment Type of {Request.paymentType} is unknown!");

This has the added benefit of not having to redefine the Request and Response Types in the plugin:

public void Execute(IServiceProvider serviceProvider)
    var context = new YourCustomActionContext(serviceProvider, this);

    // Use the Request and Response Properties
    context.Response.Result = Process(context.Request.SomeInputValue);

It used to take me over an hour (depending on the number of parameters in the custom action) to create the correctly defined custom action contexts, and of course I’d usually have a type-o or two that would require time debugging and re-updating.  Now that all the parameters are automatically generated, I get to spend that time on more productive things, like this blog post ;)

If you have any comments/feedback/suggestions/better methods, I’d love to hear them.  Happy coding!