Setting up the Razor Generator for Visual Studio Application

Hi Champs,

Today I am going to explain how we can setup the Razor Generator to you Sitecore Visual Studio Project for Pre-Compiled MVC views. Below are the steps to configure this.

  1. Open your MVC solution in Visual Studio.
  2. Install the Razor Generator tool.
  3. Open Properties of your view (.cshtml file).
  4. Set the Custom Tool field value to RazorGenerator and press Enter. In this case, a .cs file with the source code should be created for a view.rezor
  5. Build your project and copy the assembly with precompiled views into the \bin folder of your Sitecore XP solution.

Happy Learning


Configuring Azure DevOp’s Release Pipeline for TDS

Hi Champs,

In this part, we are configuring the settings in the Release pipeline to deploy our Web Deploy package. Although the deployment can also perform as part of the build, we prefer separate steps for build and deployment to reduce the chance of accidental deployments to production environments.

The Release pipeline takes the build artifacts from the Build pipeline and installs them on the Sitecore instances that have been configured in Azure. There are a couple of ways we can do this. We can use the generated PowerShell Script, or we can use some of the built-in settings in Azure DevOps. The PowerShell script can be modified to work within complex build processes, but the deployment can be accomplished even without it.

Deploy to Azure using the built-in Azure DevOps settings

Azure DevOps comes with a built-in App Service deploy task, taking the Web Deploy package from the Build pipeline and installs it in the selected Web App. Keep in mind, there are a couple of important configuration settings here. We need to add the Azure subscription where the Web App is located and select it under the Azure subscription tab. This fills out automatically as part of the settings, and you’ll only need to select your subscription and App Service.

Window of Azure App Service Deploy

Deploy to Azure using the generated PowerShell Script

The second way of deploying the Web Deploy package to the Azure Web App is using the PowerShell script generated by TDS Classic. This can be useful in build servers where there’s no native support for Azure Web deploy, or when the user wants full control and use their release script. The script also gives you an easy-to-read log containing the item names and location in the Sitecore tree of the items.

To use it, we need the Publish profile file, which can be added in source control and made available for the Release pipeline the same way we made available the PowerShell script and the Web Deploy package.

We also need to create a PowerShell Script task in our Release pipeline. In it, we specify the path to the PowerShell script, generated by TDS and the arguments, required for executing it. The arguments are the same as the ones we used for deploying from our development machine.

WIndow of Powershell

Both ways of deploying will give you status about the deployment and a log with all the details. The logs are formatted a bit differently, so consider this when choosing which method to use.

Window showing logs


With TDS 5.8, we had the goal to simplify the deployment of the TDS project to Azure environments. Using Web Deploy packages, we were also able to reduce the deployment time while making the process more intuitive and visible for the developers.

Missed Part Two? Click here to read how to configure Azure DevOp’s Build Pipeline.

Need to start from the beginning? Click here to read how to set everything up locally.

Also do check my blog for automating slot swapping in Azure DevOps.

Happy Learning

Configuring Azure DevOp’s Build Pipeline for TDS

Hi Champs,

In part one, we set up our TDS project to create a Web Deploy package and published the package to an Azure App Service manually. Now that we know we can deploy our Web Deploy package from our local environment, let’s continue by setting up an automated build in Azure DevOps. In this part, we’ll configure only the steps in the Build Pipeline, and publish the build drop (a Web Deploy package and a PowerShell script) to the Release pipeline. Note that this is a simplified scenario to be used as a starting point. Your build/deployment process might be more complex and can include different steps than this one. 

Configure the Build Pipeline

For the build pipeline, we will build the project in the “Release” configuration being it is the configuration we set up for Web Deploy packages. The first step while creating your new Build pipeline is to select your repository settings. In this example, we will use Git.

Window to Select Repository

We also need to add the TDS license; otherwise, our build will fail. This happens in the Variables tab of your Build pipelines. The following variables should be created with your license info in the values.

As a starting template for our Build pipeline, we can use the Azure Web App for ASP.NET template. We don’t need all of the predefined build steps in the template for this example, so we will remove some of them. This is done to simplify the example and focus on the build process.

Window to choose a template

Our build will contain the following tasks in the Build pipeline:

Window of Build Pipeline

Summary of the Tasks

This summary explains each task and the most important thing we should configure:

Use NuGet
This task specifies the NuGet version the build server will use. We can leave it with the default settings.

NuGet restore
This task restores the NuGet package and also doesn’t require any special settings to be configured. 

Build solution
We will set the Build solution task to build the Release configuration. The Platform and the Configuration parameters are configured from the build variables. The default values are “Release” and “Any CPU” so we can use them directly.
Window to set Build Solution

Copy Files to
The next step copies the build output to the Staging directory, so it’s ready for publishing. We only need the PowerShell Script and the Web Deploy package from our build drop, so we will only copy them. Side Note: the paths might be different for your build. 

Window to Copy Files

Publish Artifacts
The final step in the Build pipeline is to publish the build artifacts to the next phase: the Release pipeline.

Window to publish the build artifacts

Once we have everything configured, we can run a test build. If everything is configured properly, we will see the Web Deploy package and the PowerShell script available in the Artifacts explorer in Azure DevOps.

Window of Artifacts Explorer


As shown above, setting up a build in Visual Studio online to create a Web Deploy package is relatively simple. The only real customization of the build was a step to pick up the files from the build folder and add them to the Artifacts folder. In the next part of the series, we will show you how to configure a release pipeline to deploy the Web Deploy package to an instance of Sitecore running on an Azure App Service.

Missed the first part? Click here to read Part 1.

Ready to continue to the next step? Click here to move on to Part 3.

Happy Learning

Setting Up TDS to Build Azure Repo

Hi Champs,

In next few blogs I going to explain you setting up TDS for entire Sitecore CI-CD process. Without any further delay we will start by below.

By using TDS 5.8 and Web Deploy packages, I’ll walk you through on how to create a fully automated build and deployment process from your workstation to source control and into your Azure environment.

The TDS Web Deploy packages were designed around quick and easy deployments to Azure, but they can be deployed to any Sitecore server that supports Web Deploy.

The difference in using .update packages and Web Deploy packages 

Workflow before TDS 5.8
Chart showing deployment before TDS 5.8

Workflow after TDS 5.8

Chart showing deployment process with TDS 5.8

Setting up the TDS project for Web Deploy

The Web Deploy Package tab has similar options to the Update package tab. You can enable building a Web Deploy package, what to include in the package, and the package name. In this example configuration, we’ll need a Web Deploy package, so we’ll check off “Build web deploy package.” The name can be left blank, and it will use the name of the project.

Window showing Web Deploy Package Tab

Since we are planning to build on the cloud based VSO build server, we need to add the TDS Build components NuGet package into the TDS project. To do this, you need to execute the following command in the Package Manager Console of Visual Studio. Side note: make sure you have selected the repository while executing this command.

Install-Package HedgehogDevelopment.TDS -Version

Building the Web Deploy package

To create the Web Deploy package, simply build the project/solution with the configuration where Web Deploy packages are enabled. When the build is finished, you will find a folder called [Configuration]_WebDeploy with the Web Deploy package and the Web Deploy PowerShell script.

Image showing Publish Web Deploy and TDS Project files

Please note: the PowerShell script provided by TDS isn’t the only way to install the package. It is provided as a convenience for the developer to help them deploy the package if they don’t have another method of deploying it. It also contains script that can be used to monitor the deployment on the server.

Testing the Web Deploy package

Once you have the Web Deploy package and the PowerShell script, you only need to specify where it should be deployed. This can be easily set using a Publish Profile from Azure or by using parameters to the PublishWebDeploy.ps1 script. You can get a publish profile from the control menu of the App Service in Azure.

control menu of App Service in Azure

Now you can make a test deployment to the Sitecore instance using the script. I placed my Publish Profile file in the same directory where the Web Deploy package and the script were generated.

If you want to deploy the Web Deploy package into your Azure instance, all you need is to execute the script using the following parameters:

PublishWebDeploy.ps1 -PackagePath -PublishSettingsPath tdstestinstance-630820-single.PublishSettings -ViewLogs


This completes the setup of the TDS project for building Web Deploy packages. Soon, I’ll walk you through on how to set up a TDS build in a Visual Studio Online Build Pipeline.

Ready to move on to the next step? Click here to read about configuring Azure DevOp’s Build Pipelines.
Happy Learning

Sitecore 9XP installation in details with Issues(xDB, Solr, Multiple instance)

Hi Champs,

Today I am going to share not just Sitecore 9XP installation but the issues which you might get while installing Sitecore 9 on your machine or on Servers.

I will not waste time on explaining how to install Sitecore 9 installation as you can find generic steps on below articles

Issues which you will face while installing Sitecore 9 are below.

Issue 1 : Solr Core are not getting created while installing

  1. You need to go to Service.msc
  2. Need to find the Solr service which got created while running mentioned PowerShell script.
  3. Now you need to stop the service again restart service check your Solr is running.
  4. You also need to check the Solr port number you mentioned in the script.
  5. Now run again the Script.

Issue 2 : SSL certificate issue

  1. While installing/running the above script you will find an error for Marketing automation service.
  2. Error is while executing the above script it tries to start Marketing automation service for xDB with unsigned/non-self signed SSL.
  3. But it is unable to find it from machine root.
  4. for which you need to run below PowerShell code one by one to get unsigned/non-self signed SSL in proper machine root.
  5. And now again restart the installation by PowerShell script. also please check below link for any other issues related to this.
Get-Childitem cert:\LocalMachine\root -Recurse | 
    Where-Object {$_.Issuer -ne $_.Subject}

If you get any certificates, Move these non-self-signed certificates into the Intermediate Certification Authorities (i.e. CA) store

Get-Childitem cert:\LocalMachine\root -Recurse | 
    Where-Object {$_.Issuer -ne $_.Subject} | 
    Move-Item -Destination Cert:\LocalMachine\CA

Issue 3 : Installing multiple Sitecore 9 instance on same machine.

While installing multiple Sitecore 9 instance you need to take care of below.

  1. First, you need to change all parameter name’s according to other instance from the mentioned script.
  2. Please make sure that you will create Solr service with a different name and a different port.
  3. Before starting installation make sure that you will need to stop all Sitecore services for the other instances which you already created.
  4. Check that you have given proper SQL parameters.
  5. Now start the execution of PowerShell script.
  6. Don’t forget to restart all the services which you stopped for other instances.

Issue 4 : After installation issues with xDB service.

  1. If you found that there are issues for xDB you need to go to services.msc.
  2. Go to the Marketing Automation service for respective Sitecore instance you may find that it is started but actually not working.
  3. In this case, you need to go to PowerShell and need to run above commands for non-self signed certificates.
  4. Then go to IIS.
  5. Go to the connect website and rearrange the SSL for xConnect website bindings.
  6. Once this is done then again start the service.

Thanks you for reading !

Please write comments and post your questions.

Razl for Sitecore Database Comparison

Hi Champs,

Today I am going to share experience about how to use Razl tool for comparing Sitecore Databases.

To Start with this you need to download Razl from below link, one major thing is to keep in mind that Razl is paid software so keep your Product Key details ready to enter after installation.

Once you install the Razl tool make sure that you restart your machine. After restarting your machine you need to follow the instruction given in below link to connect your database from different  Sitecore instances to compare. Basic think you need to take care is all instances of Sitecore should have proper configurations and instances should be running.

there is another way to connect and compare which is by a script which you can follow below.

Once you guys are able to open connection which you want to compare. You need to follow simple steps to compare and sync the databases.

  1. Open node one by one which has left or right or both arrow mark.  Razl1
  2. Check if you required those items to be moved or not.
  3. If you find a gold star on the top end of the node name, that means it’s the latest item, and if the representation is on the side where your updating then no need to change. (Still, check)
  4. Make sure that while updating or transferring the item right click on the node and select all children item to avoid the issues.
  5. Sometime Razl doesn’t pick the child items, then it that case please check every node and get the items updated.
  6. Razl is only trusted tool after Sitecore packages to move Sitecore items from one version instance to another version instance of Sitecore.
  7. Once your data is migrated by Razl from one Sitecore version instance to another Sitecore version instance you can sync database with your TDS project and share it with the team for development purpose.
  8. With Use of Sitecore TDS and Raz, you can migrate Sitecore databases easily and share within the team, I already migrated Databases from Sitecore 8.2 to 9.1.1 which is a success story.


  1. Razl is not free software
  2. If you find any issues you can connect to Razl support via Email– or you can write issues on below link.

Happy to Share

Please write your note or queries in a comment.

Thanks for Reading!!!