Useful Dev features in Visual Studio

Enable Code Lens:

Code lens is a very useful feature where the scroll button in the Visual Studio Editor is replaced by the Code Lens. It lets you take a peek into the part of code you mouse-over on the
Scroll-bar.
To enable it, go to Tools->Options and enable check-box as shown below:

You can also selectively set other code lens features as shown in the screen-shot above.

Splitter:

Above the Code Lens is the splitter as shown below. It lets you split your code-Editor screen into 2 parts when you click, hold and drag it as shown below:

The below screenshot is divided into two code-editors. On the above part, you can move around say do Ctrl+Home to go to the top of the file.

On the below part, do Ctrl+End to move to the bottom of the file.

Ctrl + M + O

This short-cut lets you collapse the entire code file as per regions.

Create #regions

Using #region and #endregion, you can divide your code-sections into collapsible regions in your .cs file.

Ctrl+;

This lets you quickly move to the search bar of your Solution Explorer and search for files in your Solution.

Navigate Forward and Backward

If you want to quickly navigate between current and previous cursor positions in same or different code files, you can do as follows:

Navigate backward: Ctrl + –
Navigate forward: Ctrl + Shift + –

The Navigation buttons are also available under the File Menu as shown:

Peek Definition

Now and then you need peek into the properties of a class. Just place your cursor on the class name and do Alt+F12 or right-click peek definition.

Set Project Build Order in Visual Studio

In order to set the Build order for your Solution, right-click on the Solution in Solution Explorer and Select Project Build Order:

Your Project Dependencies should be set correctly which is used to determine the Build order by Visual Studio.

The image below shows the Project references added in the Business layer to determine that the DTO and Persistence Projects should be built first before the Business layer Project.

The Project Build order will make sure the required dlls are available for the Api to compile correctly.

Now give your car batteries a good re-conditioning they need. Click here to know more.

Join Armoney for best Cryptocurrency trading experience. Trade from anywhere, anytime!

Update json value using Newtonsoft library C#

We recently had a scenario where we needed to update the empty json array key questions with items having certain json key-value pairs containing user information.

Sample below shows part of the json to be updated:

"screens": [
                {
                  "uid": "<guid>",
                  "body": {
                    "text": "...",
                    "questions": []
                  }
			  }
		  ]

After update:

"screens": [
                {
                  "uid": "<guid>",
                  "body": {
                    "text": "...",
                    "questions": [
                      {
                        "uid": "another guid",
                        "name": "1st name",
                        .... other items
                      },
                      {
                        "uid": "another guid",
                        "name": "2nd name",
                        .... other items
                      }
                    ]
                  }
		}
	]

Below is the sample code that first removes the empty questions array and then adds it back after filling in the User information:

foreach (JToken token in jScreenItem["body"].Children())
{
	JProperty p = token as JProperty;
	if (p != null && p.Name.Contains("questions"))
	{
		token.Remove();
		break; //breaking when empty questions array is removed.
	}
}
foreach (JToken token in jScreenItem["body"].Children())
{
	JProperty p = token as JProperty;
	if (p != null && p.Name.Contains("text"))
	{
		JProperty jquestions = new JProperty("questions", JArray.FromObject(jUsers));
		token.AddAfterSelf(jquestions);
		break; //breaking when filled questions array is added.
	}
}

jUsers above is an array of Objects containing user information.

Create Virtual directory in Visual Studio 2017 IIS Express

You may be facing a scenario where the Images folder of your Project is hosted in another directory on your machine e.g. C:\Data\Images and not under the Project directory structure. In this case, if you need to check whether the Images are loading correctly, you’ll need to create a Virtual directory in your Web application/MVC/WebAPI Project.

Follow the below steps:

1. Right-click on your Project properties and go to the Web tab and provide the URL for the required Virtual directory and click on the button Create Virtual directory. This option edits the ApplicationHost.config file.

2. Run the application and right-click on the IIS Express icon in the status-bar notification tray. Select your website and open the config file.

3. Look for the site tag and find your website and you’ll find the Virtual directory nested tag. Edit the path and physicalPath attribute to the folder on your machine as shown below:

<site name="MyApi" id="2">                 
<application path="/" applicationPool="Clr4IntegratedAppPool">
<virtualDirectory path="/" physicalPath="C:\MyApi" />                 
</application>                 
<application path="/uploads" applicationPool="Clr4IntegratedAppPool">                     
<virtualDirectory path="/" physicalPath="C:\Data\Images\uploads" />                 
</application>                 
<bindings>                     
<binding protocol="http" bindingInformation="*:62216:localhost" />                 
</bindings>             
</site>

After making these changes, refresh the app to view the images in your app via localhost.

To know how to create a Virtual Directory in IIS for a website, check this post.

Show some love for the pit in my PayPal account.

Take care of your health. Click here to know more.

Join Armoney for best Cryptocurrency trading experience. Trade from anywhere, anytime!

Continuous Deployment execute database scripts with TFS

In another post, we’ve learned how we can use a Build definition and Release Management in a CI/CD pipeline. Please go through the articles if you need more information on these topics.

In this post, I’ll explain how we can use Release Definition to execute database scripts as part of the continuous deployment strategy. We will add a task to execute PowerShell script to achieve this.

Create Release definition

The task to be added is PowerShell under Utility. This task should be added before the Application files are deployed in the CD pipeline.

Create a Release definition for your Release pipeline as shown below, the path for the PowerShell script should be a shared path and the database Server is accessible.

Add the below code snippet to the PowerShell script. The script should be modified as per the requirement.

$localScriptRoot = "C:\Scripts"
$Server = "dbserver"
$scripts = Get-ChildItem $localScriptRoot | Where-Object {$_.Extension -eq ".sql"} | Sort-Object -Property Name
$qt = 0
foreach ($s in $scripts)
    {
        Write-Host "Running Script : " $s.Name -BackgroundColor DarkGreen -ForegroundColor White
        $script = $s.FullName	
        Invoke-Sqlcmd -ServerInstance $Server -InputFile $script -username "TFSBuildUser" -password "****" -querytimeout $qt
    }
Write-Verbose "scripts executed successfully" -verbose

The scripts to be executed are present at the location C:\Scripts with extension “.sql”. The password can be also passed as an argument to the PowerShell script and added to the Release Definition secret variable.

Use the Triggers tab to link to the required Build definition of your Project so that the Release definition is integrated with the Build pipeline. The linking can also be done using the Artifacts tab.

You can setup multiple environments using this strategy like Dev, POC and Production.

Build Web Application with TFS

The msbuild capability of TFS 2015 or 2017 agent helps build a Web Application using MSBuild Arguments. The Visual Studio Build task is required to pass the msbuild arguments along with the path of the solution file to build.

Fill the msbuild arguments with:

/p:DeployOnBuild=true /p:PublishProfile=<PublishProfileName>

Make sure the Publish profile is checked-in. It is an xml file which is used to save the Publish settings for a Project which includes the Path to Publish and the Deployment mode which can be Debug/Release. This file is found under the Profiles folder of the Project. Also, make sure in your Build Publish Profile, the option Precompile during publishing is checked.

BuildStep1

You can also use the following MSBuild arguments to Publish the Web Application build into the directory as specified in the publishUrl argument as below:

/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\Deployment\$(BuildConfiguration)

The artifactstagingdirectory is the “a” folder on the Agent for the Project Collection Id under which the Project is built. This is where the files are copied after the Project is built from the Source “s” folder.

BuildConfiguration variable under the General Tab contains Debug/Release.

e.g. C:\TFSAgent\agent\_work\<Id>\a\bin\Deployment\Release\

If the MSBuild arguments are not specified, the artifacts folder will not contain only the code files and not the build files. Save the Build definition and queue the build to view the results.

I’ve written another post on Creating Build Definition here. Another way that might work for you is a post about Publishing WebAPI or MVC application here.

Pre-build versioning with PowerShell script and TFS Build

There are a lot of scenarios where the PowerShell script requires to be run as a Build task in your Build definition. In of the cases, we had a requirement to change version attribute in the AssemblyInfo.cs files in all Projects of our solution. The version number required to be in the format “1.0.0.”. This version number should be visible in the exe properties after installation.

To achieve this, I created a PowerShell script, which recursively found all the AssemblyInfo.cs files in all Projects, checking for the Attribute pattern and replace it.

Create a PowerShell script file in the ISE and copy the following code:

Define the Params:

Param
(
[Parameter(Mandatory=$true)]
[string]$productVersion
)

$YYYY = (Get-Date).year
$SrcPath = $env:BUILD_SOURCESDIRECTORY

$AllVersionFiles = Get-ChildItem $SrcPath AssemblyInfo.cs -recurse
$versions = $productVersion.Split('.')
$major = $versions[0]
$minor = $versions[1]
$patch = $versions[2]
$build = $versions[3]

$assemblyVersion = "$major.$minor.$patch.$build"
$assemblyFileVersion = "$major.$minor.$patch.$build"
$assemblyInformationalVersion = "$major.$minor.$patch.$build"

Replace the Assembly attributes:

foreach ($file in $AllVersionFiles)
{

(Get-Content $file.FullName) |
%{$_ -replace 'AssemblyDescription\(""\)', "AssemblyDescription(""assembly built by TFS Build $productVersion"")" } |
%{$_ -replace 'AssemblyVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyVersion(""$assemblyVersion"")" } |
%{$_ -replace 'AssemblyFileVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyFileVersion(""$assemblyFileVersion"")" } |
%{$_ -replace 'AssemblyInformationalVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', "AssemblyInformationalVersion(""$assemblyInformationalVersion"")" } |
Set-Content $file.FullName -Force

}

The script requires to following parameters which requires to be passed in the Build task:

PSVersion1

The code should be checked in to TFS and mapped to a local folder from the Repository tab so it can be downloaded on to the Agent machine locally.

PSVersion12

This PowerShell build step should be the first step in your Build definition before the Visual Studio Build task so that the version changes can take place as soon as the code is fetched on the TFS Agent work folder.

Tip: Make sure your AssemblyInfo.cs files has the above attributes which you’re replacing with the PS Script in the specified format else some dlls may miss out on the updated versions.

Change Password for TFS Build Service Account

The TFS Agent for 2015 or 2017 versions is a Windows Server machine that hosts the Service that allows to run Build and Release definitions for your code as part of the DevOps Process. It can run as a Windows Service and can be found by the name VSO Agent in the Services Snap-in. It uses a domain account to run the Windows Service which can be seen under the LogOn properties of the Service.

It runs VSOAgent.exe behind the scenes which is kept in the Agent folder configured for that TFS Agent e.g.

C:\TFSAgent\agent\Agent\VSOAgent.exe

If at any point you require to change the Windows Service account details that was configured earlier due to may be a password change, the following command may help you.

Please note that Password should not be changed from the Services Snap-in as it may cause the Agent Service to break.

  1. Open Command Prompt in Administrator mode.
  2. CD to the directory e.g. as mentioned above C:\TFSAgent\agent\ . Make sure you’re one level above the folder where the VSOAgent.exe is placed else it’ll give error.
  3. Run the following command: .\Agent\VSOAgent.exe /ChangePassword
  4. Fill in the new Credentials as Prompted.
  5. Restart the Service VSO Agent from the Services Snap-in.

The Agent should now be running with the new Service account.

Release Management with TFS

Release Management is a service in VSTS Azure pipelines and TFS on-premise and an essential element of DevOps that helps you continuously deliver software. We can fully automate the testing and delivery of your software in multiple environments all the way to production, or set up semi-automated processes with approvals and on-demand deployments.

CI Build

Release definition defines the end-to-end release process for an application to be deployed across various environments.

You define the release process using environments, and restrict deployments into or out of an environment using approvals. You define the automation in each environment using phases and tasks. You use variables to generalize your automation and triggers to control when the deployments should be kicked off automatically.

You can create a deployment model on the basis of how you manually deliver the builds using build definition for different environments.

The below Release Definition shows different steps using PowerShell scripts that are modeled basis the manual process created for deployment.

Release definition

 

Creating a Release definition

Configure your environment:

  • Give the environment a meaningful name by clicking into the Default Environment name provided and enter one of your own e.g. DEV, QA, PRODUCTION.
  • Click on the ellipsis next to the environment name and select Deployment conditions…

rd1

 

Deployment Conditions

rd2

This is where we set up how we want our deployment to be triggered. It is here that we define what triggers the deployment of our release.

  • No automated deployment– deployment of the build artifacts will need to be undertaken manually with no automation
  • After release creation– this will deploy the build artifacts to the specified environment every time a new release is created i.e. Continuous Delivery.
  • After successful deployment on another environment– this will deploy the build artefacts to an environment after they have been deployed to another environment e.g. after every successful deployment to the STAGING environment deploy the build artefacts immediately to the QA environment

Use the first option if you are deploying to a production environment i.e. make the deployments to your production environment a manual exercise. Use the second option if you are deploying to a development testing environment as part of a Continuous Delivery pipeline. Use the last option if you want to push your deployments between different testing environments.

Approvals

You may setup Approvals before the deployment to a particular environment using the Approvals Tab.

rd3

 

Configure a Queue and set demands

The demands may be System defined like “DotNetFramework” or you can set yourself like selecting Agent name.

rd4

 

General Tab

rd5

 

After configuring your environment, the next step would be to add task(s) which will be invoked when we want to deploy our build artifacts to the specified environment. The deployment task is the action that we want to happen when we invoke a deployment e.g. running a PowerShell script to start/stop App Pool, running database scripts, deploy the build on to a Virtual Machine or Azure instance.

Create Release

Create Release and select the build for which you would like to create a release in Dev environment and click on Create as shown below:

rd6

The successful build selected above will trigger the Automated Deployments based on the selections made for each environment.

Create build definition with TFS 2015 or newer

What is build definition?

A build definition is a representation of the automation process that you want to run to build and test your application. The automation process is defined as a collection of tasks. VSTS and TFS have a number of tasks to build and test your application. A build definition describes the details of what your build is supposed to do, and when it’s supposed to do it.

Build and Release are two of the DevOps services in VSTS and TFS that help you manage continuous integration and delivery of your applications.

Visual Studio Team Services (VSTS) and Team Foundation Server (TFS) provide a highly customizable continuous integration (CI) process to automatically build your Web, Mobile or Desktop application whenever your team pushes or checks in code. You can also Schedule builds on a specific date or time, recurring builds or manually queue a build.

You can add build tasks for .Net, Java, Node, Android, C++, xcode applications. Similarly, there are tasks to run tests using a number of testing frameworks and services. You can also run command line, PowerShell or shell scripts in your automation pipeline.

A basic build definition consists of 3 steps or build tasks which can be used with the Visual Studio template (this template requires Visual Studio be installed on the build agent):

  1. Visual Studio Build: This step builds the solution in the $(build.sourcesdirectory). This is the Source directory with the letter “s” under the Agent’s work folder. TFS gets all the files under this directory and builds the application under the bin folder. Provide the path to the solution that requires to be built. In case you need to build a web application, fill the msbuild arguments with: /p:DeployOnBuild=true /p:PublishProfile=<name of Publish profile>. Make sure the Publish profile is checked-in.BuildStep1
  2. Copy Files: This step copies the files from the source directory described above to the Artifacts Staging directory $(build.artifactstagindirectory) with the letter “a” under the Agent’s work folder. The Files Published for the Web Application can be found under bin\$(BuildConfiguration)\Publish folder.BuildStep3
  3. Publish Build Artifacts: This step Publishes the artifacts in step 2 to the Shared folder for which Network share path requires to be provided. Appropriate permissions are required on the folder to the same user that is running the Build Agent Service on the Agent machine. You can Publish the files copied in step 2 from the Publish folder above to the Network share path for continuous delivery pipeline. BuildStep4
Repository Tab

This tab lets you specify the Mappings under the Source “s” folder on the Agent machine as to how it should manage the downloaded source files locally. You can map each Server paths with a local path e.g. one Server path may be mapped to Application files and other Server path may contain PowerShell scripts which may need to be run in a different build task.

General Tab

This tab specifies some of the required demands that are defined as capabilities on the Agent machine like:

  • msbuild
  • visualstudio
  • vstest etc.

You can specify additional demands like choosing a specific agent by adding a demand as “Agent.Name”.

The Build Number format specifies the name of the folder under which queued build will be placed.

Variables Tab

This tab holds some predefined system variables and link to the entire list of it. You can also add your own variables which can be used in the build definition.

Triggers Tab

Specify whether to schedule the build, build with each check-in or with gated check-ins.

Retention Tab

Lets you specify the duration until which you’d like to keep the queued build.

History Tab

Shows the log of any changes made to the Build definition by which users and when.