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:

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.

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.

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.