Free online event about Windows Azure - November 14, 2012

If you work with Windows Azure and you want to learn more about this great cloud ecosystem or you want to know what can be done on Windows Azure and what are the main features than…

Microsoft will host Windows AzureConf, a free online event that is done for Windows Azure community. You will be able to see a lot of sessions about Windows Azure. This will be streamed live using Channel 9.

When:  November 14, 2012

When: all over the world - live stream

If you want to register or read more about this event follow this link.

Read More

Duplicate Detection in Windows Azure Service Bus

One great feature of Windows Azure Service Bus is the ability to identify the messages that are duplicate. Using this feature we can automatically remove messages from Service Bus Queue or Topic when we have more than one the same message. By default this mechanism is deactivated, but we can activate it very easily.
Let’s see how this mechanism works. When we activate this mechanism Windows Azure Service Bus will start to store a history with our messages. This period of time can be configures from only a few minutes to days. If a duplicate message is send to Service Bus, the service will automatically ignore the message.
Because the content of each message need to be serializable, the duplicate detection mechanism will look to the serialized items that were added to the message. If the content is the same, than the message will be consider as duplicate. For example we have the following class that we add to each message:

[DataContract]
public Foo
{
    [DataMember]
    public string Id { get; set;}
    [DataMember]
    public string Name { get; set;}
}

If we will add two messages with objects of type Foo with the same id and name, than the second message will be consider duplicate. We will not receive any kind of notification when we will try to send the second message.

MessagingFactory factory = MessagingFactory.Create([uri], [tokenProvider]);
MessageSender sender = factory.CreateMessageSender("FooQueue")

Foo obj1 = new Foo() { Id = “1”, Name = “One” };
BrokeredMessage message1 = new BrokeredMessage(obj1);

Foo obj2 = new Foo() { Id = “1”, Name = “One” };
BrokeredMessage message2 = new BrokeredMessage(obj2);

sender.Send(message1);
sender.Send(message2);

It is very important to remember that the duplicate detection mechanism will use the space from our Service Bus to persist the old messages. Because of this it is very important to be careful when we set the history time period.
This configuration can be made from two places. One is from portal, when we can activate this feature and set the history time period. This feature will be available only if you select “Custom create”.

The second place from where this can be configuration can done is from code. In the moment when we create a new Service Bus Topic or Service Bus Queue we can specify in the create command. To be able to do this we will need to create a TopicDescription or a QueueDescription object. In this object we can activate this functionality and set the history time period.
Topic:

TopicDescription fooTopicDescription = new TopicDescription("FooTopic")
    {
        RequiresDuplicateDetection = true,
        DuplicateDetectionHistoryTimeWindow = new TimeSpan(10, 0, 0),
    };
namespaceManager.CreateTopic(fooTopicDescription);

Queue:

QueueDescription fooQueueDescription = new QueueDescription("FooQueue")
    {
        RequiresDuplicateDetection = true,
        DuplicateDetectionHistoryTimeWindow = new TimeSpan(10, 0, 0),
    };

namespaceManager.CreateQueue(fooQueueDescription);

These policy settings of Service Bus Queue or Service Bus Topic can be changed only on creating time. After this, if we want to change the history time period or to deactivate it, it will not be possible. To be able to do this, you will need to delete the resource and recreate it.
This is a great feature that can be used when we need to avoid duplicate messages to be added to our Service Bus.

Read More

Windows Azure Tools - Error 0x80070643: Failed to install MSI package

Today I had to install Visual Studio 2012 and Windows Azure 1.8 SDK for a new project. Everything went as a charm; I didn’t have any kind of problems. But after a while I realized that I had a project that is written in .NET 4.0 and use Windows Azure 1.6 SDK and an update to 1.8 is in this moment is not possible.
After installing Visual Studio 2012 and Windows Azure 1.8 SDK I tried to run my old project, but without success. In that moment I realize that I have a big problem, because I will not be able to provide support for that project. I uninstall Windows Azure 1.8 SDK, installed 1.6 but without success. I tried to uninstall Visual Studio 2012 with success. After that I accessed Windows Azure web site and download Windows Azure 1.6 SDK and Windows Azure Tools 1.6 but I received an error when I tried to install Windows Azure Tools 1.6.

Error 0x80070643: Failed to install MSI package

I tried to repair Visual Studio 2010, uninstall and reinstall all the kits related to Windows Azure but with the same result when trying to install Windows Azure Tools 1.6.

Error 0x80070643: Failed to install MSI package

I could not use Last Good Know Configuration because installing Visual Studio 2012 and other tools created a lot of restoring points and all of them were from today. I started to think at the “black magic solution”. Clean install of Windows on the current machine or on a virtual machine. But before this I had a great idea.
What about trying to install Windows Azure Tools 1.6 using Microsoft Web Platform Installer. And surprise. I was able to install with success all my tools. In this moment I have the machine in the state that was in this morning.
About Visual Studio 2012 and Windows Azure 1.8 SDK. For now I will create a virtual machine with a cool configuration W8 + VS2012 + Windows Azure 1.8. In the future, I will install as default machine Windows 8 with VS2012, but in this moment my first priority is to offer support to my clients.

Read More

Visual Studio - How to see the source code of .NET framework

Every time when I’m installing Visual Studio one a clean computer I have problems remembering the steps that need to be done on Visual Studio to see the source code of the .NET framework.

In the next lines we will look over the steps that need to be done. Next time when I will need to make this configuration I will come back to this post.

We need to go in Visual Studio menu, under Tool->Options and select the Debugging tab. In the general node we will need to check/uncheck the following options:

• Uncheck the “Enable Just My Code (Managed only)”
• Uncheck “Require source files to exactly math the original version”
• Check “Enable source server support”

In this moment we are almost done, the only think that we need to do is to double check under Symbols node that “All modules, unless excluded” is checked. In general I prefer to create a custom path where the symbols are downloaded.

While you are debugging, if you have any kind of problems loading this symbols, go on the call stack, right click on the stack and check if “Symbol Path” is selected in the “Load Symbols From”.

First time when you will debug after these changes, you will notify the application will run slower, because pdb files are downloaded.

Good luck!

Read More

Design a state machine mechanism using Windows Azure Service Bus (part 2)

In my last post I presented how we can implement a state machine using Windows Azure Service Bus Topics. In this post we will see the real code that we need to write to make this possible.
We will start from a simple example. Let’s imagine that we have 3 states machines:

1. Added
2. Initialized
3. Processed

Each state change will required a custom action to be executed. When changing the state from Added to Initialized we will need to calculate some values. Changing the state from Initialized to Processed will required to store the sum value in a repository. Messages in state Processed will be logged.
We will implement this using Windows Azure Service Bus Topics. For each state we will have a different subscription that will process messages with the given state. Each action that needs to be done at each step will be made by the process (machine) that receives the given message from subscription.
In the next part of the post we will cover all the steps that need to be done to be able to implement this.
First of all we need to create a new Service Bus Topic. Before creating a Service Bus Topic you should always check if a topic with the specific name was already created.

var namespaceManager =
    NamespaceManager
        .CreateFromConnectionString(CloudConfigurationManager.GetSetting("ServiceBusConnectionString"));

if (!namespaceManager.TopicExists("myFooTopic"))
{
    namespaceManager.CreateTopic("myFooTopic");
}

After this step, we will need to create a subscription for each state. For the first step, the sum that needs to be computed can be done directly from subscription. We can specify in the action of the subscription the sum calculation.

RuleDescription ruleDescription = new RuleDescription()
{
    Action = new SqlRuleAction("set sum = value1 + value2"),   
    Filter = new SqlFilter("state = added");
}

namespaceManager.CreateSubscription(
    "myFooTopic",
    "addedSubscription ",
    ruleDescription);

Even if the calculation is made automatically, by Service Bus Topic, we will need to take the message from the current subscription, change the state and add it back to the topic:

TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");

SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic",
    "addedSubscription");

BrokeredMessage brokeredMessage = subscriptionClient.Receive();
if(message != null)
{
  try
    {
    BrokeredMessage newMessage = new BrokeredMessage();
    newMessage.Properties["sum"] = message.Properties["sum"];
    newMessage.Properties["state"] = "initialized";
    topicClient.Send(newMessage);   
        message.Complete();
    }
    catch (Exception)
    {
        message.Abandon();
    }   
}

In this moment we have a mechanism that process messages that are in the first state. A similar code need to be implemented for the next 2 states. For the next state we will need to create the subscription:

RuleDescription ruleDescription = new RuleDescription()
{
    Filter = new SqlFilter("state = processed");
}

namespaceManager.CreateSubscription(
    "myFooTopic",
    " processedSubscription ",
    ruleDescription);

After this we will need to implement the action that need to be done for messages with the given state:

TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");

SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic ",
    "processedSubscription");

BrokeredMessage brokeredMessage = subscriptionClient.Receive();
if(message != null)
{
  try
    {
    var sum = message.Properties["sum"];
    // Save the sum in the repository.
    BrokeredMessage newMessage = new BrokeredMessage();
    newMessage.Properties["sum"] = sum;
    newMessage.Properties["state"] = "processed";
    topicClient.Send(newMessage);
        message.Complete();
    }
    catch (Exception)
    {
        message.Abandon();
    }   
}

For the next step, the code is very similar; I will not describe the code again. For the last state action we don’t need to add the message again to the topic, because the message is in the last state. We need only to write the data to the log.

TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");

SubscriptionClient subscriptionClient = SubscriptionClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "initialized",
    "processedSubscription");

BrokeredMessage brokeredMessage = subscriptionClient.Receive();
if(message != null)
{
  try
    {
    Trace.Write(message.Properties["[PropertyName]"]);
    Trace.Write("The ABC was processed");
        message.Complete();
    }
    catch (Exception)
    {
        message.Abandon();
    }   
}

The last step is to write a message on the Service Bus Topic that has the first state.

TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");

BrokeredMessage message = new BrokeredMessage();
message.Properties["value1"] = 10;
message.Properties["value2"] = 40;
topicClient.Send(message);

After the message will be added to the topic, based on the status property, each subscription will process it. Each subscription will process only messages that have their specific status.

 In this post we saw how we can implement in Windows Azure Service Bus Topics a simple workflow that is based on the states.

Read More

How many fingers point can be tracked by Windows 8

Windows 8 brought to us a native support for touch screens. This is a great feature that opens the tablets world for us.
For touch support, we have a lot of gestures that are built in. We need only to subscribe to the event that we want to listen. This can be very useful, because we don’t need any more to implement our custom gestures.

• Tap - one finger touches the screen and lifts up.
• Press and hold - one finger touches the screen and stays in place.
• Slide - one or more fingers touch the screen and move in the same direction.
• Swipe - one or more fingers touch the screen and move a short distance in the same direction.
• Turn - two or more fingers touch the screen and move in a clockwise or counter-clockwise arc.
• Pinch - two or more fingers touch the screen and move closer together.
• Stretch - two or more fingers touch the screen and move farther apart.

If we need a custom gesture we can implement it without any kind of problem. This is not recommended because the user will need to learn new gestures for each application.
I received some question about how many fingers can be tracked in the same time by Windows 8. It seems that this is direct dependent to the hardware. WinRT API gives as the possibility to track each touch point separately with a unique id when the track point enters in our component. We can store these items in a collection (dictionary with the pointer ID as key). When a new pointer appears in our component we can add it to our collection and when the pointer exits our control we will need to remove it from our collection. In this way we will know how many finger points are in our controller.
The event that we need to use to track these actions is PointerMoved event of a container. The event will contains a method named “GetCurrentPoint”, that will return the current point that was moved. Each object of this type contains two properties that are very useful for us:

• PointerId – The unique id of the pointer (each time when we touch the screen a new point with a new id will be generated).
• IsInContact – Will tell us if the current pointer is still in contact (eq. when you remove the finger from the screen this method will be called with this property set to false – at this step we need to remove the pointer id from the collection).

Our code should look like something like this:

private void container_PointerMoved(object sender, PointerRoutedEventArgs e)
{
    PointerPoint currentPointerPoint = e.GetCurrentPoint(myContainer);
    var pointerId = currentPointerPoint.PointerId;
    if (!currentPointerPoint.IsInContact 
           && collection.Contains(pointerId))
    {
      collection.Remove(pointerId);
        return;
    }
    if (currentPointerPoint.IsInContact) 
    {
  // Check the pointer location - Position.X and Position.X properties
  collection[pointerId] = ...;
    }
}

It seems that the number of maxim fingers that are supported by Windows 8 is directly dependent by the hardware.

Read More

Design a state machine mechanism using Windows Azure Service Bus (part 1)

In this post we try to see a possible solution to implement a simple state machine (with a simple workflow) over Windows Azure Service Bus.
Let’s imagine a system that needs to process over 1 million requests per day. Each request that enter in the system will pass through different statutes until the process will be finished. If we have simple rules, it will be very easily for us to implement a system that will process each request and change the state of our request.
This can be imagined as a simple workflow, where a request flows from one state to another. At each step, we are making executing a small action. The big question here is how we can design a solution in a way where we will don’t have any kind of scalability problems.
The biggest problem that can appear at this step is related to scalability and distribution the logic over machines. This can become a nightmare when death-locks appears or when the system will reach his limits. The costs of hardware’s that will help us to survey another day can be enormous. 
We will see a simple solution that uses Windows Azure Service Bus to resolve our problem. In the next post we see how easily we can scale this solution.
Let’s assume that each request will go through 4 states before it will process completely. Each action that need to be done implicate an external system or an internal system that was already implemented.
For this case we can use Windows Azure Service Bus with success to implement a mechanism that will send a request from one state to another. In this way we will have reliability on our site. Not only this, we will not have any kind of problem with losing the requests that has a specific state if something happens with the system.
In this first solution, we will use Windows Azure Service Bus Topic. As we already know, Windows Azure Service Bus Topic permit give us the possibility to send the same message to more than one listener. From some perspective it is very similar to message broadcast. Each listener need to listen the topic through a subscription.
What is very useful at this is what we can with a subscription. We have the possibility to have not only more than one client to our subscription, but we can define custom rules. Using these rules we will be able to define what type of messages will be accepted by our subscription.
If a subscription will accept only messages that has a property with a specific value, than we will be able to process only messages with a specific state by our subscription. After the message is processes, we can change create a new message with the new state and send it back to the Windows Azure Service Bus Topic.
The system would look something like this:

As we can see, we use the same topic to add messages that are in a new state. Each subscription will process messages on the given state. In this current implementation, we are using Windows Azure Service Bus Topics because we don’t want to use a different place to store each message that has a different state. In the same time, for each subscriber we can have more than one listener. For the states where we know that computing power is more expensive, than we can allocate more listeners.
In the next post we will see how we can make this system more scalable using Windows Azure Service Bus features.

Read More