Dynamics 365 Online vs. On-Premises

Dynamics 365 is available in two flavors, online and on-premises. The decision of which one is best for the solution is totally dependent on the organizational requirements. Some organizations highly value their customer and transaction data, and they have policies to safeguard the privacy of that data. In such scenarios, they will hesitate to put the data online and prefer to maintain an on-premises server farm to host the application. So, Dynamics 365 on-premises is the ideal solution for such organizations. The most notable drawback of the on-premises version is that updates are not released frequently compared to the online version.

The Dynamics 365 online version is regularly updated, and issues are fixed promptly. Additionally, since Microsoft has data centers on every continent, it guarantees the security of the data. Still, sometimes more traditional people will want to stay on-premise with their data. Even though this book is based on the Dynamics 365 online version, all the examples are compatible with the on-premise version as well.

Before commencing any development work, you must download the latest SDK. Needless to say, you will be needing the XrmToolBox as well. In the Dynamics 365 development world, XrmToolBox provides you with a wealth of plugins to develop and troubleshoot your work. Make sure that you have the latest version downloaded to your development environment.

Setting Up a Dynamics 365 Development Environment

Setting Up Visual Studio for Development

Make sure you download the latest SDK to your local folder. Currently, the SDK is no longer available through Microsoft, but you can use either NuGet or the following URL where David Yack has simplified the process: https://xrm.tools/SDK . Now that we have decided to use Dynamics 365 online and created the instances for development, the next step is to set up Visual Studio for the development work. When it comes to developing solutions for Dynamics 365, Visual Studio itself won’t be enough. You need some additional support or extensions. Primarily, two tools are essential for you to be a productive developer: Productivity Tools (see Figure 2-8) and Web Essentials (Figure 2-9). You can easily download and install them through Extensions and Updates of Visual Studio.

We all know that Dynamics 365 Toolkit and the Dynamics 365 Extensions are available, but still, they are not compatible with Visual Studio 2017 at the time of writing this book. There are workarounds to make them work with Visual Studio 2017, but this is not always successful. It is not essential to have them, and it is out of the scope of this book.

You will need Azure and Reporting projects as well, but they will be added to the solution later in the book. Now, you might be thinking about what might be the ideal design pattern to be used. For CRM projects, keeping it simple is best, so you will stick to the basics here. There is no harm in using a fancy design pattern, but for Dynamics 365 projects, keeping it simple is highly important.

So, when creating the Visual Studio solution, give a proper name to the solution. The most important thing is to select the correct project type. You are initially going to create a class library for plugins, so select the Class Library (.NET Framework) project type because .NET Standard and .NET Core are still not ready for CRM development. See Figure 2-10.

Once you click OK, the solution will be created. So, you need to add projects for workflows and web resources. The completed solution looks like Figure 2-11.

When creating the projects, make sure to select the .NET Framework 4.6; you are using the Dynamics 365 online version, and it requires the .NET Framework 4.6. Also, when creating the web resources project, create an empty ASP.NET Web Application (Framework) project. You will not compile this project; it is just a placeholder for the web resources.

You can loacte previous versions and the command to execute at https://www.nuget.org/packages/Microsoft.CrmSdk.CoreAssemblies/ .

Source Control

Now that the solution is created, it is time to discuss source control. This is extremely important no matter what solution you are developing. Therefore, you will also check in our example solution to Azure DevOps. You will be using the same project you have created for capturing the requirements.

1. 1.

   In your Azure DevOps project, create a folder under Code to store the artifacts. See Figure 2-12.

    

The solution will be checked into this folder. The purpose of creating this folder is to make it tidier. You can directly push all the solution artifacts to the root without creating any folder structure. See Figure 2-13.

1. 2.

   Now you need to connect to the project from Visual Studio. Open Visual Studio and open the Team Explorer. On the Home tab, click Manage Connections to add a new connection to the team project. See Figure 2-14.

    

Now you can see a small light blue padlock indicating that your solution has been checked in. See Figure 2-19.

Explaining Solutions

Fundamentally, a solution is a bucket that can be used to carry your customizations from one environment to another. There are three different types of solutions.

Default Solution

All the out-of-the-box customizations are included in the default solution. You can customize components here but cannot export them for distribution. Besides, it is always a best practice to leave the default solution as it is. You can view the default solution by navigating to Settings ➤ Customize the System (see Figure 2-20).

Managed vs. Unmanaged Solutions

When you are selecting between managed and unmanaged solutions, it all depends on how you want to release or distribute your customizations to target users.

If you are solving your software requirements in-house, then go for unmanaged solutions. Dynamics 365 solutions will be your baby, and you can create projects and hotfixes as solutions. Since you can create any number of unmanaged solutions, over time your production Dynamics 365 instance will end up in a huge pile of solutions, which will be a maintenance nightmare. Therefore, you should have some control over how you release your work. Your development environment may contain several solutions, but you must always have an integration environment where you can combine all the changes. Recently Microsoft introduced solution patches and solution upgrades, which removes most of the complexities related to solution deployment. We will be discussing this in detail in the next section.

Most of the time, the managed solutions are used by vendors to distribute solutions to their clients, and they do not want clients to modify the solution. It is like a piece of software that you would get from the market and install. Previously, managed solutions were locked for any changes. But now, by declaring managed properties, vendors can allow limited customizations. Also, when a managed solution is removed from your system, all the customizations that were in the managed solution will also be removed. This is similar to uninstalling a software component from your system.

Solution Patches and Upgrades

The solution patches enable you to release only the customizations done against a component, eliminating the risk of releasing unintended customizations to target environments. You can apply solution patches for both managed and unmanaged solutions. When creating patches, it should be based on the existing solutions. What does this mean? As a best practice, in addition to the default solution, you should create a base solution for your project. For instance, you can create a base solution that contains all the entities that are required for the project and both system and custom entities. You also can have the advanced customizations such as plugins and processes in one solution and web resources in another. Then you can create solution patches for the individual parent sollutions that you have created when changes are required.

When you decide to use this mechanism, you must start using version numbers consistently. The version of a patch will depend on the version of the parent solution. The format will be same as the solutions, which includes <major>.<minor>.<build>.<release>. See Figure 2-21.

The beauty of this is that it does not contain any of the noncustomized components or any of the related components. Unlike solutions, patches do not have a dependency on each other, meaning that you can easily remove a patch without impacting another one. Remember, when you uninstall a parent solution from the target environment, then the patches related to that solution will also be removed.

Let’s assume you are planning a big roll-out of your project, Phase 2. It should include all the patches that you have released after the last major release. Dynamics 365 provides you with the clone solution to meet this requirement. See Figure 2-22.

When you are cloning or upgrading, you must pay special attention to the version number because it only allows you to change the major and minor parts of the version. Once the cloning is completed, you can see that all the patches will be removed, and the parent solution will have the new version number. This indicates that the changes in the patches are combined with the parent solution. At this point, you can do the necessary customizations as well. For demonstration purposes, this book has used unmanaged solutions, but in the real world when cloning, the best practice is that the solution patches should be used only with managed solutions. See Figure 2-23.

The advantage of the solution upgrade is that when you import the solution to the target environment, Dynamics 365 automatically detects that this is an upgrade to an existing solution and notifies you. During the import process, you will be asked to import the solution as a “holding solution.” By default, this option is selected if there are patches for the parent solution that you are upgrading. This is extremely useful when removing unwanted customizations. The holding solution will retain customizations until removing the existing customization and applying the new upgrade. Microsoft has simplified this process, and needless to say, it works like a charm. We will be looking at this process in more detail later in this book.

Source Controlling the Customizations

So far, we have created a Visual Studio 2017 solution to hold all the plugins, custom workflow activities, and web resources. Now we are going to look at how to source control the customizations. For this, we will be using the Solution Packager tool provided by Microsoft, which is distributed as part of the Microsoft.CrmSdk.CoreTools NuGet package.

We need to come up with a proper solution to automate the repetitive work. For instance, we will be developing our solution and need to release it to a target environment. For simplicity, this book will use only two environments: Development and UAT. But you can have multiple environments or instances.

As shown in Figure 2-24, the release will begin in the development environment and go through the Azure DevOps release process. For the process shown, you will also need the Microsoft.Xrm.Data.PowerShell module. You can find more details about it at https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell .

The process is briefly explained in the following steps and will be explained in detail when we start the actual development work:

1. 1.

   The development work is done on the Dev instance. All the base solutions and patches are created as unmanaged solutions.

    
2. 2.

   Once the customizations are done, the Solution Packager will be executed to extract the solutions.

    
3. 3.

   You can then check in the extracted files to Azure DevOps. As you all know, it is not necessary to check in any DLLs. Besides, you already have the plugins and the workflows.

    
4. 4.

   Once that is done, you can start the build process and pack the solutions.

    
5. 5.

   As mentioned, we will be releasing the unmanaged version of the solution. You can use Azure DevOps release tooling or a third-party tool like Octopus to automate the releases. In your configuration, if you have multiple environments, you can use these systems to automate the releases.

    
6. 6.

   Also, there are other components such as Reports, Azure Logic Apps, and Azure WebJobs that we are planning to use, and the release mechanism will be different for them. We will discuss these when we add these components to the solution later in this book.

    

Why Is It Important to Automate Releases?

A few years ago, automating a release was a tedious task. At that time, automating Dynamics CRM releases was even more difficult. But now, both Dynamics 365 and release management software have been enhanced to a state where it can be done with minimum effort. The primary reason to automate releases is to eliminate the mistakes that people make when releasing. There is no point in wasting valuable time performing release activities manually over and over again. Besides, in Agile development environments, the releases are more frequent. In such scenarios, deployments must be automated.

Many release automation techniques can be used. SPKL Task Runner is a set of tools that can be used to automate deployment. You can find more details at https://github.com/scottdurow/SparkleXrm/wiki/spkl . Also, there is the Nullfactory Generator, which is a framework that is designed especially for Dynamics 365 projects. You can find more details at www.nullfactory.net/2018/06/generator-nullfactory-xrm-1-7-0-released/ . You also have the option to create your own process from scratch, and there are many resources to guide you.

In this book, we will be using SKPKL Task Runner to implement the build and release process. This was developed by Scott Durow, and it is a robust and well-tested set of tools. To begin with, let’s create the base solution.

Creating the Base Solution

You will be starting the application development process by creating the base solution. For the demonstration prposes of this book base solution will contain only the entities.

Add Entity Icons

Keep in mind that you need to upload two images in the sizes 16×16 and 32×32 to be used as both the icon for the entity and the icon for the form. After uploading the icons, you can map them to the entity. As mentioned earlier, this is for the web interface, but if you are using the Unified Interface, please follow the steps given in the reference shared in previous section.

1. 1.

   Navigate to an entity where you want to add the icon and click the Update Icon. As you can see in this window, you can upload two images. One is for the web application, and the other one is for the entity forms. As mentioned earlier, the web application icon must be 16×16, and for the entity forms the icon must be 32×32.

    
2. 2.
   When you click the lookup search button next to the field, you will see the topmost resources in the solution. If you cannot find your icon web resource there, then scroll down and click Lookup More Records, which will open the Lookup Search window where you can search and add your icons to the entity. See Figure 2-37.

   

    
3. 3.

   Keep in mind that you need to upload two images (a 16×16 version and a 32×32 version) to be used both for the entity and for the form. After uploading the icons, now you can map them to the entity. Navigate to an entity where you want to add the icon and click the Update Icon button, as shown in Figure 3-37. As you can see from this window, you can upload two images.

    
4. 4.
   When you click the Lookup Search button next to the field, you will see the topmost resources in the solution. If you cannot find you icon web resource there, then scroll down and click Lookup More Records, which will open the Lookup Search window where you can search and add your icons to the entity. See Figure 2-38.

   

    
5. 5.
   The next step is to create the relationships between the entities. Open the entity where you want to be set up the relationship and select 1:N Relationships. Since Member (Account) is a system entity, the relationship with other system entities like Contact is already set up. See Figure 2-39.

   

    
6. 6.

   When you click the New 1-to-Many Relationship button on the grid toolbar, a window to set up the relationship will be displayed. On this form, there are a few mandatory fields that you must enter before saving the relationship between the entities such as Related Entity, Display Name, Field Requirement, and so on.

    

These fields are categorized into four sections.

• Relationship Definition: This section lists the properties that describe the relationship.

• Lookup Field: This is the field that is displayed at the related entity.

• Navigation Pane Item for Primary Entity: This describes how the relationship is presented at the primary entity navigation.

• Relationship Behavior: In general terms, these are the settings that preserve the data integrity.

Once the fundamental properties are set, then you can set the others as per your requirements. In this example, we will be leaving the default settings as they are. See Figure 2-40.

Once all the relationships are set up, you can verify whether the relationships are correct. The best way is to compare your high-level ERD with a diagram created with Dynamics 365. Figure 2-41 was extracted from the XrmToolBox plugin Entity Relation Diagram Creator after creating the entities and setting up the required relationships with the newly created entities. You can find out more about the tool from https://www.xrmtoolbox.com/plugins/JourneyIntoCRM.XrmToolbox.ERDPlugin .

This is an easy to use tool. You first have to set up the connection to the Dynamics 365 instance via the XrmToolBox. Then on the tool, there is an option to load the entities. This will load all the entities including the custom entities in the system. You can select the entities in your base solution to make sure all the relationships are set up as per the initial design.

Installing SPKL Task Runner

Optionally, you could install a specific version by using -Version <version number> with the previous command. Once it’s installed successfully, a few components will be installed to the project, as shown in Figure 2-42.

You only have to execute the .bat files under the spkl folder to export and import your solutions. First, open spkl.json and change the solution_uniquename and packagetype attributes. solution_uniquename is the name of the solution, and the package type is set to managed since we are going to release a managed version of the package to the target environment.

The spkl.json file contains all the folder mappings and settings required to extract and pack the solutions. See Figure 2-43.

After setting these values, you can right-click the spkl folder of the SBMA.Solutions project and click the Open Command Line menu item. From the submenu, click Standard Command Prompt to open the command prompt from Visual Studio. From the list of .bat files under the spkl folder, enter the unpack.bat file to the command prompt and hit Enter. You will have to provide the following parameters to make the connection. The beauty of the SPKL Task Runner tool is that it remembers your credentials, so you do not have to enter them over and over again. In Figure 2-44, we will be selecting option [0] to enter the server details.

Once successfully connected with the server, the tool will display the available organizations, and it will ask you to select the organization, as shown in Figure 2-44. Then the tool will locate the solution on the server and download the solution components to the local folder. You can include the folder and check in the customizations. See Figure 2-45.

Now let’s deploy this to the target environment. For that, you will have to use the pack+import.bat command file from the spkl folder. Again, if your target environment is not in the tool’s memory, you can add it by selecting this option: [0] Add new server configuration. The process is the same as executing the unpack command.

When the command executes, you will get to see the progress of packing and importing, and when successfully imported, the command will also publish the solution at the target environment. Once successfully executed, you will be able to see your base solution at the target environment. See Figure 2-46.

Summary

With this, we end Chapter 2. In this chapter, you set up a development environment and dug deep into managed and unmanaged solutions. You also looked at the solution patching and upgrading. Lastly, the chapter discussed the release management approach suitable for the project. The book will demonstrate how to extend and improve the release process when the project get matures. From Chapter 3 onward, the book will guide you through how to customize Dynamics 365 with examples from the SBMA project.