Category Archives: Software Development

RegEx: string doesn’t start with

Recently I had to go through lots of files and find a string that does not start with semicolon ‘;‘ and ends with one of the words status, error or warning. Of course, regular expressions will help us here. Without further due, I would like to introduce RegEx:


Lots of time saved!

Visual Studio 2012: Project is missing TFS status icon

Recently I had an annoying issue: C# project checked-in into TFS was added to Visual Studio 2012 solution and was lacking TFS status icon in Solution Explorer:

Missing TFS Status

Missing TFS Status

Turns out the fix to this issue is very simple:

  1. In VS2012 Menu go to File > Source Control > Advanced > Change Source Control
  2. In Change Source Control window select project that was missing TFS Status icon, it has Not Controlled status

    Change Source Control

    Change Source Control

  3. Click Bind
  4. Save your solution and check it in into TFS.
  5. Done!


Managing Windows registry permissions with PowerShell

… is simple. But before jumping into code sample make sure to familiarize yourself with ObjectSecurity.SetAccessRuleProtection.

And here’s the PowerShell script code:

$acl = Get-Acl HKLM:\Software\Foobar\Product

# Disable inheritance for this key (true), remove inherited access rules (false):
$acl.SetAccessRuleProtection($true, $false)

# Remove all permissions for "NT AUTHORITY\SYSTEM":
$acl.Access | where {$_.IdentityReference.Value -eq "NT AUTHORITY\SYSTEM"} | %{$acl.RemoveAccessRule($_)}
Set-Acl HKLM:\Software\Foobar\Product $acl

# Set Read-only permissions for "NT AUTHORITY\SYSTEM":
$acl = Get-Acl HKLM:\Software\Foobar\Product
$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("NT AUTHORITY\SYSTEM","ReadPermissions","Allow")
Set-Acl HKLM:\Software\Foobar\Product $acl

# Now if you create subkey it will not inherit permissions from parent key:
$rootRegPath = Join-Path -path $rootRegPath -childPath SomeProduct
new-item -path $rootRegPath

FxCop: suppressing Web.config errors and warnings

Recently I had an issue where I had to suppress certain errors coming out of ASP.NET configuration files. Since Web.config isn’t a code per se we need to use global suppression file to suppress errors coming out of config file.

The real problem was that the issues where reported not in the project where the file Web.config is located but from a different project in solution:

d:\BuildTest\Any CPU\Release\DeploymentDrop\Web.config(27): warning : CA3114 : Microsoft.Security.Web.Configuration : Always
enable custom errors to return generic error information. Set mode attribute to “On” in unit MyProject file d:\BuildTest\Any CPU\Release\DeploymentDrop\Web.config line 14 column 4 [D:\PathInTFS\MyProject\MyProject.csproj]

The issue was solved by adding GlobalSuppressions.cs to MyProject where there issue was showing up (not where Web.config lives!):

// This file is used by Code Analysis to maintain SuppressMessage 
// attributes that are applied to this project.
// Project-level suppressions either have no target or are given 
// a specific target and scoped to a namespace, type, member, etc.
// To add a suppression to this file, right-click the message in the 
// Code Analysis results, point to "Suppress Message", and click 
// "In Suppression File".
// You do not need to add suppressions to this file manually.

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Security.Web.Configuration", "CA3114:SetCustomErrorsModeToOn")]

Note that SuppressMessage above will suppress all CA3114 messages in the project.

PowerShell: capturing output to log file and console

Recently I had to redirect full PowerShell session to both console and log file. Full means both stdout and stderr needs to be redirected. Working code is worth thousand words:


Stop-Transcript | out-null
$ErrorActionPreference = "Continue"

$OutputFileLocation = "C:\output.log"
Start-Transcript -path $OutputFileLocation -append

Write-Host "This will go into output.log"

# redirecting both STDOUT and STDERR (2>&1) to transcript:
robocopy.exe C:\ D:\ readme.txt 2>&1 | out-host



Line 11 deserves additional explanation. Due to a PowerShell bug 315875 output from native applications will not be captured. That being said, the workaround is to combine stdout and stderr and redirect it to a out-host.

The only remaining limitation is that stderr will be interpreted by PowerShell as error (and rightly so!) and thus printed out in red. While it is a little annoying, your output log doesn’t have colors 🙂


Move Fast and Break Things

When back in 2006 I started to work on UIQ 3.0 and Symbian OS 9.x, I was impressed with the architecture and design of Symbian. Coming from a fast-moving mobile app-development company to work on Operating System that was powering 80% of world’s smartphones at that time was an exciting challenge. What struck me first day that everything that UIQ and Symbian did they did in the right way. Everything you read in books and blogs, articles and white papers was applied at Symbian: Symbian OS was object-oriented from the ground up and had vast sophisticated hierarchy of classes with awesome documentation, development tools were mature and powerful, every aspect of software development process was also done in a right way – we used Agile/SCRUM, great source control system (Perforce) and bug tracking  software (Serena). Every feature was properly designed, reviewed, implemented and tested. When we fixed bugs – we looked at the spec and only then talked to PM/Architect. And yes, specs were actually up-to date (mostly). Every code check-in was core reviewed, had accompanying Unit Tests and automated testing suite was executed (STEAM). However, in early 2007 iPhone came out and it became clear that Symbian will soon become obsolete unless major changes will be done.


Copyright Alex Kolesnikov

So why did Symbian and UIQ failed during transition to capacitive multi-touch screens? As with any major disaster (think collapse of USSR) there are many reasons that lead to a quick demise, but I think the most obvious and biggest reason of failure in case of Symbian was that it could not embrace change fast enough. Going even further, I believe that the fact that Symbian engineers, architects and management were used to near-perfect release cycles and great engineering systems, they were all reluctant to embrace the change. Why would you change a great engineering infrastructure? Great engineering culture that was working so far? Being used to a predictable and solid engineering practices inhibited change.

Move fast and break things. Adopt or die. Adopt chaotic, hectic world of Web 2.0 and cloud, when you ship or rather launch every week. Symbian, good bye!