DEV Community: Mehmet Seçkin

Continuously Delivering a PCF Control

Mehmet Seçkin — Fri, 21 Feb 2020 00:00:00 +0000

There are lots of things that can be possible with the mighty PowerApps Component Framework. The component development experience is great thanks to the scripting provided by the framework, however once you’re happy with your component, “shipping it” may not be so easy. You still have to deal with the produced solution archive (.zip) file. Moreover, the properties of this solution file is in an XML file in your repository, for example, you’ll have to increment the version number for the solution that will be output by your build process manually. This is fine if it’s a one-off operation, but it can be a little daunting when you have to repeat it over and over during your dev/test loop, or if you want to implement continuous delivery.

An example scenario

I have recently developed a PCF control to learn the framework, and decided to implement continuous integration and delivery. To achieve this, I decided to use Azure Pipelines and release the control as a managed solution to GitHub.

Let’s start with a CI pipeline that builds our new control:

stages:
- stage: 'build'
  jobs:
  - job: 'build_job'
    pool:
      vmAgent: 'windows-latest'
    steps:
    - task: VSBuild@1
      displayName: "Build"
      inputs:
        solution: 'Solutions\Solutions.cdsproj'
        msbuildArgs: '/t:build /restore'

Well, that was easy. However, our solution is getting built in Debug mode, and this produces an unmanaged solution by default. You can manually override this setting by specifying a property in the Solutions.cdsproj file. (Hint: The property is included as a comment in the generated project file).

In this scenario, we will just tell the pipeline to build in Release mode:

# ...
        msbuildArgs: '/t:build /restore /p:configuration=Release' # build in Release mode to get managed solution

Great, now we have our managed solution. Let’s give our build a name to provide unique version numbers to each build:

variables:
  version: '1.0.0'

name: $(version).$(build.buildId)

# stages: ...

Now each build has its own unique version number, but our solution version never changes. To update the solution version, we will use a simple PowerShell step:

# ...
    steps:
    - powershell: |
        echo "Updating solution version: $($env:BUILD_NUMBER)"
        $solution = [xml](gc "$($env:SOLUTION_XML_PATH)")
        $solution.ImportExportXml.SolutionManifest.Version = "$($env:BUILD_NUMBER)";
        $solution.Save("$($env:SOLUTION_XML_PATH)")
      displayName: 'Update solution version'
      env:
        BUILD_NUMBER: $(build.buildNumber) # a.k.a. the 'name', e.g. 1.0.0.5523
        SOLUTION_XML_PATH: 'Solutions\Other\Solution.xml'
    # - task: VSBuild@1 ...

Now, every build produces a managed solution with a unique version number. It’s time to tag the source in GitHub, and publish our managed solution to GitHub as a release.

To do this, we will first need to add a checkout step with persistCredentials flag set to true at the beginning of our build job, and a PowerShell script to create and push a tag to our repository.

    steps:
    - checkout: self
      persistCredentials: true

    # ... build tasks

    - powershell: |
        echo "Tagging Build: $($env:BUILD_NUMBER)"
        git tag $env:BUILD_NUMBER
        git push origin $env:BUILD_NUMBER
      env:
        BUILD_NUMBER: $(build.buildNumber) # a.k.a. the 'name', e.g. 1.0.0.5523
        GIT_REDIRECT_STDERR: 2>&1 # This is needed because git writes warnings to error stream and this fails the task

Now we can use the GitHub Release task to release our solution to GitHub. The githubConnection parameter accepts a Service Connection name which can be configured on Azure Pipelines in Project Settings > Service Connections.

    - task: GitHubRelease@1
      inputs:
        gitHubConnection: 'azure-pipelines-github-connection'
        repositoryName: '$(Build.Repository.Name)'
        action: 'create'
        target: '$(Build.SourceVersion)'
        tagSource: 'gitTag'
        assets: Solutions\bin\Release\*.zip

Our final pipeline definition looks like this:

variables:
  version: '1.0.0'

name: $(version).$(build.buildId)

stages:
- stage: 'build'
  jobs:
  - job: 'build_job'
    pool:
      vmAgent: 'windows-latest'
    steps:
    - checkout: self
      persistCredentials: true
    - powershell: |
        echo "Updating solution version: $($env:BUILD_NUMBER)"
        $solution = [xml](gc "$($env:SOLUTION_XML_PATH)")
        $solution.ImportExportXml.SolutionManifest.Version = "$($env:BUILD_NUMBER)";
        $solution.Save("$($env:SOLUTION_XML_PATH)")
      displayName: 'Update solution version'
      env:
        BUILD_NUMBER: $(build.buildNumber) # a.k.a. the 'name', e.g. 1.0.0.5523
        SOLUTION_XML_PATH: 'Solutions\Other\Solution.xml'
    - task: VSBuild@1
      displayName: "Build"
      inputs:
        solution: 'Solutions\Solutions.cdsproj'
        msbuildArgs: '/t:build /restore'
    - powershell: |
        echo "Tagging Build: $($env:BUILD_NUMBER)"
        git tag $env:BUILD_NUMBER
        git push origin $env:BUILD_NUMBER
      env:
        BUILD_NUMBER: $(build.buildNumber) # a.k.a. the 'name', e.g. 1.0.0.5523
        GIT_REDIRECT_STDERR: 2>&1 # This is needed because git writes warnings to error stream and this fails the task
    - task: GitHubRelease@1
      inputs:
        gitHubConnection: 'azure-pipelines-github-connection'
        repositoryName: '$(Build.Repository.Name)'
        action: 'create'
        target: '$(Build.SourceVersion)'
        tagSource: 'gitTag'
        assets: Solutions\bin\Release\*.zip

Hope this helps!

My First PCF Control: TimeZoneDisplay

Mehmet Seçkin — Fri, 21 Feb 2020 00:00:00 +0000

PowerApps Component Framework is a new way to build helpful, reusable components that provide better user experiences in an efficient and maintainable way. I have been looking for a PCF control idea to learn and explore this new framework and its capabilities.

Recently, I have missed a series of international webinars due to my timezone miscalculations, and decided to address this with a PCF control. This is how the Time Zone Display was born.

Time Zone Display is a simple control that allows you to convert a date or datetime field to any given time zone. It’s built using React.js and the Office UI Fabric components.

If you’d like to check it out, head over to GitHub to download the latest release.

If you have any feedback or would like to improve it, please get involved and create an issue or send a pull request!

A .NET Native Alternative to JSON.NET (a.k.a. Newtonsoft.Json) for Dynamics 365 Plugins

Mehmet Seçkin — Thu, 23 Jan 2020 00:00:00 +0000

A .NET Native Alternative to JSON.NET (a.k.a. Newtonsoft.Json) for Dynamics 365 Plugins

23 January 2020, Birmingham, UK

Background

JSON.NET (a.k.a Newtonsoft.Json) is a powerful JSON library. But when working with Dynamics 365 plug-ins, it needs to be combined into your plug-in DLL using ILMerge. This works fine, but using ILMerge for plug-in and custom workflow assemblies is unsupported and can jeopardise your support agreement.

If you don’t want to use ILMerge, or unable to for some reason, you can use DataContractJsonSerializer for most JSON tasks JSON.NET is capable of.

Show me the code

Here is an example drop-in replacement class with the same interface as JSON.NET:

using System.IO;
using System.Runtime.Serialization.Json;
using System.Text;

public static class JsonConvert
{
    public static string Serialize<T>(T obj)
    {
        using (var stream = new MemoryStream())
        {
            GetSerializer<T>().WriteObject(stream, obj);
            return Encoding.UTF8.GetString(stream.ToArray());
        }
    }

    public static T Deserialize<T>(string json)
    {
        using (var stream = new MemoryStream())
        {
            using (var writer = new StreamWriter(stream))
            {
                writer.Write(json);
                writer.Flush();
                stream.Position = 0;
                return (T)GetSerializer<T>().ReadObject(stream);
            }
        }
    }

    private static DataContractJsonSerializer GetSerializer<T>()
    {
        var settings = new DataContractJsonSerializerSettings
        {
            UseSimpleDictionaryFormat = true
        };

        return new DataContractJsonSerializer(typeof(T), settings);
    }
}

This can be used in the same way as JSON.NET:

// Serialize a Person object into a JSON string
string json = JsonConvert.Serialize(person);

// Deserialize a string into a Person object.
var person = JsonConvert.Deserialize<Person>(json);


using System.Runtime.Serialization;

[DataContract]
public class Person
{
    [DataMember]
    public string FullName { get; set; }

    [DataMember]
    public Dictionary<string, string> Attributes { get; set; }
}

Hope this saves someone a minute or two!

Perform CRUD Operations using `Xrm.WebApi`

Mehmet Seçkin — Wed, 18 Sep 2019 00:00:00 +0000

Perform CRUD Operations using `Xrm.WebApi`

I have recently had a challenge where I needed to perform some CRUD operations on a bunch of records, and wondered whether I could use the Client API Xrm.WebApi.online.executeMultiple to achieve this.

Here are the examples I’ve come up with, hope this saves someone some time!:

Update: These examples are now in the PowerApps docs, check it out: Perform CRUD Operations.

Create a record

The following example demonstrates how to perform a Create operation.

var Sdk = window.Sdk || {};
/**
 * Request to execute a create operation
 */
Sdk.CreateRequest = function (entityName, payload) {
    this.etn = entityName;
    this.payload = payload;
    this.getMetadata = function () {
        return {
            boundParameter: null,
            parameterTypes: {},
            operationType: 2, // This is a CRUD operation. Use '0' for actions and '1' for functions
            operationName: "Create",
        };
    };
};
// Construct a request object from the metadata
var payload = {};
payload["name"] = "Fabrikam Inc.";
var createRequest = new Sdk.CreateRequest("account", payload);
// Use the request object to execute the function
Xrm.WebApi.online.execute(createRequest).then(
    function (result) {
        if (result.ok) {
            console.log("Status: %s %s", result.status, result.statusText);
            // perform other operations as required;
        }
    },
    function (error) {
        console.log(error.message);
        // handle error conditions
    }
);

Retrieve a record

The following example demonstrates how to perform a Retrieve operation.

var Sdk = window.Sdk || {};
/**
 * Request to execute a retrieve operation
 */
Sdk.RetrieveRequest = function (entityReference, columns) {
    this.entityReference = entityReference;
    this.columns = columns;
    this.getMetadata = function () {
        return {
            boundParameter: null,
            parameterTypes: {},
            operationType: 2, // This is a CRUD operation. Use '0' for actions and '1' for functions
            operationName: "Retrieve",
        };
    };
};
// Construct a request object from the metadata
var retrieveRequest = new Sdk.RetrieveRequest({ etn: "account", id: "87547d08-b9d0-e911-a826-000d3a43d70a" }, ["name"]);
// Use the request object to execute the function
Xrm.WebApi.online.execute(retrieveRequest).then(
    function (result) {
        if (result.ok) {
            console.log("Status: %s %s", result.status, result.statusText);
            // perform other operations as required;
        }
    },
    function (error) {
        console.log(error.message);
        // handle error conditions
    }
);

Update a record

The following example demonstrates how to perform a Update operation.

var Sdk = window.Sdk || {};
/**
 * Request to execute an update operation
 */
Sdk.UpdateRequest = function (entityName, entityId, payload) {
    this.etn = entityName;
    this.id = entityId;
    this.payload = payload;
    this.getMetadata = function () {
        return {
            boundParameter: null,
            parameterTypes: {},
            operationType: 2, // This is a CRUD operation. Use '0' for actions and '1' for functions
            operationName: "Update",
        };
    };
};
// Construct a request object from the metadata
var payload = {};
payload["name"] = "AdventureWorks Inc.";
var updateRequest = new Sdk.UpdateRequest("account", "87547d08-b9d0-e911-a826-000d3a43d70a", payload);
// Use the request object to execute the function
Xrm.WebApi.online.execute(updateRequest).then(
    function (result) {
        if (result.ok) {
            console.log("Status: %s %s", result.status, result.statusText);
            // perform other operations as required;
        }
    },
    function (error) {
        console.log(error.message);
        // handle error conditions
    }
);

Delete a record

The following example demonstrates how to perform a Delete operation.

var Sdk = window.Sdk || {};
/**
 * Request to execute a delete operation
 */
Sdk.DeleteRequest = function (entityReference) {
    this.entityReference = entityReference;
    this.getMetadata = function () {
        return {
            boundParameter: null,
            parameterTypes: {},
            operationType: 2, // This is a CRUD operation. Use '0' for actions and '1' for functions
            operationName: "Delete",
        };
    };
};
// Construct a request object from the metadata
var deleteRequest = new Sdk.DeleteRequest({ entityType: "account", id: "87547d08-b9d0-e911-a826-000d3a43d70a" });
// Use the request object to execute the function
Xrm.WebApi.online.execute(deleteRequest).then(
    function (result) {
        if (result.ok) {
            console.log("Status: %s %s", result.status, result.statusText);
            // perform other operations as required;
        }
    },
    function (error) {
        console.log(error.message);
        // handle error conditions
    }
);

Recommendations on Git Commits and Pull Requests

Mehmet Seçkin — Thu, 24 Jan 2019 00:00:00 +0000

Recommendations on Git Commits and Pull Requests

A project’s long-term success is tightly coupled by its maintainability. A clean and well crafted source control history is one of the most important and powerful tools when it comes to maintain projects.

In this document, I will try to provide some recommendations to help us build and keep a clean source control history and make life easier for both our future selves and whoever might inherit and maintain your codebase.

Commits

The simplest building block of the source control history is the individual commits. As the commits get better, your source control history gets healthier, the project becomes easier to maintain and develop, which contributes a lot to the project’s success.

A good commit is an atomic set of changes, documented with a well-written commit message.

Make atomic commits

An atomic commit is a logically separated set of changes. Each set of change contains a single block of work that tackles a single task.

Give some thought into your changes and try to divide them into logical chunks of work, each addressing a single operations.

If you can, make your commits digestible; for example, don’t code for a whole week on five different bugs and then submit all of your changes in a massive commit:

Fix issues with single sign-on, header layout and another irrelevant module

Try to split your work into at least one commit per bug, with well-written commit messages. This will make it easier to review the changes and pull out or revert one of the change sets later if needed:

commit a023bac42
Author: Mehmet Seckin <mehmetseckin@example.com>
Date: Fri Jan 01 00:00:00 1970 -0000

Enable single sign-on for XYZ context

Fixes: #123
---
commit 0c2cda12
Author: Mehmet Seckin <mehmetseckin@example.com>
Date: Fri Jan 02 00:00:00 1970 -0000

Improve header layout

Moved the navbar towards the top of the page to prevent the logo from
disappearing in responsive mode.

Fixes: #456
---
commit 10dcb332
Author: Mehmet Seckin <mehmetseckin@example.com>
Date: Fri Jan 03 00:00:00 1970 -0000

Add plug-in support for XYZ module

Completes: #789

Write good commit messages

There are some well-established conventions as to what makes a good commit message. The following example shows the idiomatic format and sections of a good commit message:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

Here are some rules of thumb:

Treat the first line of your commit message as the Subject Line

The first line of your commit message should be treated like the subject line of an e-mail message.

This should summarise the changes in a short, descriptive sentence.

Start with a capital letter

The subject line should be capitalised, for example;

Fix file format and indentation

Keep it short - about 50 characters or less

50 characters isn’t an absolute limit, but it forces the author to think about the message and try to summarise it as clearly as possible.

If you’re having a hard time summarizing, you might be committing too many changes at once. Always try to make atomic commits.

Most git platforms are aware of this convention and will display a truncated version of your subject line if it’s longer than it supposed to be.

Use imperative mood in the subject line

Git itself uses imperative whenever it creates a commit, for example if you use git merge, you will see a commit message like the following:

Merge branch 'myfeature' into 'develop'

So when you write your commit messages in the imperative, you’re following Git’s own built-in conventions, which increases consistency across the source control history. For example:

Refactor XYZ to improve readability
Update README file
Remove deprecated methods
Merge 'feat/abc' into 'develop'
Release v1.0.0

is easier to follow than the following log:

Refactoring XYZ to improve readability
README file has been updated
Removal of deprecated methods
Merge 'feat/abc' into 'develop'
Released v1.0.0

Do not end the subject line with a period

Ending wih a period is unnecessary in subject lines. Besides, the period eats a precious character from the 50 character limit.

Do this:

Configure Kerberos authentication

instead of this:

Configure Kerberos authentication.

Add a body to explain the context and details of your change

Not every commit message requires a subject and a body. Some commits can be as simple as:

Correct typo in README file

There is no need to say anything more. If the reader wants to know what was the typo, they can take a look at the change.

However, sometimes your commit needs a bit of explanation or context. In this case, add details of your change after your subject line. Try to explain the context and reason of the change. For example:

Re-authenticate user with admin scope

The X action requires the user to have elevated privileges. This commit
adds functionality to request the necessary privileges and perform the
action subsequently.

Separate the body from the subject line with a blank line

For example, git revert generates the following:

Revert "Add the thing with the stuff"

This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.

Use the body to explain what and why instead of how

Code is generally self explanatory about how a change was made. Focus on documenting the problem your solution and why is it the best way to tackle the problem in the message, instead of the implementation details of your solution.

For example, do this:

Clear the token cache when a new session starts

The cached tokens were being re-used by the browser which resulted
in token renewal errors between sessions. Clearing the token cache
avoids the futile effort by the browser to renew the previous session.

Instead of this:

Clear the token cache when a new session starts

Call `OAuth2UserManager.TokenCache.Clear()` to clear the token cache.

Add references to tasks or bugs at the end of the body

Drop a reference to the related work item to make it much easier to track the cause of the change. This is especially good when the git platform is capable of automatically associating the referenced work item as it also helps with changelogs.

Pull Requests

The Pull Requests are an important part of the source control history, because this is the place where a particular change is documented, explained, reviewed and refined.

Keep Pull Requests as small as possible

The more changes in a pull request, the harder to understand it, and the longer it takes to review it.

Break down your work into multiple pieces of logically separate and independent pull requests to ease the review process, catch bugs early and reduce code smell.

Apply single responsibility principle

The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

Just like classes and modules, pull requests should do only one thing. Before submitting a PR for review, try applying the principle of single responsibility. If this code is doing more than one thing, break it into other Pull Requests.

The Pull Request title should be short and self-explanatory

The title should be sufficient to understand what is being changed. For example:

Add single sign-on support for X
Improve registration error handling process

The description should contain as much detail as possible

Describe what has changed.
Explain why has the change been made.
Clearly define how the change was implemented
Use screenshots, code snippets and other resources to demonstrate the changes.

This is especially helpful if the Pull Requests are merged into the mainstream via a squash merge, in which case your PR title and description will automatically form a good commit message.

Delete multiple Azure Active Directory applications via PowerShell

Mehmet Seçkin — Tue, 25 Sep 2018 00:00:00 +0000

Delete multiple Azure Active Directory applications via PowerShell

Recently, I needed a quick way to delete multiple Azure Active Directory applications. This is unfortunately not possible through the Azure portal, so it was time for a little PowerShell magic.

I came up with a little command named Remove-AzureADApplications, which will present a list of applications on your tenant and delete the selected applications. It also features a silent execution mode (-Force parameter) and a display name begins with filter option (-SearchString parameter).

Check it out:

<#
  .SYNOPSIS
  Delete multiple Azure AD applications based on a search criteria.

  .DESCRIPTION
  The Remove-AzureADApplications cmdlet displays a list of all applications registered in the Azure Active Directory, and deletes specified applications from Azure Active Directory (AD).

  .PARAMETER SearchString
  The service principal search string.

  .PARAMETER Force
  Forces the command to run without asking for user confirmation. This will remove all applications that match the filter criteria specified by the SearchString parameter, without displaying a list and waiting for the user to specify which applications are going to be deleted. If the SearchString parameter is omitted, this will attempt to delete all application registrations without confirmation. Use with caution.

  .EXAMPLE
  Remove-AzureADApplications

  Displays the list of all applications registered in the Azure Active Directory, and deletes selected applications.

  .EXAMPLE
  Remove-AzureADApplications -SearchString "deleteme" -Force

  Remove applications whose names start with "deleteme" without displaying a list for the user to select.
#>
function Remove-AzureADApplications 
{
    [CmdletBinding()]
    param
    (
        [Parameter(HelpMessage = "The service principal search string.")]
        [string]
        $SearchString = "",    
        [Parameter(HelpMessage ="Forces the command to run without asking for user confirmation. This will remove all applications that match the filter criteria specified by the SearchString parameter. If the SearchString parameter is omitted, this will attempt to delete all application registrations without confirmation. Use with caution.")]
        [Switch]
        $Force
    )

    Import-Module "AzureAD";

    if ($SearchString) {
        $apps = (Get-AzureADApplication -SearchString $SearchString)
    }
    else {
        Write-Warning "No search string specified. Fetching all applications."
        $apps = (Get-AzureADApplication -All $true)
    }

    if($Force)
    {
        $selectedApps = $apps;
    }
    else
    {
        $selectedApps = $apps | Out-GridView -Title "Please select applications to remove..." -OutputMode Multiple;
    }

    $selectedApps | ForEach-Object {

        $displayName = $_.DisplayName;
        $objectId = $_.ObjectId;
        try {
            Remove-AzureADApplication -ObjectId $objectId
            Write-Host "Removed $displayName..." -ForegroundColor Green;
        }
        catch {
            Write-Host "Failed to remove $displayName..." -ForegroundColor Red;
        }
    }
}

Clean up git branches that do not exist on origin

Mehmet Seçkin — Wed, 08 Aug 2018 00:00:00 +0000

Clean up git branches that do not exist on origin

After our team worked on a git repository for a while, we accumulated a lot of useless branches that are no longer being used. We’ve removed these branches regularly from the origin, but the local branches remained in everyone’s workstations like zombies.

It was time to do something.

That’s when we decided to combine the powers of git fetch --prune and shell scripting to forge a PowerShell function that will kill the zombie branches in our local repositories.

The script simply uses git fetch --all --prune to update all remote references (--all) and drop deleted ones (--prune).

After this, it filters out the local branches that do not exist on the origin by scraping the output of git branch -vv, and deletes the zombie local branches.

Here’s the whole thing:

<#
.SYNOPSIS
Remove local git branches that are deleted from the origin.

.DESCRIPTION
Removes local git branches that are deleted from the origin using `git fetch --prune` and `git branch -[dD]`.

.PARAMETER Force
Switch to to force removal using `git branch -D` instead of `git branch -d`.

.EXAMPLE
Remove-DeletedGitBranches
Removes merged non-existing branches.

.EXAMPLE
Remove-DeletedGitBranches -Force
Removes all non-existing branches.

.NOTES
This cmdlet uses `git fetch --prune`, so it will delete references to non-existing branches in the process. Use with caution.
#>
function Remove-DeletedGitBranches
{
    param
    (
        [Parameter()]
        [Switch]
        $Force
    )

    $null = (git fetch --all --prune);
    $branches = git branch -vv | Select-String -Pattern ": gone]" | ForEach-Object { $_.toString().Split(" ")[2] };
    if($Force)
    {
        $branches | ForEach-Object {git branch -D $_};
    }
    else 
    {        
        $branches | ForEach-Object {git branch -d $_};        
    }
}

Set-Alias -Name "rmdelbr" -Value Remove-DeletedGitBranches

Extending Dynamics 365 Package Deployer

Mehmet Seçkin — Mon, 25 Jun 2018 00:00:00 +0000

Extending Dynamics 365 Package Deployer

25 June 2018, Windsor, UK

The Dynamics 365 Package Deployer is a great tool that allows you to move your customisations and data between environments in bulk.

It imports your solutions and data, and provides an API to hook your custom code up to this process at certain points. These hooks are as follows:

Custom code hooks for Dynamics 365 Package Deployer process

Method Name	Execution Time
`InitializeCustomExtension`	After the package deployer extension is initialized, before the solution import process.
`PreSolutionImport`	Before importing each solution.
`RunSolutionUpgradeMigrationStep`	Before importing each solution, only if the solution that is being imported is already present in the target Dynamics 365 instance.
`BeforeImportStage`	Before the solution import completes, if the sample data or flat files are being imported.
`AfterPrimaryImport`	After the solution and data imports are completed.

There are some special parameters and properties that you can set in some of these methods. These parameters and properties can be set to alter the deployment behaviour, such has enabling plug-ins and workflows disabled, overriding safety checks during data import, etc.

There are also some cool methods that lets you interfere with the user interface, such as the CreateProgressItem, RaiseUpdateEvent, RaiseFailEvent methods. These methods enables you to create your own progress items in the progress items pane, however they seem to be only effective after the solution import process begins.

Another cool property that is provided via the Dynamics 365 Package Deployer API is RootControlDispatcher. This property allows you invoke logic in the Package Deployer’s main UI thread. This means, you can use your custom WPF user interface during a package deployment.

The Package Deployer also supports customised Welcome and End HTML pages for license agreements, release notes and whatnot. This also supports javascript, however I haven’t tried to run a full-blown single page application on there, and I believe the javascript support would be somewhat limited.

A JavaScript alert from a custom welcome page in Dynamics 365 deployment package

There is a lot of clever stuff that can be done using these extension points if you want to customise, enhance and automate the deployment process of your Dynamics 365 applications.

DEV Community: Mehmet Seçkin

Continuously Delivering a PCF Control

An example scenario

My First PCF Control: TimeZoneDisplay

A .NET Native Alternative to JSON.NET (a.k.a. Newtonsoft.Json) for Dynamics 365 Plugins

A .NET Native Alternative to JSON.NET (a.k.a. Newtonsoft.Json) for Dynamics 365 Plugins

Background

Show me the code

Perform CRUD Operations using `Xrm.WebApi`

Perform CRUD Operations using Xrm.WebApi

Create a record

Retrieve a record

Update a record

Delete a record

Recommendations on Git Commits and Pull Requests

Recommendations on Git Commits and Pull Requests

Commits

Make atomic commits

Write good commit messages

Treat the first line of your commit message as the Subject Line

Start with a capital letter

Keep it short - about 50 characters or less

Use imperative mood in the subject line

Do not end the subject line with a period

Add a body to explain the context and details of your change

Separate the body from the subject line with a blank line

Use the body to explain what and why instead of how

Add references to tasks or bugs at the end of the body

Pull Requests

Keep Pull Requests as small as possible

Apply single responsibility principle

The Pull Request title should be short and self-explanatory

The description should contain as much detail as possible

Further Reading

Delete multiple Azure Active Directory applications via PowerShell

Delete multiple Azure Active Directory applications via PowerShell

Clean up git branches that do not exist on origin

Clean up git branches that do not exist on origin

Extending Dynamics 365 Package Deployer

Extending Dynamics 365 Package Deployer

Perform CRUD Operations using `Xrm.WebApi`