Advanced bindings with the Windows Azure Web Jobs SDK

 Jan 27th, 2014 

 ,

The Windows Azure Web Jobs SDK is a framework that simplifies the task of adding background processing to web sites. You can get more details about it by reading the Getting Started guide or Scott Hanselman’s introduction. Scott describes the Web Jobs SDK very well: “minimal ceremony for maximum results”. The Windows Azure Web Jobs SDK (codename SimpleBatch) is a very simple framework but provides some powerful binding capabilities.

The most simple advanced binding is the blob name placeholder. It allows you to express the intent of listening to blobs in a specific container that match a specific pattern. For example, you are only interested in blobs that end with “.jpeg”, or only blobs that are prefixed with “input-” and have the extension “.txt”, or you just want the name of the blob and you do not want to bind to an Azure SDK type.

public static void Thumbnails(
    [BlobInput("images/{name}.jpeg")] Stream inputImage,
    [BlobOutput("thumbnails/{name}.jpeg")] Stream outputImage)
{
    // Code that reads the image from inputImage and writes it to outputImage
}

The function above will only be triggered by blobs in the “images” container that have the extension “.jpeg”. The value of {name} placeholder from the input will replace the {name} placeholder in the output. For example, if the input blob is “images/img123.jpeg” then {name} is “img123″ and the output image is “thumbnails/img123.jpg”.

The name placeholders can be also be used to read and write to and from the same container without triggering an infinite loop (the output retriggers the function).

public static void Thumbnails(
    [BlobInput("images/full_{name}.jpeg")] Stream inputImage,
    [BlobOutput("images/thumb_{name}.jpeg")] Stream outputImage)
{
    // Code that reads the image from inputImage and writes it to outputImage
}

The function above reads from the “images” container and writes back in the same container. However, it is only triggered by blobs suffixed with “_full.jpeg” and writes blobs that end with “_thumb.jpeg”. For example, if the input blob is “images/full_img123.jpeg”, then {name} is “img123″ and the output image is “images/thumb_img123.jpeg”.

The placeholder binding is not limited to blob output only. If you need the value of {name} in the code, you can get it by adding a parameter named “name” to your function.

public static void Thumbnails(
    [BlobInput("images/{name}_full.jpeg")] Stream inputImage,
    string name,
    [BlobOutput("images/{name}_thumb.jpeg")] Stream outputImage)
{
    // Code that reads the image from inputImage and writes it to outputImage
}

When the function above executes, the parameter “name” will have the value of the {name} placeholder. For example: if the input is “images/img123_full.jpg” then “name” has the value “img123″.

Similar binding capabilities are available for queue messages too. Assume the following queue message object:

class Order
{
    public string CustomerName {get;set;}
    public string OrderId {get;set;}
}

When a new order arrives, we are going to get the Order message from a queue and create a blob (an invoice) with the name equal to the order id. One approach is to use the IBinder interface to bind the output blob and specify the name that equals the order id. The better and simpler approach (SimpleBatch) is to bind the blob name placeholder to the queue message properties:

public static void ProcessOrder(
    [QueueInput("orders")] Order newOrder,
    [BlobOutput("invoices/{OrderId}")] TextWriter invoice)
{
    // Code that creates the invoice
}

The {OrderId} placeholder from the blob name gets its value from the OrderId property of the newOrder object. For example, newOrder is (JSON): {"CustomerName":"Victor","OrderId":"abc42"} then the output blob name is “invoices/abc42″. The placeholder is case-sensitive.

C# error CS1540

 Sep 12th, 2012 

 , , ,

There are many ways in which one could violate the rules of Object Oriented Programming in C#. Fortunately, the C# compiler is smart enough to prevent many of them, like the one in the example below. Can you  figure out why the compiler doesn’t allow the call in the last method?

abstract class BaseClass
{
    protected abstract void AMethod(BaseClass arg);
}
class Derived : BaseClass
{
    protected override void AMethod(BaseClass arg)
    {
        arg.AMethod();
    }
}

Read the rest of this post »

Default indexer and Reflection glitch

 Apr 22nd, 2011 

 , ,

I was writing some C# unit tests that had to use Reflection in order to set properties on objects, when I got into an interesting problem. I will provide a simplified version of the code I wrote, first the version without reflection, then my reflection version that had an issue and, in the end, the correct version.

TestClass is a class that has a property of type List<int>:

class TestClass
{
    public List<int> Value { get; set; }
}

Goal: create an instance of this class, set the property and print the second element in the list. Simple, huh? The code without reflection is:

TestClass c = new TestClass();
c.Value = new List<int>() { 4, 5, 6 };
Console.WriteLine(c.Value[1]);

Seems straight forward to use reflection for this, right? Here is my attempt:

//TestClass c = new TestClass();
object c = new TestClass();
//c.Value = new List<int>() { 4, 5, 6 };
Type t = c.GetType();
PropertyInfo prop = t.GetProperty("Value", BindingFlags.Public | BindingFlags.Instance);
prop.SetValue(c, new List<int>() { 4, 5, 6 }, null);
//Console.WriteLine(c.Value[1]);
int valueToOutput = (int)prop.GetValue(c, new object[] { 1 });
Console.WriteLine(valueToOutput);

Can you see the glitch? I can tell you that line 10 throws TargetParameterCountException. You know why?

Read the rest of this post »

Dynamic tests with mstest and T4

 Mar 5th, 2011 

 , , , , , ,

If you used mstest and NUnit you might be aware of the fact that the former doesn’t support dynamic, data driven test cases. For example, the following scenario cannot be achieved with the out-of-box mstest: given a dataset, create distinct test cases for each entry in it, using a predefined generic test case.

The best result that can be achieved using mstest is a single testcase that will iterate through the dataset. There is one disadvantage: if the test fails for one entry in the dataset, the whole test case fails.

So, in order to overcome the previously mentioned limitation, I decided to create a text template that will generate the test cases for me. As an example, I will write some tests for an integer multiplication function that has 2 bugs in it:

public int Multiply(int a, int b)
{
    //This conditions are simulating the 2 bugs
    if (a == 0 && b == 1)
        return 100;
    if (a == 1 && b == 0)
        return -100;
    return a * b;
}

The classical approach (no dynamic test)

Without using any ‘hacks’, one could write the tests for the Multiply function in the following way:

//Tuple description <value of param a, value of param b, expected result>
private static readonly Tuple<int, int, int>[] TestData = new Tuple<int, int, int>[]{
    new Tuple<int, int, int>(0,0,0),
    new Tuple<int, int, int>(2,3,6),
    new Tuple<int, int, int>(1,0,0), //These will trigger one of the bugs
    new Tuple<int, int, int>(-2,-3,6),
    new Tuple<int, int, int>(0,1,0) //These will trigger one of the bugs
};
[TestMethod]
public void TestMultiply()
{
    foreach (var data in TestData)
    {
        Assert.AreEqual(data.Item3, Multiply(data.Item1, data.Item2),
                        "Failed for input ({0}, {1})", data.Item1, data.Item2);
    }
}

Running the test will surface only one of the bugs, the one triggered by the input (1,0):

This is not only bad because it doesn’t give a complete overview of the bugs but it also violates the principle of one assertion per test because more than one assertion could be triggered in the test case above.

The T4 approach (dynamic test)

Read the rest of this post »

Modifying .NET binaries – Part 2

 Jul 21st, 2010 

 , , , , , , ,

Description
ObjectiveRemove the ‘Trial protection’ from an obfuscated .NET application
Tools
  • WinDbg
  • CFF Explorer
Target audienceAdvanced users

The second part of the article discusses how to modify binaries that are obfuscated. For simplicity and clarity, I will not use obfuscated binaries. Doing this, allows the reader to understand what is actually happening. In the demo I will completely ignore the name of the methods or the actual, non-obfuscated, code.

I recommend reading the first part, if you didn’t already. It provides some information that might be needed to understand theis second part.

The same ‘TrialApp.exe’ binary is used. The current approach, as opposed the the former one, is:

  1. Load the application in debugger and break the execution when the trial message is displayed.
  2. Get the call stack
  3. Find the address of the trial check method
  4. Remove the call

1. Load the application in debugger and break the execution when the trial message is displayed

WinDbg can be obtained for free from Windows SDK (see the Microsoft Downloads website). If you are running a 64 bit OS, make sure you start the 32bit version of WinDbg (should be in Program Files (x86)).

Load ‘TrialApp.exe’ in WinDbg by clicking File -> Load Executable. In order to run it you have 3 options:

  1. Type ‘g’ and press ENTER
  2. Press F5
  3. Click Debug -> Go

The application will start and the execution will stop when the message box is displayed. Is actually waiting for the user to click OK. At this point break the execution by pressing Debug -> Break.

Before being able to debug the .NET application, 2 DLLs needs to be loaded. They help the debugger ‘understand’ the .NET internals. The actual paths might differ on your configuration. Anyway, make sure you load the 32 bit version of these files (the 64 bit version are in the Framework64 folder). The .load command loads external libraries.

.load c:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
.load c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

Read the rest of this post »

Modifying .NET binaries – Part 1

 May 30th, 2010 

 , , , , , ,

The content of this post can be used for good and bad purposes. Modifying the source code to bypass trial/license checks is what crackers do in order to get paid software for free. Be advised that the purpose of this article is not to teach you how to steal. My target for this article are the .NET developers who should understand what a cracker will (try to) do in order to get access to paid features.

Before reading any further you should understand that each protection measure (as long as the cracker can access the source code) is useless. Is just a matter of time, for a motivated person, before she will bypass any protection.

For the demo, we are going to use a very simple Windows Forms Application that will display a message box with a trial message and will exit after that. The goal is to show a few techniques that will prevent the application from exiting (and will remove the trial message).

The code for the ‘trial’ application is kept in just one class. There is just one variable for checking the trial and we’ll consider that is always true – it makes no difference if there was a function call to determine if the trial has expired.

public partial class Form1 : Form
{
    bool hasExpired = true;
    public Form1()
    {
        InitializeComponent();
    }
    private void Form1_Load(object sender, EventArgs e)
    {
        CheckTrialApp();
    }
    private void CheckTrialApp()
    {
        if (hasExpired)
        {
            MessageBox.Show("Trial has expired");
            Application.Exit();
        }
    }
}

The binary used was compiled on the x86 Release configuration with VS2010 having .NET 4.0 as target framework. The IL Disassembler from VS2010 and a free application called CFF Explorer are used to view and edit the binary.

Read the rest of this post »

Expression evaluation

 May 27th, 2010 

 , , , , ,

Let’s start with a simple quiz: 7/2 = … . Of course is 3.5 but is this also true for code?

If you somehow use a non-fractional data type for storing the result, you will always get the result 3. And that should not surprise you.

int result = 7/2; //expression is 3

However, if you choose to use a fractional data type, things will change …

double result = 7/2;

… or not. The value stored in the variable result is still 3 (actually 3.0 or something really close to 3.0 – since floating point data types store the approximation of a number).

Why is this happening?
Read the rest of this post »

Fancy windows previewer

 May 5th, 2010 

 , , ,

Tutorial description
Objective

Create a fancy-looking application that displays the preview of the open applications.

Covered topics
  • Enumerating windows and getting various information about them
  • Creating the Aero glass effect
  • Using the DWM windows preview feature
Requirements
  • Windows Vista/7 with the Aero theme active
  • Visual Studio 2010 (or 2008 but requires some changes in code which are not covered by this tutorial)
Target audienceIntermediate users
DownloadDownload IconTaskSwitcher (13.07 KB)

The basic idea behind this application is the following: upon start, we create snapshot (a list) of all the available windows and we use it to decide what previews to display. Once the list is created, a preview is drawn for each item. There is a drawback for this approach: if new windows are created or some existing are closed the interface will not display them (actually for closed windows will replace the preview with an icon). The advantage: is a simple implementation.

There are three parts for this project.

  1. Enumerating only the open applications’ windows
  2. Make a glass window
  3. Generate a live preview for each window

Enumerating windows

Enumerating all windows can be done with the EnumWindows function from user32.dll which can be easily imported in C#.

[DllImport("user32.dll")]
private static extern int EnumWindows(EnumWindowsCallbackDelegate callback, int lParam = 0);
private delegate bool EnumWindowsCallbackDelegate(IntPtr hWnd, int lParam);

However, the result of a pure enumeration will return hundreds of windows. The most powerful filtration is to keep just the windows that are visible. Again, a function from user32.dll called IsWindowVisible is used to check whether a hWnd belongs to a visible window. Probably, after this step you will have just 30-40 windows left in the list.

[DllImport("user32.dll")]
private static extern bool IsWindowVisible(IntPtr hWnd);

The next step is to decide which is the most meaningful representative window from each cluster of windows related by ownership. The Old New Thing blog presents an algorithm for this problem. The logic behind this algorithm is: “For each visible window, walk up its owner chain until you find the root owner. Then walk back down the visible last active popup chain until you find a visible window. If you’re back to where you’re started, then put the window in the Alt+Tab list.” A few Dll imports and the translation of the pseudocode to C# gives the following code.

Read the rest of this post »

Using UAC with C# – Part 3

 Jan 6th, 2010 

 , ,

After a long period since I wrote part 2 of this article I decided to add some extra information. There is one thing that was missed by the previous two articles: the design of UAC enabled applications.

If you use Windows Vista/7 then you know that buttons and links which elevate privileges are preceded by a shield icon. This is the way Microsoft decided to inform the user about the effect of clicking that control.

The first idea that might pop up is the reinvention of the wheel (or shield). In other words you could draw the shield on a button. This is OK except that:

  1. Is not easy
  2. Will require you to recompile the interface if Microsoft decides to change the icon
  3. You need the icon in many sizes 16×16, 24×24, 32×32, etc. (extract it from MS’ DLLs)
  4. Will create a lot of overhead with layout (position icon relative to text size/position)

The second method is easier, safer and recommended by MS. All you need to do is send a specific message (BCM_SETSHIELD) to the button if the user has limited privileges and pressing that button will trigger the UAC window. Actually there is a second, tricky, thing that must be done: the style of the button must be “System” (in C# “System.Windows.FlatStyle.System”). Without this you will not be able to see the shield.

The code provided in part 1 of this article will be modified in order to display the shield on the two buttons. Moreover, the shield will be displayed only when the user runs under an account with limited privileges or non-elevated administrator.

In order to display the shield one needs to send the BCM_SETSHIELD (=0x0000160C) message to the button. This can be done by using the SendMessage function from user32.dll. This article will not cover what is and how to use SendMessage, if you need more information about it follow the previous link.

To set the shield of the “Elevate this application” button one needs to send the message in the following way:

SendMessage(btnElevate.Handle, BCM_SETSHIELD, 0, 1);

The first parameter is the handle of the button, the second one is the message, the third one is not used and must be ‘0’ and the last argument must be non-zero in order to draw the shield, zero otherwise.

If you try this it will not work :) Remember the ‘tricky’ thing told before? This is the full code to display the shield for btnElevate:

btnElevate.FlatStyle = FlatStyle.System;
SendMessage(btnElevate.Handle, BCM_SETSHIELD, 0, 1);

There is only one thing that must be done in order to work properly. Remove the shield if the user has elevated privileges. I don’t know if this is against MS’ recommendation but in my opinion one must not be shown information that cannot be used in that context; in our case don’t show the elevate shield if there is nothing to elevate.

Part 1 described how to check if a user has full rights. Now we are just using that boolean variable:

if (!hasAdministrativeRight)
    SetUACShields();

Where SetUACShields will send the message to all buttons that require the shield drawn.

The full updated code from Part 1: Download IconUAC Code 3 (10.13 KB)

Tip 2: #if

 Jul 23rd, 2009 

 , , ,

This is a C# tip

When the C# compiler encounters an #if directive, followed eventually by an #endif directive, it will compile the code between the directives only if the specified symbol is defined. Unlike C and C++, you cannot assign a numeric value to a symbol; the #if statement in C# is Boolean and only tests whether the symbol has been defined or not.

A predefined (by default) symbol on the “Debug” build configuration is DEBUG. Using this symbol you can define code that will be compiled only in Debug; for example, a debug window will be shown only when needed.

using System;
using System.Text;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
#if DEBUG
            Console.WriteLine("Debugging information");
#endif
            Console.WriteLine("Code that always executes");
        }
    }
}

The code above will print “Debugging information” and “Code that always executes” when build on Debug and will display only “Code that always executes” when build on another configuration.

You can suppress the definition of the DEBUG symbol from the project properties or by removing the DEBUG from the build argument “/define:DEBUG”. Also, you can define your own symbols in order to accommodate your needs.

Define as many build configurations and symbols you need but don’t abuse this feature!