Category Archives: Test Automation

ALM – Power Platform – Copy Azure DevOps Build/Release to New Project

Here is my next video on “Tips & Tricks in ALM with PowerApps Build Tools”.

Please do subscribe my channel.

In this video, I have explained how to Copy Azure DevOps Build/Release Pipeline to New Project.

Here is the link for my course on Power Platform – ALM Fundamentals

CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS -Part 5 – Master Data Deployment

In my previous blog, I wrote about how to set up a gated check-in, In this blog, we will see how to move the master data from source to target instance using our CI/CD pipeline.

Generally, we use the configuration migration tool to move the master data across multiple environments and organizations. Configuration data is used to define custom functionality in model-driven apps in Dynamics 365, such as Dynamics 365 Sales and Customer Service, and is typically stored in custom entities. Configuration data is different from end-user data (account, contacts, and so on). A typical example of configuration data is what you define in the Unified Service Desk for Dynamics 365 to configure a customized call center agent application. The Unified Service Desk entities, along with the configuration data that is stored in the entities, define an agent application.

Note: Disable plug-ins before exporting data and then re-enable them on the target system after the import is complete for all the entities or selected entities.

Master data/Configuration data deployment

undefinedDefine the schema of the source data to be exported: The schema file (.xml) contains information about the data that you want to export such as the entities, attributes, relationships, definition of the uniqueness of the data, and whether the plug-ins should be disabled before exporting the data.

undefinedUse the schema to export data: Use the schema file to export the data into a .zip file that contains the data and the schema of the exported data.

undefinedImport the exported data: Use the exported data (.zip file) to import into the target environment. The data import is done in multiple passes to first import the foundation data while queuing up the dependent data, and then import the dependent data in the subsequent passes to handle any data dependencies or linkages.

Instead of moving it manually we are going to automate this above process using Azure DevOps.


  • Please make sure the latest configuration.xml(generated using DataMigrationUtility.exe tool) is generated and placed in the desired input location.
  • Please make sure we have updated the variables (correct connection string, CRM username, CRM password) in both the VSTS build and release definition.               

VSTS Build Definition

We have to create a separate Build Definition for moving the master data from source to target instance. Once the solution movement is done this below build definition should trigger.

In my previous blog, I have explained how to create a new build definition. Please refer to that for creating a new build definition.

What will do – It will connect to the source instance and export the master data using the configuration.xml and push it to artifacts repository

In this Build Definition we have used the following MSCRM Build Tools tasks:

  • MSCRM Tool Installer – Installs the Dynamics 365 tools required by all of the tasks
  • MSCRM Export config migration data – Exports data from a CRM instance using a Configuration Migration schema file (How to prepare configuration schema file).

You have to update the connection string variable name and select the configuration.xml input location.

  • Publish build artifacts – Publish build artifacts to Azure Pipelines

Release Definition

Once the above definition gets succeded, this Release Definition will trigger automatically and performs the following tasks:

  • MSCRM Tool Installer – Installs the Dynamics 365 tools required by all of the tasks
  • MSCRM Import config migration data – Import data exported using Configuration Migration Tool into a CRM instance

You have to update the connection string variable name and select the exported data zip from the artifacts repository(drop).

This will import the master data/configuration data into our Dynamics Online sandbox instance.

In my next blog, we will see how to integrate the unit testing framework with the VSTS Build definition.

If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.

CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS -Part 4 – Gated Check-in

In my previous blog, I wrote about how to set up a VSTS Release definition. In this blog, I am goint to explain the gated-check-in but before heading to it. We must know why we need gated check-in

Gated check-in helps to restrict developers from checking in a broken code into a source control system and thus helps to avoid blocking your team. With gated check-in when check-in is initiated by a developer, it will build the project and will check-in the code only if the build is successful. Gated check-in is suitable for projects whose overall build time is less than a few minutes.

C# we have used StyleCop and FxCop and for JavaScript and Jquery we have used JSHint

StyleCop for the custom code such as Plugins, Workflows, Actions, and WebApi.

Consider there is a group of developers working together and each one writes the code in the exact same way.

More often than not, one isn’t better than the other and it’s just a matter of taste. In a team or in a single project, it’s more important to be consistent than it is to choose the right style.

Agreeing on a style can be hard enough, but enforcing it shouldn’t be something you do manually. It will be tedious and error-prone.

StyleCop is a tool that can automate this. Let’s have a look at how to set it up.

What is StyleCop?

StyleCop analyzes C# source code to enforce a set of style and consistency rules.

StyleCop used to be a Visual Studio plugin and a NuGet package. You can still use this in Visual Studio 2019, 2017 etc.

Installing StyleCop

To add StyleCop to your project, right-click your project in Visual Studio’s Solution Explorer, and choose “Manage NuGet Packages?”:

Search for “StyleCop.Analyzers” and install the latest stable version:


Once it is installed, you build the project solution. You might get the below StyleCop warnings.

  • Add XML comments
  • Generate an XML documentation file (this can be set in the project properties)
  • Add a file header (e.g., copyright information)
  • Put the “using” statements inside the “namespace” block
  • Put braces on a new line
  • Add an empty line between the two method definitions (Output2 and Output3)


The first step in integrating StyleCop into an MSBuild system is to obtain the default StyleCop MSBuild targets file. To do so, run the StyleCop installer, and select the MSBuild files option on the Custom Setup page. This will install the StyleCop MSBuild files into the {Program Files}\MSBuild\StyleCop folder.

Adding the Import Tag

Once the StyleCop MSBuild files are installed, the next step is to import the StyleCop targets file into your C# projects. This is done by adding an Import tag to each C# project file.

For example, to integrate StyleCop to the project SampleProject, open the project file SampleProject.csproj within your favorite text editor. Scroll down to the bottom of the file and add a new tag to import the StyleCop.targets file. This import tag should be added just below the import of Microsoft.CSharp.targets:

<Project DefaultTargets=”Build” xmlns=”″&gt;   …Contents Removed…   <Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” />   <Import Project=”$(ProgramFiles)\MSBuild\StyleCop\v4.4\StyleCop.targets” />   …Contents Removed… </Project>          

Save the modified .csproj file. The next time you build this project either within Visual Studio or on the command line, StyleCop will run automatically against all of the C# source files within the project.

Build Warnings Vs Errors

By default, StyleCop violations will show up as build warnings. To turn StyleCop violations into build errors, the flag StyleCopTreatErrorsAsWarnings must be set to false. This flag can be set as an environment variable on the machine, or within the build environment command window. Setting the flag this way will cause StyleCop violations to appear as build errors automatically for all projects where StyleCop build integration is enabled.

Alternately, this flag can be set within the project file for a particular project. Open the .csproj file for your project again, and find the first PropertyGroup section within the file. Add a new tag to set the StyleCopTreatErrorsAsWarnings flag to false. For example:

<Project DefaultTargets=”Build” xmlns=”″&gt;   <PropertyGroup>     <Configuration Condition=” ‘$(Configuration)’ == ” “>Debug</Configuration>     <Platform Condition=” ‘$(Platform)’ == ” “>AnyCPU</Platform>     <ProductVersion>8.0.50727</ProductVersion>     <SchemaVersion>2.0</SchemaVersion>     <ProjectGuid>{4B4DB6AA-A021-4F95-92B7-B88B5B360228}</ProjectGuid>     <OutputType>WinExe</OutputType>     <AppDesignerFolder>Properties</AppDesignerFolder>     <RootNamespace>SampleProject</RootNamespace>     <AssemblyName>SampleProject</AssemblyName>     <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>   </PropertyGroup>            

The configuration described above will suffice to enable StyleCop build integration on an individual development machine. However, development teams working within a well-defined development environment can set up the build integration in a more global way, so that each developer does not have to manually install StyleCop on his machine.

To do this, copy all of the files from {Program Files}\MSBuild\StyleCop into a custom folder within your build environment, and check all of these files into your source control system. Next, define an environment variable within your development environment which points to the location of the StyleCop targets file. For example:

set StyleCopTargets=%enlistmentroot%\ExternalTools\StyleCop\v4.4\StyleCop.targets

With this configuration in place, it is simply a matter of adding the following import tag to each .csproj file within your development environment:

<Import Project=”$(MSBuildBinPath)\Microsoft.CSharp.targets” /> <Import Project=”$(StyleCopTargets)” />          

StyleCop will automatically run each time this project is built, no matter which developer is building the project. There is no need for each developer to install StyleCop manually, since the StyleCop binaries are checked directly into your source control system and are centrally integrated into your build environment.

What is CodeAnalysis?

To integrate Code Analysis in build, unload and edit project and add following tags. Note that paths might be different depending on Solution configuration.

    <CodeAnalysisDictionary Include="$(SolutionDir)\CodeAnalysisDictionary.xml" />
<Import Project="$(SolutionDir)\ExternalDlls\StyleCop 4.7\StyleCop.targets" /> 

Code Analysis configuration

Configure project Debug configuration to use Code Analysis rules in Solution root. Do the same for the Release configuration. Only difference is that in debug mode Code Analysis should not be run because it slows down the build. We keep CA running in Release to get error report from continues integration and to allow easily turning CA on by altering solution mode from Debug to Release.

Once the above step is done, please commit the project solution files in Azure DevOps/VSTS repository.

How to enable Gated Check-in VSTS build definition.

Go to Build definition -> Triggers-> you can see the gated check-in as follows:

Check the gated check-in checkbox. Now gated check-in is enabled for this particular build definition.

In my next blog, we will see how to move the master data from source to target instance using our CI/CD pipeline.

If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.

CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS – Part 2- Build Definition

In the previous post, I showed you how you can export and extract the solution from Dynamics 365 CE instance and commit to VSTS.

In this blog post, I will tell you how to create the VSTS build definition.

Dynamics CRM CICD process

The below diagram illustrates the basic flow of the Dynamics 365 CE Workflow process.

In this part, we are going to see how to create a build definition in VSTS.


Install Dynamics 365 Build Tools by Wael Hamze in VSTS

To set up your tooling there is only one thing to do. You need to install an extension from the Visual Studio Marketplace within VSTS. Go to this link to add this extension to your VSTS account. You need to be an administrator to do this.

Setting up the variables for the connection to CRM

You can create variable groups in VSTS. This is useful for variables who are related. You will use this to create a group for credentials for your development environment. Later if you implement the automated deployment, you can store the credentials to other environments there too.

In VSTS go to “Build and Release” and select “Library”. Here you can create variable groups.

Next click on ‘+ Variable Group’. This will take you to a form where you can create a variable group.

Now you give your variable group a name. For our demo purpose, I am giving the example as a Development environment. Next, add the below variables

Connection string – AuthType=$(AuthType);Username=$(Username);Password=$(Password);Url=$(Url)

URL- Enter your instance URL.

Username – Enter the username of your instance

Password – Enter the password of your instance

Authtype – Office365

Below is the sample connection string details for your reference

AuthType=Office365;; Password=passcode;Url=

Reference Link

VSTS Build Definition

Once the developer checks-in the changes into BuildAutomation.Solutions project we have a Build Definition in VSTS which will trigger automatically and perform the following steps:

In Build Pipeline, we will be packing the CRM solution and store the solution file in Artifacts. You can create a build definition directly from Visual Studio Online(VSTS/Azure-DevOps) or from within Visual Studio. Firstly, I will show you how to create a build definition from within Visual Studio, navigate to the Builds tab in the Team Explorer:

Once there, you can click New Build Definition to be taken directly to Visual Studio Online. This is where you would start if you had decided to create the build definition directly from Visual Studio Online instead of starting in Visual Studio.

On the dialog box that pops up in the browser, we’ll select Visual Studio as our build template, but you can see there are other templates for use, such as Xamarin for Android or iOS and the Universal Windows Platform. The default settings for your build definition should be correct for the most part, but you’ll need to check the Continuous Integration checkbox. Here’s what they look like for this example:

Because this is a simple example and we don’t need the additional flexibility the Default queue provides, we can leave the default Hosted option selected in the Default agent queue field. For more information on the restrictions on the Hosted pool.

You can see the checkbox for CI at the bottom of the dialog. This is enabled so that Visual Studio Online will execute the defined build definition for each check-in. The build definition will define whether or not this build code is published to an environment. Since we want to continually build and deploy to our web environment, we’ll check this box.

We can create the build definition from Azure Dev Ops too by following the below steps.

Navigate to Pipelines -> Builds -> Click New Pipeline


Click the Visual Designer, which will allow you to perform using GUI.

Select the Team Project, Repository, Branch and click on the continue button. For Demo purpose, I have given the name of the build definition as D365 CI


In the next step, Select an empty job as shown below:


After selecting an empty job, you can see the empty Agent Job and Select the Agent Pool as Hosted


Once the above step is done, we need to associate the variable group which we have created in the previous step to the build definition variables. In the “Variables” tab, you can set up the variables which are connected to this definition. The first part is the process variables. These are variables specific and available only to this build definition. Just leave the default variables like they are.

The other part is that you can link variable groups. Earlier in the blog, you set up your credentials as a variable group. Here you click link variable group and select your variable group to link it to this build definition. After linking you can use these variables like they are process variables.

If you ever add your own variables, make sure that a variable in the process variable and a variable in the linked group(s) don’t have the same name. This can lead to unpredictable results.

System.Debug process variable

A good fact to know is the use of the ‘system.debug’ variable. If you set this to true, then verbose logging will be enabled on all build tasks. If you are stuck on some error in the process, this may help to get more information. It will create a massive amount of logging.

Next step is we need to configure the VSTS build definition as shown in the below diagram.

  1. UseNuGet4.4.1 & Nuget restore – The NuGet tasks are required to process the NuGet package references in the
  2. Build Solution – Then we use the Visual Studio Build task to build the complete solution
  3. Copy files – The Copy task copies all files in **\bin\$(BuildConfiguration)\** to the $(Build.ArtifactStagingDirectory).
  4. MSCRM Tool Installer – We are using the MSCRM tool installer. It will install the necessary files (Installs the Dynamics 365 tools required by all the tasks).
  5. MSCRM Set Solution Version – Then we are setting the solution version in the source environment using MSCRM set solution version component.

Note: We need to provide the connection string in the below format to establish the connection with Dynamics 365 CE instance which we have created initially.

  • MSCRM Pack Solution task creates an Unmanaged and managed solution from the files in Solution/.. within that project and we output the Zip file in the respective folder of the project.  The Copy task copies all files in **\bin\$(BuildConfiguration)\** to the $(Build.ArtifactStagingDirectory), we then Publish the Artifact.

In the MSCRM Set Version task, we must specify the Build Number Format under Options in the Build Definition. Here is an example of my build number $(Build.BuildNumber).

In my next blog, we will see how to create the VSTS Release definition(It will pick the CRM solution from artifacts and deploy it in the Dynamics 365 CE target instance).

If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.

CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS – Part 1

In this blog series, we will explore building out DevOps processes and practices for Dynamics 365 Customer Engagement (CE) by utilizing Wael Hamez MSCRM Build tools. In this first blog, we will cover the version control for Solutions.

What is DevOps?

DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile infrastructure” or “agile operations”; it sprang from applying Agile and Lean approaches to operations work.  The second is a much-expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world (cf. Operations: The New Secret Sauce).

Problem Statement

I have started working on CI/CD when I was assigned as a Platform Engineer for a Dynamics 365 CE implementation project. At that time, I had a few key challenges with Dynamics 365 CE. I have listed those below:

  • Solution files were manually extracted and imported to target as a deployment process
  • No Unit testing or validation for deployed solution
  • Multiple deployment process is followed between release environments. For example, in Dev and Sit environment, the solution was migrated manually, and in UAT, Pre-Prod and Prod environment DB compare was applied to promote changes
  • Master data were mutually entered in each environment
  • Multiple developers working in the same organizations overwriting the changes.

Before we start solving the problem, let us take a moment to define some of the mandatory steps which we need to follow.

  • All the source code must be in source control. For example, Plugin Code, Custom workflows, actions, Warehouses (HTML, js, etc) Solution file, master Data, and user roles, etc.
  • Check-in regularly and every change should trigger the commit process
  • Commit process should be short and validates the committed component(Gated-Checkin)
  • Track changes and rollback as needed


Here is a little bit of information regarding the environment.  We are using Dynamics 365 (Online) v9.0 and VSTS/Azure DevOps for version control, build and deployment.  I am using Visual Studio 2017 with the Microsoft Dynamics CRM SDK Templates extension installed.

I have also installed the Dynamics 365 Build Tools(By Wael Hamze) into our VSTS Organization so the tasks are available for all Build and Release Definitions.

Version control for solutions

Solutions in Dynamics 365 CE are in essence a package containing any customization we’ve done to our environment that we can export from one environment then import into various environments. When exported from an environment, solutions are in the form of a zip file. When that zip file is unzipped, the output directory contains folders for plugins, web resources, and any workflows we have made as well as XML files defining the schema of any customization we have done. In the zipped format, our schema definition is contained in one massive file. Consider this zip file as a binary, or in layman’s terms, a tidy package with a fancy bow, i.e. It may look nice but it’s not easy to see what’s inside and it’s a poor format for version control.

Solution packager is a tool that essentially takes our Dynamics 365 CE solution zip file and breaks it out into a logical folder structure by decomposing the contents. The resulting output shows a more granular view of our solution and is considerably more friendly for version control as you can see from the example screenshots below.

Dynamics 365 Instance Management

Below are the little regarding how we have managed the dynamics 365 instances for achieving this DevOps.

  1. Dev environment: It is the true source for all the customization and configuration changes.
  2. SIT: where you test all the functionality against different types of data by internal test users.
  3. UAT: where you test all the functionality against different types of data by business users.
  4. Production: Go Live Instance.

Dynamics CRM CICD process

The below diagram illustrates the basic flow of Dynamics 365 CE Workflow process.

In this part, we are going to see the highlighted one in detail.

The process followed by the developer is essentially these steps (pictured below), the two steps in the middle are handled by the SolutionExportDev.cmd script:


It will export the solution from source instance and unpack the solutions into the folders in BuildAutomation.Solutions

  • Developers benefit using this process by making the solution deployment repeatable and predictable.
  • Developers can associate their work items with their check-ins
  • Very useful for tracking changes (traceability) and comparing solution files.
  • SolutionExport.ps1 – This will connect to the Dynamics 365 CE instance and export the Unmanaged and Managed solutions from that environment.
  • SolutionUnpack.cmd – This will extract the Unmanaged solution into the BuildAutomation.Solutions /BuildAutomation folder.  The Core Tools folder contains the Solution Packager tool from the Dynamics Core Tools NuGet package (pictured below)

Our solution consists of a CRM Deployment Packager project(BuildAutomation.SolutionPackager) and Solutions(BuildAutomation.Solutions) which is used as a container for the extracted files and folders of the solution. 

We added a Scripts(SolutionUnpack.cmd) folder to the project (BuildAutomation.SolutionPackager) which contains some below PowerShell scripts.

Powershell script for exporting the solution from the source environment.

$solutionName ="BuildAutomation"

Set-StrictMode -Version latest
function InstallRequiredModule{
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
$moduleName = “Microsoft.Xrm.Data.Powershell”
$moduleVersion = “2.7.2”
if (!(Get-Module -ListAvailable -Name $moduleName )) {
Write-host “Module Not found, installing now”
Install-Module -Name $moduleName -MinimumVersion $moduleVersion -Force
Write-host “Module Found”
function EstablishCRMConnection{
Write-Host "UserId: $CRMUserName Password: $CRMSecPasswd CrmUrl: $crmUrl"
$CRMSecPasswdString = ConvertTo-SecureString -String $CRMSecPasswd -AsPlainText -Force
write-host "Creating credentials"
$Credentials = New-Object System.Management.Automation.PSCredential ($CRMUserName, $CRMSecPasswdString)
write-host "Credentials object created"
write-host "Establishing crm connection next"
$crm = Connect-CrmOnline -Credential $Credentials -ServerUrl $CrmUrl
write-host "Crm connection established"
return $crm


#Update Source CRM instance details below:
Write-Host "going to create source connection"
$CrmSourceConnectionString = EstablishCRMConnection -user "$CRMSourceUserName" -secpasswd "$CRMSourcePassword" -crmUrl "$CRMSourceUrl"
Write-Host "source connection created"
Set-CrmConnectionTimeout -conn $CrmSourceConnectionString -TimeoutInSeconds 1000

Write-Host "going to create destination connection"
$CrmSourceDestinationString = EstablishCRMConnection -user "$CRMDestinationUserName" -secpasswd "$CRMDestinationPassword" -crmUrl "$CRMDestinationUrl"
Write-Host "destination connection created"
Set-CrmConnectionTimeout -conn $CrmSourceDestinationString -TimeoutInSeconds 1000

Write-Host "Publishing Customizations in source environment"
Publish-CrmAllCustomization -conn $CrmSourceConnectionString
Write-Host "Publishing Completed in source environment."

Write-Host "Exporting Solution"
Export-CrmSolution -conn $CrmSourceConnectionString -SolutionName "$solutionName" -SolutionFilePath "$SolutionFilePath" -SolutionZipFileName "$" 
Write-host "Solution Exported."
  1. $SolutionName – Name of the solution which you want to export the source instance.
  2. $SolutionFilePath – Desired folder path to export the solution
  3. $CRMSourceUserName – Username of the Dynamics 365 CE source instance
  4. $CRMDestinationUserName – Username of the Dynamics 365 CE destination instance
  5. $CRMDestinationPassword – Password of the Dynamics 365 CE destination instance
  6. $CRMDestinationPassword – Password of the Dynamics 365 CE source instance
  7. $CRMSourceUrl – URL of the Dynamics 365 CE source instance
  8. $CRMDestinationUrl – URL of the Dynamics 365 CE destination instance.

After updating the values in the above script, you can copy and paste in Windows PowerShell and run it. This will establish the connection to the Dynamics 365 CE source instance and export the solution to the $SolutionFilePath(Desired folder path to export the solution). Once this is done then run the below command file to extract the solution file.

Command Script:

rem @echo off
set solution=%1
set folder=%2

if "%solution%"=="" set solution=BuildAutomation
if "%folder%"=="" set folder=%solution%
if "%auth%"=="" set auth=ifd
set managed=false
set packagetype=unmanaged
set projectdir=BuildAutomation.Solutions

tools\solutionpackager.exe /action:Extract /packagetype:%packagetype% /zipfile:..\%projectdir%\%folder%\ /folder:..\%projectdir%\%folder%\ /allowDelete:No
exit /b

Developers need to do below the configuration in visual studio(Run the command prompt from inside Visual Studio) to execute the SolutionUnPack.cmd

To make the tool available, add it to the external tools list. Here are the steps:

  1. Open Visual Studio.
  2. Select the Tools menu, and then choose External Tools.
  • On the External Tools dialog box, choose the Add button. A new entry appears.
  • Enter a Title for your new menu item such as Command Prompt.
  • In the Command field, specify the file you want to launch, such as SolutionUnPack.cmd
  • In the Arguments field, please leave it as blank.
  • Choose a value for the Initial directory field, such as Project Directory.


Title – Name of the external tools to run

Command – Provide the physical path to the command file

Initial directory – Provide the directory path of the SolutionUnPack.cmd file.

Use Output Window – Enable

Prompt for Arguments ­– Disable

Close on exit–Enable

  • Choose the OK button.

The new menu item is added, and you can access the command prompt from the Tools menu as follows:

To run this, please click on ExportCrmSolution. It will export the solution from source instance and unpack the solutions into the folders in BuildAutomation. Solutions.

Once the above step is done, the developer now has some manual steps to perform depending on the files/changes that were extracted from the solution:

  1. Include any new file under the extracted folder Solutions\BuildAutomation (extracted) into the project- BuildAutomation. Solutions (so that they can be checked-in).
    NOTE: When doing the check-in, be sure to check the ‘Excluded Changes’ if additional files were detected and promote them to the ‘Included Changes’ as needed.
  2. For any .xaml file (under Solutions\BuildAutomation\Workflows or Solutions\BuildAutomation \Entities\xxxx\Formulas), make sure that Build Action is ‘None’ (not ‘Page’ or ‘XamlAppDef’). If this step is skipped, you may get one of this compilation error (s):
    – Project file must include the .NET Framework assembly ‘WindowsBase, PresentationCore, PresentationFramework’ in the reference list.
    – Assembly “System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ cannot be resolved”.
  • Ensure that DLL files under Solutions\..\PluginAssemblies are added to source control.
  • Undo all pending changes that do not specifically apply to your changes.
  • Associate the check-in with a work item(s), write a comment and check-in all required changes.

Note: Check-in to TFS will auto trigger the deployment process.

In my next blog, we will see how to pack the solution and deploy it in the Target instance using VSTS Build and Release definition.

If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.