Monday, August 15, 2016

Get IP address by MAC address in C#

Sometimes it happens that you need to access device in the network by IP address. But unfortunately, it is not every time possible, e.g the device does not have static IP. In such case you can use device's MAC address to find it in the network.

Address Resolution Protocol 

Displays and modifies entries in the Address Resolution Protocol (ARP) cache, which contains one or more tables that are used to store IP addresses and their resolved Ethernet or Token Ring physical addresses. There is a separate table for each Ethernet or Token Ring network adapter installed on your computer.
So we are going to use following arp-command to get all the entries and filter them by specified MAC address.

arp -a

For more option use following link ARP Documentation.

.NET implementation


ArpEntity.cs


namespace ArpExample
{
    public class ArpEntity
    {
        public string Ip { get; set; }

        public string MacAddress { get; set; }

        public string Type { get; set; }
    }
}

ArpHelper.cs


using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text.RegularExpressions;

namespace ArpExample
{
    public class ArpHelper
    {
        public List<ArpEntity> GetArpResult()
        {
            var p = Process.Start(new ProcessStartInfo("arp", "-a")
            {
                CreateNoWindow = true,
                UseShellExecute = false,
                RedirectStandardOutput = true
            });

            var output = p?.StandardOutput.ReadToEnd();
            p?.Close();

            return ParseArpResult(output);
        }

        private List<ArpEntity> ParseArpResult(string output)
        {
            var lines = output.Split('\n').Where(l => !string.IsNullOrWhiteSpace(l));

            var result =
                (from line in lines
                 select Regex.Split(line, @"\s+")
                    .Where(i => !string.IsNullOrWhiteSpace(i)).ToList()
                    into items
                 where items.Count == 3
                 select new ArpEntity()
                 {
                     Ip = items[0],
                     MacAddress = items[1],
                     Type = items[2]
                 });

            return result.ToList();
        }
    }
}

IpFinder.cs


using System.Collections.Generic;
using System.Linq;
using System.Text.RegularExpressions;

namespace ArpExample
{
    public class IpFinder
    {
        public string FindIpAddressByMacAddress(string macAddress)
        {
            List<ArpEntity> arpEntities = new ArpHelper().GetArpResult();

            return arpEntities.FirstOrDefault(a => a.MacAddress == macAddress)?.Ip;
        }
    }
}

Troubleshooting 

Recently I figured out that the solution described in the article sometimes might fail. I wrote the article with the fix. Please find it using the link Get IP address by MAC address in C#. Updating ARP table

Sunday, August 14, 2016

Source code beautifier / Syntax Highlighter Using PrismJs for Blogger

Preparing this post I created simple syntax highlighter using prismjs http://prismjs.com/. Please find below some instructions how to use it.
Steps:

  1. Copy code to 'Source code' text field
  2. Select language
  3. Select theme
  4. Check 'Include style' checkbox. If you have already added some highlighted code to you blog page, you might uncheck 'Include style' checkbox to prevent css-styles duplication on your page.
  5. Click 'Transform' button
  6. Copy and paste generated code to your blog page. 

Source code
Highlighted code
Select language:
Select theme:
Include style:

QA: Estimation Techniques

There is bunch of techniques which can be used to estimate QA work.

  • Industry averages, metrics, predictive models. Usually it is 30% of development work, but this is the most tricky estimates, for example developers changed store procedure this is approximately 5-8hrs of work for developer, so QA will be 1.5-2.5hrs. For QA this could mean to do full regression of application because this store procedure is using across application.
  • Tester-developer ratio. This technique usually based on organization history. For example 4 developers generate work for 1 QA engineers, so QA time will be 0.25 of full development work.
  • Experience (intuition, guess) based estimate. 
  • Team estimation sessions. Estimates can be more accurate estimates when dev lead and BA participate in estimation sessions, more details can be provided and took into account.
  • Test case based technique. This estimates can be used only when test cases created, or you can guess how many test cases you will create.
  • Bottom-up approach of estimates. Work is breaking down on tasks, each task can be estimated individually and sum of tasks will be overall project estimates.
In addition to provided techniques add additional time for bugs creation and verification, for updating test case, and 30% of estimated time add as risks. Usually when QA starts estimate functionality no one know how this functionality will behave at the result. Better way to overestimate and use less time, than underestimate and use much more time of testing under pressure and not founded bugs.


Saturday, December 5, 2015

StyleCop integration for .NET projects

Why it is important?

Coding conventions serve the following purposes:
  • They create a consistent look to the code, so that readers can focus on content, not layout.
  • They enable readers to understand the code more quickly by making assumptions based on previous experience.
  • They facilitate copying, changing, and maintaining the code.
  • They demonstrate C# best practices.

Code style recommendations

As the reference for your coding conventions, please use Microsoft guidelines (https://msdn.microsoft.com/en-us/library/ff926074.aspx).  If they will conflict with this document, please use rules from the document.

Naming convention 


EntityPattern
Types and namespacesUpperCamelCase
InterfacesIUpperCamelCase
Type parametersTUpperCamelCase
Methods, properties and eventsUpperCamelCase
Local variableslowerCamelCase
Local constantslowerCamelCase
ParameterslowerCamelCase
Fields (not private)UpperCamelCase
Instance fields (private)_lowerCamelCase
Static fields (private)_lowerCamelCase
Constants fields (not private)UpperCamelCase
Constants fields (private)UpperCamelCase
Static read-only (not private)UpperCamelCase
Static read-only (private)UpperCamelCase
Enum membersUpperCamelCase
All other entities UpperCamelCase

Try to give names for entities without any abbreviations. Name should describe entity’s purposes. 

Using statement


1. Please put “using statement” outside of namespace.
using System;  
using System.Text;  
using System.Web.Mvc; 
 
namespace SampleProject.Controllers  
{  
}
2. System usings should be placed first, then all others
3. Usings should be sorted alphabetically.

Return statement 

1. Please separate return statement from other code with single empty line.
public ActionResult DashBoard()  
{  
    DoSomething();

    return View();  
}  

Curved brackets

1. Curved brackets should be places for “foreach”, “if”, “for”, “while”, etc. all the time.
if (someVal)  
{  
   DoSomething();  
}  

How to implement rules if you are at the beginning of the project?

We assume that all team members should follow the code guidelines without any exceptions. So, know we have to think how we can achieve that statement. In general, all the cases will lead you to the following two cases.
  1. Rely on people
  2. Rely on tools
What does it mean to “Rely on people”? By this phrase, we assume that all team members will be responsible for following code style rules. There are some procs and cons of this approach. Although it is easy to start using it, there are some disadvantages of such approach. Among them – additional time for code style review and non-strict control of following the rules by all team members.
In such situation, tools can help the team to follow code style guidelines. Therefore, in this article, we will look at StyleCop tool (https://stylecop.codeplex.com/).

StyleCop

Installation

To install StyleCop on your machine you need to download installer from the https://stylecop.codeplex.com/ and run. Alternatively, you can open “Extensions and Updates” window in Visual Studio and install any appropriate extension, e.g. “Visual StyleCop”.

Create settings file

To create StyleCop settings file just right click on project and select “StyleCop settings”.
Select rules you want to follow and click “Apply”. After that, Settings.StyleCop file will appear in project folder.To download settings file click on following link Settings.StyleCop.


Enable StyleCop on build

1. Open NuGet Package Manager for project you would like to validate.
2. Search for “StyleCop.MSBuild” package and install it.



3. Create file with rules, which are acceptable for your team. 
4. Import that file to the project.


5. Build the project. As the result, you will see warning in “Error List” window.


Just described behavior is kind of soft behavior, because code compiled and application would work. To fix such situation you can do following things:
  • In project’s properties change “Treat warning as errors” property
  • Install “StyleCop.Error.MSBuild” NuGet package

After implementation all the steps above, you can be sure that everyone will follow the code style rules.

How to start using styling rules if you already have “billion” files?

It is no secret that majority projects does not have styling standards and we have to live with it. Let’s think how we can improve such situation. 

Assumptions:
  • At the begging do not allow to fail build on style settings validation
  • After some period build should fail on code styling issue
I would like to recommend following steps to rewrite all code according style standard:
  1. Create styling rules for your project and introduce Settings.StyleCop  with them
  2. Install on each developer’s machine StyleCop or another appropriate tool
  3. Create milestones with percentage of cleaned files
  4. Ask developers to change code according style rules in files, which they working on during current iteration
  5. Allocate time for code style fixes as technical debt
  6. Track progress
  7. Start failing build on style issues

Approximate roadmap for code style changes

Step 1

The step's approximate time frame is 0 - 6 week. During step 1 team concentrates on following:
  1. All team members have installed StyleCop tool on their machines
  2. While working on some area teammates do code style refactoring
  3. While code review first step to run StyleCop against created rules
  4. Team will concentrate on “main” libraries
  5. Team will allocate time for style fixes as part of technical debt stories

Step 2

The step's approximate time frame is  6 - 12 week. During step 2 team concentrates on following:
  1. We will enable code style checks on build. “StyleCop.MSBuild” package will be installed to libraries we would like to validate
  2. Code style warnings will appear
  3. Steps 1, 2, 3, 5 from first row
  4. Libraries coverage increased
  5. We will track number of style warnings

Step 3

The step's approximate time frame is  from 12 week. During step 3 team concentrates on following:
  1. Warnings replaced with build failures. By this moment, we assume that all files will have appropriate style. 
    1. In project’s properties change “Treat warning as errors” property
    2. Install “StyleCop.Error.MSBuild” NuGet package
  2. Deprecate style review on code review sessions

FAQ

How to apply settings for solution?

It is easy when you have only one file with rules and all projects in solution have reference to that file. StyleCop allow us to do that. Put file with rules in the root folder of the project. Then add to each projects’ folder Settings.StyleCop file with following lines.

<StyleCopSettings Version="105">  
  <GlobalSettings>  
   <StringProperty Name="LinkedSettingsFile">..\Settings.StyleCop</StringProperty>  
   <StringProperty Name="MergeSettingsFiles">Linked</StringProperty>  
  </GlobalSettings>  
</StyleCopSettings>  

LinkedSettingsFile – path to the main settings file.

How can I extend existing rules?

First, you can try to find some already written rule extensions. E.g. StyleCop+ (StyleCop+ is a plug-in that extends original StyleCop features. It offers you a variety of rules for building C# code style that best suits your needs.) (https://stylecopplus.codeplex.com/)
Second, you can write your own rule. 


Saturday, October 25, 2014

Интеграция OpenCover в .NET проект.

Что такое OpenCover?

OpenCover - это инструмент с открытым кодом, который показывает разработчикам .NET приложений на сколько существующий исходный код покрыт unit-тестами. Ссылка на официальный сайт - https://github.com/sawilde/opencover.

Интеграция OpenCover

Для того, чтобы интегрировать OpenCover в проек, для начала необходимо установить:
  1. NUnit.Runners
  2. OpenCover
  3. ReportGenerator
Данную процедуру можно сделать при помощь Library Package Manager (NuGet). Сперва необходимо добавить поддержку востановления NuGet-packages для .sln-файла проекта.


Далее переходим в панель управление NuGet-packages.


В поле для поиска вводим поочередно название NuGet-package и устанавливаем его. В итоге в .nuget папке должен появиться файл packages.config с содержимым:

<?xml version="1.0" encoding="utf-8"?>
<packages>
    <package id="NUnit.Runners" version="2.6.3" />  
    <package id="OpenCover" version="4.5.3207" />  
    <package id="ReportGenerator" version="2.0.0.0" />
</packages>

Файл packages.config не появляется в файле проекта после добавления указанных выше NuGet-packages, поэтому можно добавить его руками.

Тестовой проект, в который мы интегорируем OpenCover, имеет следующую структуру:


Так как OpenCover не может сгенерировать coverage-отчет без unit-test runner, необходимо создать .bat файл, который выполнит все наши тесты (RunTests.bat). Содержимое RunTests.bat:

..\..\..\..\packages\NUnit.Runners.2.6.3\tools\nunit-console.exe OpenCoverSample.Core.UnitTests.dll /noshadow

После того, как мы научились выполнять unit-тесты, мы можем построить coverage-отчет. Для этого создадим RunOpenCover.bat файл со следующим содержимым:

..\..\..\..\packages\OpenCover.4.5.3207\OpenCover.Console.exe -target:RunTests.bat -register:user -filter:"+[OpenCoverSample*]* -[OpenCoverSample.Core.UnitTests]*"

..\..\..\..\packages\ReportGenerator.2.0.0.0\reportgenerator.exe -reports:results.xml -targetdir:coverag

.\coverag\index.htm

Так как мы не хотим, чтобы в coverage-отчет входили сборки с unit-тестами, мы добавили фильт, который будет игнорировать их.

Для файлов RunOpenCover.bat и RunTests.bat атрибуту Copy to Output Directory ставим значение "Copy always".

Далее добавим ссылку на проект с unit-тестами в проект OpenCoverSample .CoverageReportGenerator.

В OpenCoverSample.CoverageReportGenerator Program.cs добавляем код, который будет генерировать отчет:

namespace OpenCoverSample.CoverageReportGenerator
{
  class Program
  {
    static void Main(string[] args)
    {
      var process = new System.Diagnostics.Process();
               var startInfo = new System.Diagnostics.ProcessStartInfo
      {
        WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden,
        FileName = "RunOpenCover.bat",
        RedirectStandardOutput = true,
        UseShellExecute = false
               };
      
      process.StartInfo = startInfo;
      process.OutputDataReceived += (sender, a) => Console.WriteLine(a.Data);

      process.Start();
             process.BeginOutputReadLine();
             process.WaitForExit();
          }
  }
}

Компилируем приложение OpenCoverSample.CoverageReportGenerator и запускаем. В результате получаем coverage-отчет:

Файл с тестовым проектом, можно скачать по ссылке OpenCoverSample.zip