Category Archives: .NET

.NET, visual studio team services

Visual Studio Team Services = Git/TFS + JIRA + Team City + Octopus

Leave a comment 
Warning: The content of this post is highly opinionated. Please exercise caution. :)

A bit of Background

Back in 2012-13, the term Dev-Ops was unheard of in my team. We were still living in dark ages where a developer would developed the code, then write unit test cases more to get the code coverage look good than to actually “test” the code. The code would then go through a review and queued for check-in. Some magic which the developer never really cared about would then tell us if the code was successfully checked-in or it failed. That magic was TFS XAML  build. The build was managed by a dedicated team and we never felt it was part of development process. After the end of sprint iteration a huge code base would then go to the test team and they would start testing the code based on their test cases and log bugs to the dev team. More often than not a developer would talk to tester only during that phase. This resulted in 100s of bugs in a big team. Few of these bugs would be invalid due lack of understanding of requirements, few others would be basic bugs which should have been handled by the developer in the first place. All the requirements, tasks, bugs, issues etc were logged in TFS. But, there was no dashboard. So, every developer and dev lead had to be expert in excel to track the items more effectively. It is said Ignorance is bliss, and same was true for us. We were happy in our shell, delivering code in this fashion and never felt need of change.

During the similar time-frame, I got an opportunity to work in a customer location. This is when I got a rude shock. The customer used tools which I had not heard before. They used confluence to collaborate, JIRA to track work items, Team City for build and a source control that was not TFS :). Suddenly, I realized that development was more than just writing code. I fell in love with these tools immediately. I realized there is more in the world than TFS.

However, there was still one big pain point with all these tools and application. We were using just too many tools and plugins – TortotiseSVN, JIRA, Team City, some other tool for deployment etc. Each one of these tools looked different and they worked differently.

Visual Studio Team Services

Microsoft was late to join the party and TFS was surely lagging the features that Agile projects and modern development practices demand. In 2013, Microsoft introduced Visual Studio Online (VSO). At the time of launch VSO appeared to be nothing more than TFS on cloud. However, Microsoft started adding more and more features to VSO. Many of these features were “inspired” from competitive tools. Over a period of time, VSO was aptly renamed to Visual Studio Team Services (VSTS). Today, VSTS has become one stop for all our development.

VSTS has solved one big problem of fragmentation. Its features today are on-par if not more with JIRA, Team City and Octupus.  With VSTS as a user you do not need multiple accounts,  your single account will give you access to everything you need for software development. Additionally, VSTS now offers full support for more and more non-Microsoft services. That means, you are first class citizen irrespective of your editor, source control (TFVC,  Git) and technology. If you do not want to use VSTS for everything, you still have a choice to choose what you want. For example, you can choose Octopus over VSTS Release Management and push package from VSTS build to Octopus directly. It works seamlessly.

To know more about features of VSTS go here. What tools do you use for your development?

Advertisements
.NET, Visual Studio, Visual Studio 2017

Visual Studio 2017 – The best IDE ever

1 Comment

Visual Studio 2017 was launched with much fan fare yesterday (March 7, 2017). I started exploring Visual Studio 2017 from RC and I must say, after using VS 2017 I felt I was earlier leaving in stone age. It is so much better.

In short the Visual Studio 2017 is equivalent to following:

VS 2017 = VS 2015 + Loads of 3rd party plugins (like NChrunch, few ReSharper features etc.) + Improved tooling, performance, experience, productivity etc.

Below, I have tried to highlight major features in Visual Studio 2017. This is not an exhaustive list but only few features which has helped me to improve my productivity significantly.

Faster Installation – Choose your workload

The first thing that you will notice while starting Visual Studio is that you got to chose what you want. Are you just a web developer? No worries, you only install just web workload. In fact, you can even chose what individual component you want to install within that workload. That means, lesser space, faster install time.

01-VS Installer
Visual Studio 2017 installer

Faster Load Time – Increase Productivity

One of the major pain-points with previous version of VS was that it used to taken an eternity to load a solution with lot of projects. You could actually launch your VS go for coffee, come back and it would still be loading. But, VS 2017 actually loads these project very fast. So, you no longer need to go to coffee, just open the project and start coding and leave home early 🙂

From my own experience, my solution contained around 92 projects. Opening them in Visual Studio 2015 could take anywhere between 2 to 3 minutes or even more. Sometimes, it would hang and I would need to start all over again. Worst still, if you had ReSharper installed like me, I could go for lunch along with coffee and come back before it loads.

 

VS 2015 - Preparing solution1
VS 2015 – Preparing Solution (You can go for a coffee)

With VS 2017, the same solution opens in less than 30 seconds. No more coffee breaks!

C# 7.0 Support

Visual Studio 2017 comes with C# 7.0. C# 7.0 has introduce lot of new features like Tuples, Switch Case improvements, Pattern Matching, Local Functions, etc.

// Example of tuple feature of C# 7.0
public (int sum, int difference) GetSumAndDiffernce(int a, int b)
{
       return (a + b, a - b);
}

You can get more details on C# 7.0 here.

Live Unit Testing

If you have used NChrunch, probably you would know what I’m talking about. Visual Studio 2017 brings in the support for live unit testing. VS 2017 runs unit test cases in background as you write your code. It means you simply write code and you will get an instant feedback on what unit test cases are failing or passing due to your change. Ideal for TDD. Makes your smarter and increase your productivity.

To enable Live Unit Testing in your solution go to Test -> Live Unit Testing -> Start

03-Live Unit Testing
Start Live Unit Testing
06-Live Unit test Example
Example of Live Unit Testing
Important Note: If you are using a .NET Core project. Then you are out of your luck. .NET Core does not support Live Unit Testing currently.
You will get following error in output window:
"Live Unit Testing does not yet support .NET Core"

Improvements in .NET Core Tooling

Back in VS 2015 days, .NET Core tooling was still in preview. If you were early adopters of .NET Core you would know what a pain it was. With VS 2017 the tooling has come out of preview and moved to 1.0. In addition to this you have MS Build support.

Once, you open an existing .NET Core project written in Visual Studio 2015 is “One-way upgrade” dialog as shown below. On clicking OK it will migrate your existing VS project to a newer version automatically.

02-Project Upgrade1.PNG
.NET Core One-way upgrade

Why this upgrade? This is because, VS 2017 no longer supports project.json and xproj. It is replaced by csproj. The csproj itself is no longer complicated as earlier. You can edit csproj file and add/ remove references without unloading the project. The csproj file also supports intellisense.

05-Edit CSProj.PNG
Simplified csproj file with intellisense 

 

Docker Support

Vs 2017 supports containers out of the box. While creating a new project you get an option to enable Docker Support.

04-Enable Docker
Enable Docker Support
Important Note: Before you enable Docker Support in your project, make sure you have Docker installed in your machine. 

Else, your build will fail with error: "Microsoft.DotNet.Docker.CommandLineClientException: Unable to run 'docker-compose'. Verify that Docker for Windows is installed and running locally."

If you do not have the tools, you can enable Docker support later as well.

There are many other features which I have not listed down here. For the complete list please refer to VS 2017 release notes.

Happy Coding!!!

.NET, async/await, C#, Task Parallel Library

async await best practices

1 Comment

aysnc await is probably one of the most important features of C#. It has made the life of developers easy. It helps developers to write clean code without any callbacks which are messy and difficult to understand.

However, if used in incorrectly async await it can cause havoc. It can lead to performance issues, deadlocks which are hard to debug. I have burnt hands due to incorrect use of  async await in the past and based on my little experience I can tell these issues will make your life hell, you will start questioning your very existence on this earth or why you chose to be a developer 🙂

I have tried to add common pitfalls while using async await  below. These are some of my learnings while working on problems that arise due to incorrect use of async await Much of these is inspired from Stephen Cleary blogs and Lucian Wischik six essential tips for Async channel 9 videos.

Here are tips:

  • AVOID using Task.Result or Task.Wait(). They make the calls synchronous and block async code.
  • Make your calls async all the way.
  • USE `Task.Delay` instead of `Thread.Sleep`
  • Understand the difference between CPU bound and IO bound operation before using Task Parallel Library or TPL
  • USE Task.Run or Parallel.ForEach for CPU bound operation.
  • USE await for IO bound operation.
  • USE ConfigureAwait(false)on the web APIs or library code. On the WPF application do not use ConfigureAwait(false) at the top level methods.
  • AVOID using `Task.Factory.StartNew`. Use Task.Run
  • DO NOT expose a synchronous method as asynchronous or visa vesra. In other words your library method should expose the true nature of method.
  • DO NOT use async void other than top level Events. ALWAYS return async Task

I hope these tips help few of you and help avoid common mistakes. Please suggest any other tips in the comments section.

.NET, C#, csproj, Project, Visual Studio

Clean Visual Studio Solution

Leave a comment

Today, every project we work on big or small, easy or complex, small team or large team  is probably on Source Control. The source control of course can be git, VSTS, SVN etc.

Still, there are times where you need to share your code as zip in an email, or shared link. It could be because your customer, colleague or partner do not have access to your source control or simply you have not added your code to Source Control itself.

Now, if you just zip the solution folder and email or share the link then you would include folders like bin, obj, packages or files like .sou, .user etc. These files are not required to build the solution. These files increase your zip file size significantly. The solution is simple, delete all the files which are not required. However, what if you have over 50 projects in the solution? And what if you have to this activity multiple times? It is too much of manual effort to do perform this activity.

I had a similar issue in my one of  my engagements recently.  However, instead of spending hours to do this manual work, I decided to automate the process by creating a small console app. The app deletes all the unwanted folders and files recursively from the solution. I have included following folders and files as per my requirements as the part of  deletion list:

Folders:  bin, obj, TestResults, packages
Files:  "*.vssscc", "*.ncrunchproject", "*.user", "*.suo"

Source code has been shared in GitHub here.

Alternatively, You can also download the executable directly from here.

Hope it helps some you to save your time and be more productive. Please do provide your comments and feedback.

.NET, C#, HttpClient, Visual Studio

Dispose HttpClient or have a static instance?

Leave a comment

Recently, I came across this blog post from ASP.NET Monsters which talks about correct using HttpClient.

The post talks about issues of related to disposing HttpClient object for each request. As per the post calling HttpClient method can lead to issues.

using (var httpClient = new HttpClient())
{
    await httpClient.GetAsync(new Uri("http://bing.net"));
}

I have been using the HttpClient object like this for almost all of my projects. Hence, this post was an eye opener for me.

Also, as per the patterns and practices documentation:

In a web application this technique is not scalable. Each user request results in the creation of a new HttpClient object. Under a heavy load, the web server can exhaust the number of sockets available resulting in SocketException errors.

From above two articles I could conclude, below are the major issues with disposing the HttpClient object for each request:

  • The execution time of the HttpClient request is higher. This is obvious since we create and dispose the object every time for a new request.
  • Disposing HttpClient object every time could potentially lead to SocketException. This is because disposing the HttpClient object does not really close TCP connection. Quoting from the ASP.NET monster post:

..the application has exited and yet there are still a bunch of these connections open to the Azure machine which hosts the ASP.NET Monsters website. They are in the TIME_WAIT state which means that the connection has been closed on one side (ours) but we’re still waiting to see if any additional packets come in on it because they might have been delayed on the network somewhere

I wanted to test the performance improvements when we create a static instance of HttpClient. The aim of my test was ONLY to see the difference of execution time between the two approaches when we open multiple connections. To test this, I wrote following code:


namespace HttpClientTest
{
   using System;
   using System.Net.Http;

   class Program
   {
      private static readonly int _connections = 1000;
      private static readonly HttpClient _httpClient = new HttpClient();

      private static void Main()
      {
         TestHttpClientWithStaticInstance();
         TestHttpClientWithUsing();
      }

      private static void TestHttpClientWithUsing()
      {
         try
         {
             for (var i = 0; i < _connections; i++)
             {
                using (var httpClient = new HttpClient())
                {
                   var result = httpClient.GetAsync(new Uri("http://bing.com")).Result;}
                }
}
}
         catch (Exception exception)
         {
             Console.WriteLine(exception);
         }
      }

     private static void TestHttpClientWithStaticInstance()
     {
         try
         {
             for (var i = 0; i < _connections; i++)
             {
                  var result = _httpClient.GetAsync(new Uri("http://bing.com")).Result;
             }
         }
         catch (Exception exception)
         {
             Console.WriteLine(exception);
         }
}
}

 

For testing:

  • I ran the code with 10, 100, 1000 and 1000 connections.
  • Ran each test 3 times to find out the average
  • Executed ONLY one method at a time

My machine configuration was:

machineconfiguration
System Configuration

Below are the results from the Visual Studio Instrumentation Profiling:

Method No Of Connections Time in Seconds Difference in Seconds Performance Improvement in %
TestHttpClientWithUsing 10 2.6
TestHttpClientWithStaticInstance 1.8 1 44
TestHttpClientWithUsing 100 408
TestHttpClientWithStaticInstance 240 168 70
TestHttpClientWithUsing 1000 241
TestHttpClientWithStaticInstance 160 81 51
TestHttpClientWithUsing 10000 2456
TestHttpClientWithStaticInstance 1630 826 51

As you can see the time of execution for the static instance is far lesser than disposable object.

Does it means we should use static client object all the time? It depends.

One of the issues people have found with static HttpClient Instance is that it does not support DNS changes. Refer this article. For .NET application, there is a workaround available where you can you can set connnectonLeaseTimeOut by using ServicePoint object as mentioned in post.

However, for an ASP.NET Core, you may be out of luck as per this issue in GitHub as similar property does not seem to exist.

Hope this post help you take informed decision in your projects. Please share your thoughts in comments section.