Page 2 of 4

Powershell CmdLets

Powershell is a powerful language and can be used in several situations.
One of these situations is the deployment process (continuous delivery). It is also integrated in several systems, f.e. NuGet. NuGet uses powershell for post package installation processing.

I use powershell for the following cases (in continuous delivery):

  •  Replace/rename config files
  • Replace variables in config files
  • Call/Post to webservices
  • Run SQL commands

Note: External Modules need to be imported for calling webservices and running SQL commands. This can be done by calling the Import-Module CmdLet.

Powershell can be used as scripting language, but you can also create CmdLets. These commands can be invoked from the command line in the powershell environment.


A CmdLet is a command which can be called from the powershell command line.

Cmdlets are created by inheriting your class from Cmdlet.
This is available in the System.Management.Automation namespace.

CmdLets use the Verb-Noun naming convention. The Verb and Noun are provided as argument in the CmdLet attribute which decorates your CmdLet class.
The VerbsCommunications class comes with the following fields:

  • Connect
  • Disconnect
  • Read
  • Receive
  • Send
  • Write

You are not restricted to these Verbs, you can also use custom Verbs.

The ProcessRecord method is called. The method is called for every item in the pipeline.

[Cmdlet(VerbsCommunications.Send, "Greeting")]
public class SendGreetingCommand : Cmdlet
	public string Name { get; set; }

	protected override void ProcessRecord() 
	      WriteObject("Hello " + name + "!");

This CmdLet example can be called from powershell command line as follows:

Send-Greeting –Name "Vincent" // Outputs: Hello Vincent!

Command line arguments are automatically bound to properties which are decorated with the Parameter attribute. Parameters are mandatory when the Mandatory argument of Parameters are set to true.

Maybe it’s interesting to know that the package manager console in Visual Studio also uses powershell and commands like Add-Migration and Update-Database are all CmdLets.

So if you haven’t given powershell a try, you really should!

Out Of Memory Exceptions when using Images in Android

I haven’t talked about my app for a while. The development was going quite well. When the learning phase of working with android was decreasing, the development effort decreased and I started to embrace the android development framework and its lifecycle.
The functionality of my app increased rapidly, with tons of new features and the look and feel got better and better and better (thanks to!)

That’s when random crashes of my app start to occur at random moments in the app.
The debugger couldn’t help me at all and all I got was this exception message:

 Out of memory: Heap Size=49159KB, Allocated=40884KB, Limit=49152KB

I couldn’t really figure out why, I did use some memory by drawing some images, but it wasn’t huge.
So I googled it and it seems to be a common problem. A lot of people run in to these Memory issues.

The garbage collector collects all elements which are not used. Unfortunately, the views have a callback, this is why the garbage collector cannot detect that they aren’t used anymore.

I found some code which unbinds all views and their descendants. I tweaked it a bit and rewrote it for c#.

protected void UnbindDrawables(View view)
   if (view == null) { return; }

  if (view.Background != null)
      view.Background.Callback = null;
  if (view is ViewGroup)
       for (int i = 0; i < ((ViewGroup)view).ChildCount; i++)
       if (!(view is AdapterView))

Now that we’ve got this method, we can call it in the OnDestroy of an Activity.
In this example, I use my LayoutContainer view, which is my outer wrapper view which contains all views of the current layout. Feel free to use your own view id, but make sure the images you want to unbind are in this view.

protected override void OnDestroy()


When I implemented this in all activities (perhaps consider a BaseActivity), the memory issues were gone and I have not seen them since.
A lot of people suggest to add android:largeHeap=”true” to your manifest file so your app can use more heap size. I don’t consider that as a good solution. You should try to keep your application clean and only use the memory you really need. Just clean everything up as you’re supposed to.

Dumping objects to string for logging purposes in c#

Logging is very important and in many cases not given as much attention as it deserves.
When connecting to external datasources, logging becomes crucial.
Whenever data provided by an external source is not as expected, you would like to know what went wrong.

When objects are dumped to the log, a common use is to override the ToString method

    public class Phone
        public Guid Id { get; set; }

        public string Brand { get; set; }

        public override string ToString()
            return string.Format("Phone with ID {0} and Brand {1}", Id, Brand);

This works fine for objects with not a lot of properties.
When the object becomes complex, overriding the ToString method becomes unclear and a lot of work.
Instead, we want to see the data of the entire object without having to do lots of work for this.
Let’s create an interface for dumping objects to string, which we can use for logging purposes.

public interface IObjectDumper
    string WriteToString(object objectToDump);

Objects can be dumped in several formats. You can pick whatever format you prefer, think of json, xml, ….
I prefer json. I think it is an easy to understand and readable format.
Asp.Net has its own json serializer (JavaScriptSerializer), but I prefer the one from Newtonsoft Json (this package can be downloaded from NuGet):

public class JsonObjectDumper : IObjectDumper
   public string WriteToString(object objectToDump)
       return JsonConvert.SerializeObject(objectToDump, Formatting.Indented);

The Formatting.Indented makes sure the output is indented.
Dumping a phone object looks as follows:

  "Id": "d768bbc4-a1d5-441f-ae14-ebb5bef92b41",
  "Brand": "Google"

Using the object dumper with logging would look something like this:

    public class PhoneRepository : IPhoneRepository
        private readonly IObjectDumper _objectDumper;
        private readonly IConnector _connter;
        private readonly IPhonesParser _phonesParser;
        public PhoneRepository(IObjectDumper objectDumper, IConnector connector, IPhonesParser phoneParser)
            _objectDumper = objectDumper;

        public IEnumerable<Phone> GetPhones()
            var phones = new List<Phone>();
                var result = _connector.GetPhones();
                phones = _phonesParser.Parse(result);
            catch (ParseException e)
                Logging.Error(string.Format("Error parsing result for GetPhones with data: {0}", _objectDumper.WriteToString(result)), e);
            catch (Exception e)
                Logging.Error("Error retrieving data for GetPhones.", e);
            return phones;

Value objects and operator overloading in c#

Value objects are small objects which are not equal by ref, but by value. They do not have an identity. Comparison of two objects is based on a value, not all values in the Value object have to be equal.

Another attribute of a Value object is that it is immutable.

An example of a Value object is a price.

public class Price
    private readonly double _value;
    public Price(double value)
        _value = value;

    public double Value {
        get { return _value; }

This is a simple value object which holds one property, Value. This Value property holds the actual price.
The value is set by the constructor and stored in a readonly variable. This makes it immutable.

When validation is required, this can be added to the constructor. When a not valid value is provided as argument, an exception should be thrown. It is the objects responsibility to make sure it is valid. A best practice is to throw custom exceptions, f.e. when a negative value is provided, an InvalidPriceException could be thrown. This specific exception can be caught on a higher level which knows how to handle these exceptions.

Comparing two Price objects with the same value but a different ref, will result in false.
It can only be compared by value by using the Value property. This means that we have to understand how the Price value object works in order to compare it. This is not a best practice. It is the responsibility of the value object to determine if it is equal to another value object of the same type.
This is when operator overloading comes to the rescue! Operator overloading allows us to override the default implementation of the operators used on the value object.

Lets start with implementing comparison.

public static bool operator ==(Price x, Price y) 
    if ((object)x == null || (object)y == null)
        return false;
    return x.Value == y.Value;
public static bool operator !=(Price x, Price y)
    return !(x == y);

When implementing the == operator, you are required to implement the != operator.
Do not forget to override the Equals method. By default, this method compares objects by ref. It should return the same result as the == and != operators.

public override bool Equals(System.Object obj)
    Price p = obj as Price;
    if ((object)p == null)
        return false;
    return Value == p.Value;

public override int GetHashCode()
    return Value.GetHashCode();

Now that we can compare Prices, the next step is to have some simple math functions like adding, subtracting, multiplying and dividing. The math operations is also the responsibility of the value object.

public static Price operator +(Price x, Price y)
    return new Price(x.Value + y.Value);

public static Price operator -(Price x, Price y)
    return new Price(x.Value - y.Value);

Remember to return a new instance of your object. This will prevent strange side effects when objects are set to null and the ref is destroyed.
Operator overloading is not limited to the currenty type, it can be implemented for any type. For multiply and divide a double is used.

public static Price operator *(Price x, double y)
    return new Price(x.Value * y);

public static Price operator /(Price x, double y)
    return new Price(x.Value / y);

These are some very simple math operations on a Price value object. The key point is that the value object itself is responsible for handling all the operations.
Although this is very basic, it is a perfect scenario for some unit tests.

Add msbuild parameters for NuGet to the TFS build process template

NuGet packages can be a great artifact of a build and it can easily be integrated in your build process.
Make sure the NuGet targets file is imported in the projects which should generate a NuGet package. Please read my previous post about NuGet to see how you can integrate NuGet in your solution.
By default, NuGet registers itself in a project file as follows:

<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

The targets file contain a BuildPackage target which can be triggered by setting an msbuild parameter named BuildPackage to true.
Now we need to create a property in the Build  template which sets the BuildPackage parameter in the msbuild command in the build template.

Open Visual Studio and open the Team Explorer window. Click on Builds to display your TFS Builds. When you right click on a Build, you can select “Edit Build definitions”. This will bring up the edit screen for the selected Build.
Now click on the “Process” tab. This will display which Build template is associated with the Build and what the parameters are.

Click the “show details” icon in the top right corner to see the template.
The template is a Windows WorkFlow Foundation (WWF) template.  The xaml file is an xml based file which creates workflows in applications.
Edit the .xaml build process template in an xml editor, I prefer notepad++.
Find <x:Members> and add the following (do not remove any existing child elements):

   <x:Property Name="NuGet_BuildPackage" Type="InArgument(x:Boolean)" />

Now that we’ve added the properties, we can add them to a section.
Find the <this:Process.Metadata> element and add the following items (and again, do not delete any existing child elements):

    <mtbw:ProcessParameterMetadata BrowsableWhen="Always" Category="#400 NuGet" Description="Set this to true to create NuGet packages" DisplayName="NuGet : Build Package" ParameterName="NuGet_BuildPackage" />

This will create a section called “NuGet” and add the parameters to this section. The #400 sets the priority of the section, it will be positioned in fourth place (just beneath the default sections).


Now that we can set the parameters in the build process, we need to provide them as build arguments to msbuild.
Switch from the xml editor to the Workflow editor and find “Run MsBuild for project“.

Edit the command arguments in the properties window and add the new build property to the CommandLineArguments property:

String.Format("/p:SkipInvalidConfigurations=true {0} /p:BuildPackage={1}", MSBuildArguments, NuGet_BuildPackage)


You can now enable or disable NuGet package Generation from the build process window of your build. Creating NuGet packages is triggered for every project which has the NuGet targets file imported.

When you want to push the NuGet packages to the NuGet repository, take a look at NuGets push command.  This can also be implemented by an msbuild task.

Providing data to JavaScript functions from code behind

In my previous post, I talked about JavaScript namespaces and functions.
When using WebForms, it can be difficult to call these functions from the code behind in a nice way.
It usually requires some data to initialize the JavaScript function, for example, providing some html element ids as trigger elements.
The Ids of html elements are non-predictable (except when using static ids, but this brings in a whole bunch of different problems) and should be provided from the code behind to avoid the ugly <% %> syntax in your markup file.
I see a lot of people making use of a StringBuilder to write out a JavaScript object. This will work of course, but it is not the nicest and best way to do that, because you will lose your strongly typing and intellisense.

I prefer to create a model and use a JavaScript Serializer to create a json object and provide that to a function.

public class SearchManagerOptions
    public string Url { get; set; }

.Net has its own serializer; JavascriptSerializer. It is a very simple and straight forward serializer and does the trick.

var options = new SearchManagerOptions { Url = "someurlhere" };
var json = new JavaScriptSerializer().Serialize(options);

The result (json) will look like


This is fine for most common cases.

If you want some extra control over the serialization process, the JavaScriptSerializer will not be your friend and I recommend you to switch to the serializer of json.NET. This is a third party library (available on NuGet) which allows you to control the serialization process by decorating your properties with attributes.
For example, when I want to apply to the JavaScript standard of camel casing properties, I can use an attribute to change the output name of the property.

public class SearchManagerOptions
    public string Ur; { get; set }

The json.NET seializer is used as follows:

var options = new Models.SearchManagerOptions { Url = "SomeUrl" };
var json = JsonConvert.SerializeObject(options);

This results in:


That’s even better, we now apply to the standard!
Just play around with the json.Net library, it is full of nice serialization tricks. For example, ignoring properties for serialization by adding the JsonIgnore attribute to properties.

Now we need to call the JavaScript function and provide this data.
WebForms provides us two methods for injecting scripts; RegisterClientScriptBlock and RegisterStartupScript.
What is the difference? Good question! Both method signatures are the same. The difference lies in the position where the script is injected in the page.
RegisterClientScriptBlock injects the script at the top of the form element (as one of the first children). This means that none of the html elements are rendered yet. Remember that! All your selectors won’t work! Unless you use a document ready event.
RegisterStartupScript injects the script at the bottom of the form element, which means that all html elements are already rendered.
I usually go for RegisterStartupScript, because I think it is a cleaner solution to inject scripts at the end of your page. It is still injected inside the form element, but that is a limitation of WebForms.

var options = new Models.SearchManagerOptions { Url = "SomeUrl" };
var json = JsonConvert.SerializeObject(options);
var script = string.Format("ViCreative.Managers.SearchManager.init({0})", json);

if (Page.ClientScript.IsStartupScriptRegistered("SearchManagerInitialization"))
    Page.ClientScript.RegisterStartupScript(GetType(), "SearchManagerInitialization", script, true);

I do not want this script to be injected more than once, which is why I check if this script is already registered. I usually would add “SearchManagerInitialization” to a constant, but for clarity of this blog post, I just added it to the script.

JavaScript Globals, Namespaces and Scopes

Everybody hates (or at least should hate) globals. It makes your application harmful for attacks and globals can easily be overwritten (even by mistake).

Hiding functions and variables in scopes is one way to decrease the use of globals.
But globals cannot always be avoided. For instance, when you want your application to communicate with the outside world.

I like to use namespaces to make sure that I do not overwrite any globals. It also brings structure to your application. It groups related objects and functions.

var ViCreative = ViCreative || {};
ViCreative.Managers = ViCreative.Managers || {};

This creates a ViCreative.Managers namespace (or reuses it if it already exists). I usually use the domain name as first part of the namespace, just to make sure I don’t mess with other plugin/framework namespaces.
Always make sure you do not overwrite the namespace when creating/extending a namespace. Check if the namepsace already exists!!
This also allows the JavaScript files with namespace definitions to be loaded in any sequence. Now that we have a namespace, we can add objects and functions to it.

ViCreative.Managers.SearchManager = {
    _url : '',
    _value : '',

    doSearch : function() {
        // logic for searching

    init : function(options) {
        /// initialization logic here
        this._url = options.url;

    search : function(searchValue) {
        // post searchValue and return response
        this._value = searchValue;

This is already a lot better than using just some global methods, but we’re still not there yet.
All variables and methods are still out in the open. We need to create a scope to hide the private members and functions. In the example above, we only want to expose the init and search method. The doSearch method should not be called directly.

Functions have their own scope and allow you to hide variables. Wrapping the SearchManager in a function allows us to create a new scope for all variables inside the SearchManager object.

ViCreative.Managers.SearchManager = function () {
    var url = '';
    var value = '';

    var doSearch = function() {
        // logic for searching

    var init = function(options) {
        /// initialization logic here
        url = options.url;

    var search = function(searchValue) {
        // post searchValue and return response
        value = searchValue;
    return {
        init: init,
        search: search

The example above creates and executes a function and stores the result in ViCreative.Managers.SearchManager.
The function returns an object, which exposes the init and search functions. All other variables and functions are not accessible from the global scope:


Frameworks, variables and other objects from the global scopre, which are used by this function, should be provided as argument to this function to bring them to the local scope.

ViCreative.Managers.SearchManager = function ($) {

This example adds jQuery to the scope of this function and stores it in $.
Try not to pollute the global scope and hide all methods and variables which are meant to be private.

JavaScript is a first-class citizen! Treat it as such!

Continuous delivery, NuGet package generation and integration with TFS build server

Continuous Integration is getting more important and more popular and that is a good thing!
A couple of days ago, I was automating the NuGet package generation process. NuGet packages can be used for deployments to environments.

NuGet integrates in your solution when package restore is enabled.


This adds the following files to the .nuget folder in your solution:

  • NuGet.exe
  • NuGet.targets
  • NuGet.config

It also adds an import command for the NuGet.targets file to the project file:

<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

One target of the targets file is BuildPackage. This target can be triggered by running the following msbuild command from the command line:

msbuild mysolution.sln /t:Build /p:BuildPackage=true

This will create a NuGet package for all projects which have imported the NuGet.targets file.
The following files will automatically be added to the NuGet package:

  • The project assembly
  • Files with build action set to content

For simple projects, this behavior is fine. The NuGet package holds the exact content of the project.
In my case, this was not really what I wanted. I wanted one NuGet package for multiple projects and the content files had to be placed in a different structure and location.

That’s when a nuspec file comes to the rescue!

The NuSpec file is the manifest file for NuGet packages. This file holds all information required for the NuGet packages, for example;

  • Package meta data (name, author, copyright, etc.)
  • Dependencies
  • Included Files

For a complete reference of the nuspec file, see

I added a reference to the assembly1 and assembly2 project and added a nuspec file to the root of the project.
In the nspec file, I added the required assemblies and content files. The nuspec files section looked something like:

    <file src="bin\assembly1.dll" target="lib\net40" />
    <file src="bin\assembly2.dll" target="lib\net40" />
    <file src="..\assembly1\Scripts\**\*.*" target="Content\Scripts" />
    <file src="..\assembly2\Scripts\**\*.*" target="Content\Scripts" />

I ran the msbuild command on my dev environment and a package was created successfully and contained all files.
It also contains the dll of the NuGet project itself. This is not what I wanted.
I created a naming convention for all NuGet projects, the projects end with NuGet. This gives me the option to exclude the *nuget.dlls from the packages. This can be added to the build command I will describe later in this post.

Files added to the Content folder of a NuGet package are installed on the root of the target the project (the project which the NuGet package is installed to).
Assemblies added to the lib folder will be referenced in the target project. A subfolder in the lib folder can be used for providing different assemblies for a framework (.Net 3.5, .Net 4, etc).

I configured the TFS build server to run the same command and started a build.
The build failed, because NuGet could not find some of the referenced files in the files section of the nuspec file.
When I used RDP to login to the build server, I noticed that the output folder (binaries folder as it is called in the TFS build workflow template) is changed by TFS. It does not use the bin folder of every project, but it changes it to a different folder.
That is why bin\assembly1.dll and bin\assembly2.dll could not be found.

Creating packages should work on both dev environment and on the build server, so referencing the absolute output path on the build server is not an option.
The output folder is stored in the OutDir parameter. This parameter needs to be available in the nuspec file. This can be achieved by adding it to the properties list of the build command.
The build command is stored in the targets file, add “OutDir=$(OutDir.Trim(‘\\’))\\” to the property parameter of the build command. You can also exclude files by adding an Exclude parameter. This is what I have done to exclude the *Nuget.dll files.
The updated BuildCommand is as follows:

<BuildCommand>$(NuGetCommand) pack "$(ProjectPath)" -Properties "Configuration=$(Configuration);Platform=$(Platform);OutDir=$(OutDir.Trim('\\'))\\" $(NonInteractiveSwitch) -OutputDirectory "$(PackageOutputDir)" -symbols -Exclude **\*NuGet.dll</BuildCommand>

It is now possible to use the OutDir variable in the nuspec file:

    <file src="$OutDir$assembly1.dll" target="lib\net40" />
    <file src="$OutDir$assembly2.dll" target="lib\net40" />
    <file src="..\assembly1\Scripts\**\*.*" target="Content\Scripts" />
    <file src="..\assembly2\Scripts\**\*.*" target="Content\Scripts" />

This solves the output issue on the build server and the build still works on the dev environment.

Creating a circular bitmap in Android in C#

A while ago, I was looking for a way to change a bitmap into a circular bitmap.
There are a lot of good examples on the internet, but none of them completely met my requirements.
So I used one of them as base to create my own helper for creating a circular bitmap.

public static Bitmap CreateRoundedBitmap(Bitmap bitmap, int padding)
    Bitmap output = Bitmap.CreateBitmap(bitmap.Width, bitmap.Height, Bitmap.Config.Argb8888);
    var canvas = new Canvas(output);

    var paint = new Paint();
    var rect = new Rect(0, 0, bitmap.Width, bitmap.Height);
    var rectF = new RectF(rect);

    paint.AntiAlias = true;
    canvas.DrawARGB(0, 0, 0, 0);
    canvas.DrawOval(rectF, paint);
    paint.SetXfermode(new PorterDuffXfermode(PorterDuff.Mode.SrcIn));

    canvas.DrawBitmap(bitmap, rect, rect, paint);
    return output;

I’m not a fan of static methods, but when no context is used, I’m not that bothered.

A border can be added by drawing a second oval with a stroke width and a color property set to the paint instance.

 var rect2 = new Rect(padding, padding, bitmap.Width - padding, bitmap.Height - padding);
 var p = new Paint();
 p.Color = Color.White;
 p.StrokeWidth = 10;
 p.AntiAlias = true;
 canvas.DrawOval(new RectF(rect2), p);

This example creates a white border around the circular bitmap.

In my app, I use a lot of white circular bitmaps. To keep the code as DRY as possible, I created another helper method for creating white bitmaps.

public static Bitmap CreateWhiteBitmap(int width = 160, int height = 160)
    var bitmap = Bitmap.CreateBitmap(width, height, Bitmap.Config.Argb8888);
    Canvas c = new Canvas(bitmap);
    return bitmap;

Another static. Still can’t be bothered, because no context is used.
I do like to point out that statics can be very dangerous. When statics are used as repositories to read static variables, files or whatever kind of data, remember to at least always use locks, but even better… just don’t use statics!!

Now let’s bring it all together.

In my activity, I use the following code to create a bitmap, change it to a circular bitmap and add it to an ImageView (with id “Image” in my Layout file):

var bitmap = BitmapHelper.CreateWhiteBitmap();
bitmap = BitmapHelper.CreateRoundedBitmap(bitmap, 10);
var imageView = view.FindViewById<ImageView>(Resource.Id.Image);

That’s it! Hope this helps!

Changing the layout for different states of an android button

A button in android can have one or multiple states:

  • android:state_pressed
  • android:state_focused
  • android:state_hovered
  • android:state_selected
  • android:state_checkable
  • android:state_checked
  • android:state_enabled
  • android:state_activated

The layout of a button’s state cannot be changed from within the layout file itself.
A drawable resource file needs to be used to set a layout for the different states.

This resource file should contain a selector with a collection of item elements.
Every item element can target one (or multiple) state(s) of a button by adding the state and its value as attribute. See example below.
It is not necessary to implement all states. An item element with no state attribute is used as default state. See last item element in example below.
This resource file is stored in the Drawable folder of the Resources content (F.E. /Resources/Drawable/button.xml).
Other resources can be referenced and used. In the example below, two custom defined colors are used (@color/custom_theme_button_primary and @color/custom_theme_button_secondary).
When a combination of states are defined on an item element, all states need to be active!

The following example adds three layout states to a button; pressed, disabled and a default state.

<selector xmlns:android="">
  <item android:state_pressed="true" android:color="@color/custom_theme_button_primary">
    <shape xmlns:android="">
          android:color="@color/custom_theme_button_secondary" />
          android:bottom="10dp" />
  <item android:state_enabled="false" android:color="@color/custom_theme_button_primary">
    <shape xmlns:android="">
          android:color="@color/custom_theme_button_secondary" />
          android:bottom="10dp" />
  <item android:color="@color/custom_theme_button_secondary">
    <shape xmlns:android="">
          android:color="@color/custom_theme_button_primary" />
          android:bottom="10dp" />

Setting the color attribute on the item element sets the text color. Setting the color attribute in the solid element within the shape element will set the background color for this shape.
Note: The margin cannot be set in a drawable resource file.

In the layout file, the button needs to contain a reference to the drawable resource file:


This example requires a drawable resource with the name “button”. Simply create a xml file with the name “button.xml” in Resources/Drawable and add your selector and items.