C# error at compile time challenge

Problem:
I have a challenge for you. You will find at the end of thispost a link to a zip that contains a .NET 4.0 projects. The challenge is tomake this project to compile and give me the cause of the problem. I will letyou until Friday morning.

Good luck.

https://skydrive.live.com/redir?resid=BB7D9F52E4FDB024!259&authkey=!APfTPi6HWX0VJQg


Solution:
In the ‘class’ word from the Foo class we had an odd character for Unicode world. The character named is ‘Zero with space’. Is like a space between words but without a visible space (width). Because Visual Studio can process also Unicode files, we have no limitation to add Unicode characters that are not visible using a normal editor. If we open the file with Total Commander viewer for example we will be able to see the character (in hex view for example).
Nice job :-)

Read More

Service Bus Topics - Limitations

Until now we saw how we can use Service Bus Topics. Before starting to use it in a real project we need to know what are the current limitations that Service Bus Topics. In time, this limitation can change when a new version of Service Bus will be released. The following limitations are valid now, august 2012.
The size of a topic is set on creation. The maxim size accepted is 5GB. We can define a topic size from 1GB to 5GB. For Service Bus Topics we don’t need to pay the space used by the messages from the topic. Also when a message is received to a topic that exceeds the maxim size, a custom exception will be throw, which notify the client code about this problem. The good part is that we don’t have a limit of numbers that we have in a topic if we don’t exceed the maximum size of the topic.
For each topic we can have as many as 25 listeners. This is the maxim number of listeners on a relay. In the same time, the maximum numbers of relay listeners is limited to 2000. As we expect, an error is throw when this limit is reached (this behavior is for almost all limitation reached). As with the maxim number of listeners on a relay, we can have maximum 2000 subscribers per topic and a maximum 2000 SQL filter per topic. Don’t ask me from where this numbers appeared. One interesting thing here, each filter and action defined for a topic can have maximum 4KB size and each action can has as 64 expressions.
In the same order, a namespace can have as many as 10.000 topics and quest. Remarks, the maxim value is a sum between total number of Service Bus Queues and Service Bus Topics from a namespace.
The maximum size of a message is 254KB, from where the message header can have maximum 64KB. We can add as many properties we want to the header if we don’t exceed 64KB.
When we exceed one of these limitations an error is atomically throw in our code. Because of this is very easy to detect a kind or limitation reached.
In the next future I accept the limitation to disappear. Even now, I thing that for a normal application we can leave without any problem with this limitation and develop beautiful application over it.

Read More

Service Bus Topics - How to use it (part 2)

In this post I will continue the post about how we can use Service Bus Topics. In the previews topic we saw how we can create and send messages to a topic. In this post we will see how we can consume messages that were sent to a topic.
Each topic can have from one to n subscribers. A subscriber represents a consumer of messages from the topic. Each subscriber can register to all messages that are added to a topic or only to a part for them. Each subscriber can have a filter set; based on this filter only the messages that validate the filter condition will be received by him. We can imagine that for each subscriber a private queue is create where messages are sent for the specific subscriber.
The base subscriber that is the most simple is the one that subscribe to all messages that are sent to a topic. The type of the filter that is used for this case is called “MatchAll” – and is the default filter. Each subscriber has a unique named and similar with creating the topic, we need to check if the subscriber already exists before creating it.

if (!namespaceManager.SubscriptionExists("myFooTopic", "retriveAllMessagesSubscriber"))
{
    namespaceManager.CreateSubscription("myFooTopic", "retriveAllMessagesSubscriber");
}

The first parameter specifies the name of the topic and the second one represent the subscriber name. The naming conventions for the subscriber name are the same as for a topic name. Beside the default behavior, we can specify custom filters that can be applied to messages. For example we can define a subscriber that only accepts messages that a property named “value” set to 10.
This custom filter can be specified in two ways – filters and rule description.
The first way, using filters, is using the SQLFilter rules implementation (SQL92). If you have some knowledge about SQL and where clause, that it will be very easy to use this filter. For the above example we need to create a new instance of SQLFilter and to specify the “value” property to be equal to 10.

namespaceManager.CreateSubscription(
    "myFooTopic",
    "valueIs10Subscriber",
    new SqlFilter("value = 10"));

The other way is by using the RuleDescription class. In comparison with a filter, the rule description can have custom actions that can be executed when the filter conditions is true. For example we have the ability to change a property of the BrokeredMessage that is in the topic. For example when the value is 10 we want to set the property isValid to false. For this we will need to create a RuleDescription where the filter condition to be the same as in the above example, but the action will set the isValid property to false.

RuleDescription ruleDescription = new RuleDescription()
{
    Action = new SqlRuleAction("set isValid= false"),
    Filter = new SqlFilter("value = 10");
}
namespaceManager.CreateSubscription(
    "myFooTopic",
    "seccondSubscription",
    ruleDescription);

We can have only the action or only the filter set. Also each rule can have a name set. In this way it is easier for us to edit a subscription. When we create or retrieve a subscription an object is returned that permit to add/remove/change any custom rule that we defined. In the same manner we can have more than one rule defined on a subscription.

var subscription = namespaceManager.CreateSubscription(
    "myFooTopic",
    " thirdSubscription");
subscription.Add(ruleDescription1);
subscription.Add(ruleDescription2);
subscription.Add(ruleDescription3);

The rules will be applied in the order that they were registered.
Maybe you have the following question? Does a message will be added to the subscription if one of the rules is not satisfied?
Yes, by default the TrueFilter is added. Any modification that is made to the message by the rule (using Action) will not be persisted to the topic – it will be persisted only to the subscription if the message is added.
Besides TrueFilter, we have also the FalseFilter. In this case, by default all messages are blocked and only messages that respect the rules are added to the subscription. To be able to change this, the first step after creating a subscription is to remove all the rules. After this step we can add our custom rules.

var subscriptionRules = namespaceManager.GetRules(
    "myFooTopic",
    "thirdSubscription");
SubscriptionClient subscription = messagingFactory.CreateSubscriptionClient(
    "myFooTopic",
    "thirdSubscription");

foreach (var rule in subscriptionRules)
{
    subscription.RemoveRule(rule.Name);
}

In the action of a subscription, it you want to access a value property from the current message you need to use “[sys]”. In the following example, I set a value of a property as sum of another two properties of the message.

RuleDescription ruleDescription = new RuleDescription()
{
    Action = new SqlRuleAction("set sum = [sys].ValueA + [sys].ValueB "),
    Name = “sumRule”,
}

Each of this subscription can have some custom property that can be set as expiration time, lock duration, the number of maximum delivery and so on. Using this functionality we can create a pretty complicated flow.
In this moment we can talk about how to receive messages from a subscription. Like Service Bus Queue we can receive message in two different ways: PeekLock and ReceiveAndDelete. For the first one a message is not removed until we don’t call the Complete() method of the message. Using the second one, a message is automatically deleted when is send to the received. Because of this if any error appear, the message will be lost. I recommend the first way if you want to consume messages in a safe way. To create a subscription client that is able to receive messages we need to specify the topic name, credentials and the subscription name. After this we can peak message from the subscription and consume them.

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

subscriptionClient.Receive();
BrokeredMessage brokeredMessage = subscriptionClient.Receive();

if (message != null)
{
    try
    {
        ...
        message.Complete();
    }
    catch (Exception)
    {
        message.Abandon();
    }
   }
}

In the above example we consume messages in PeekLock mode. At this level, all the action that we could do with Service Bus Queues can be made also with Service Bus Topics – they have the same base class MessageClientEntity and are using the same message (BrokeredMessage).
At the end we should know that: if we have two clients that we want to receive the same message with the same rules, that we need to specify to subscribers – one for each client. If we have a subscription, that can be consume by 2, 3 or n instances, that we should define only one subscription.
In conclusion receiving message from a Service Bus Topic can be a simple thing but in the same way a complicate one (defining the rules). Depends very much what we want to do. The good part of these rules is that they use the Sql92 standard implementation. Because of this we don’t need to learn how we need to specify each rule.

Read More

Service Bus Topics - How to use it (part 1)

In the last post we saw find out what is a Service Bus Topics. Next step that we should to do is to see how we can use it. From a lot of perspective, it is similar to Service Bus Queues.
The first thing that we need here is a Service Namespace. This is a unique named used to identify or service. The same namespace can be used for Service Bus Topics and Service Bus Queue without any kind of problems. To create a new namespace from the Azure portal, we should go Service Bus section. From there we have the possibility to create a new namespace. After the namespace is created we should be able to access it and see in the properties list the “Default Issuer” and “Default Key”. This information is needed to be able to consume and access a Service Bus Topics.
After we have the namespace created we need to configure the application to be able to access these services. In an application, this information can be stored in different locations, depending on our needs and preferences. The simplest one is to hardcode this value in our application, but is not the best one. If we create a website we can use configuration file of our web application to store this information.

<configuration>
    <appSettings>
        <add
                key="ServiceBusConnectionString"
value="Endpoint=sb://myFooNamespace.servicebus.windows.net/;SharedSecretIssuer=myFooIssuerName;SharedSecretValue=myFooDefaultKey" />
    </appSettings>
</configuration>

In the case you are working with a web-role or with a worker role, a good idea is to save this information in the service definition file (*.csdef and *.cscfg).

<WebRole name="FooWebRole" vmsize="Medium">
        <ConfigurationSettings>
            <Setting name="ServiceBusConnectionString" />
        </ConfigurationSettings>
</WebRole>

<Role name="FooWebRole"
        <ConfigurationSettings>
            <Setting name="ServiceBusConnectionString"
                     value=="Endpoint=sb://myFooNamespace.servicebus.windows.net/;SharedSecretIssuer=myFooIssuerName;SharedSecretValue=myFooDefaultKey"  />
        </ConfigurationSettings>
</Role>

Another possible solution is to store this information in a separately file, that can be consume by our application. In this case when we will create the instance of Service Bus Topics we will need to be able to specify this data. Basically, this information can be stored in any location from our application. We can even hardcoded this in our code – but please, don’t do this.
Remarks: If you read the posts about Service Bus Queues, you will notify that this configuration is the same. This happens because the entry point for Topics and Queues in Windows Azure are represented by the same “service”.
For creating a topic we have two options. We can create one from portal. We need to go to the portal, select our namespace from Service Bus and we will see that we have a new button there that permits us to create a new topic (or queue). It is not very insetting in this way. The other option is to create it from code.
From code, first of all we need to create a new instance of NamespaceManager. Yes, the same NamespaceManager that we used for Service Bus Queues. After this, we can create the Topic directly or check if it exists.

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

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

We should check if the topic already exists. Otherwise, a MessagingEntityAlreadyExistsException exception will be throwed by the service. Also, the name of the topic should respect the following rules:

• Character that are accepted are: ‘a’-‘z’, ’A’-‘Z’, ‘-‘, ‘.’, ‘0’-‘9’
• It should start with a character

If we want to specify some custom property to the topic, for example the TTL of the messages or the size of the topic, this can be done in the moment when we create the topic using TopicDescription.

TopicDescription topicDescription = new TopicDescription("myFooTopic")
{
    DefaultMessageTimeToLive = new TimeSpan(0, 1, 0)
};
...
namespaceManager.CreateTopic(topicDescription);

Creating a topic is quite simple. Creating a message for a topic is simple as well. We need to create a BrokeredMessage and send to the topic (yes, the same BrokeredMessage class that is used in Service Bus Queues – pretty cool). To handle a topic, we need to create a new instance of TopicClient.

TopicClient topicClient = TopicClient.CreateFromConnectionString(
    CloudConfigurationManager.GetSetting("ServiceBusConnectionString"),
    "myFooTopic");
BrokeredMessage message = new BrokeredMessage();
message.Properties["myCustomProperty"] = 1234;
topicClient.Send(message);

Receiving messages from Topics, is also simple, but before this we should talk about subscriptions and filters. This will be done tomorrow in more details.
In conclusion we saw how we can create namespace, Service Bus Topics and how we can send messages to these topics. Keep in mind that a message that is added to a topic is simple a BrokeredMessage.
Part 2

Read More

Service Bus Topics - Overview

This is the first post of a series of blog posts about Service Bus Topics. In this post we will see what Service Bus Topics is and what we can do with it.
Don’t let the name Topic intimidated you. This service, exposed by Windows Azure can be seen as a Service Bus Queues with steroids. The main feature of Service Bus Topics is the ability to publish a message to more than one subscriber (consumers). Each message sent to the Service Bus Topics goes a specific topic. Each topic is able to forward the message to each subscriber. We can imagine each subscriber has a private queue where the topic sends the message. All the messages sent to the topic will be received by each subscriber in the same order that were added to the topic.
The model of communication that is supported by Service Bus Topics is named publish/subscribe communication. This type of communication permits to have a communication from one-to-many. A message added to the topic will be received by all the subscribers.
One of the big advantages of using Service Bus Topics is scalability. Theoretically, we can have an unlimited numbers of subscribers to a topic. Each subscriber can be register/unregistered dynamically. Because of this it is very easy to reconfigure it.
One of the great functionalities of Service Bus Topics is the messaging filter. Each subscriber that is added to the topic can specify his own filters. Based on this filter we will receive the messages that validate his filter condition. Based on this, we can define “routing” schema for topics and subscribers. The filter expression is in SQL92 format – this SQL format is known by all of us and is very easy to use. But we will talk about this in another post.
Service Bus Topics are very similar with Service Bus Queues; I would say that topics are constructed over the queue. Because of this a lot of functionalities and features from the queue can be found to the topics also. For example the integration with WCF of the 4 properties of the Service Bus Topics that is valid also for Service Bus Topics:

• Loose Coupling – we can add, remove subscribers without affecting the rest of the system
• Load leveling – the topics can work in good conditions with load peaks and indirectly this peaks will be smoothed. The subscriber will not fell this peak.
• Temporal decoupling – the producer of messages don’t need to know about the subscribers. In the same time subscribers don’t need to be online all the time.
• Load balancing – a message can be consumer by more than one subscriber. The process of redirecting the message to each subscriber is resolved by Service Bus Topics.

In today post we saw what Service Bus Topics is. In the next post we will see how we can use it.

Read More

Where we can add resjson files in a Metro Application

In one of my latest post I wrote a short introduction about how we can support localization in a Metro Application for Windows 8. The current framework for Metro Application makes a great job. Today I want to discuss about resjson files.
This new extension was introduce with Metro Applications and help us to store all the strings that are localized in a very simple format (key, value) using json. In this case json is better than XML (when json is not better).
By default, when we create a Metro Application, a folder named strings is created in the root of our project. Under this folder we can create us many folders we want with a name convention [cultureName]-[regionName].

string
    en-US
        Resources.resjson
        Error. resjson
        payPage. resjson
    en
        Resources. resjson
        Error. resjson
        payPage. resjson
    fe-BE
        Resources. resjson
        Error. resjson
        payPage. resjson

I have the following question for you: How many strings folders can we have in an application? Does the resjson files need to be under the strings directory?
Basically, the strings folder is only a convention; we can have the resjson files under any directory structure. To be able to load the content from these files, the framework needs two important things:
Each resjson file need to have the “Content type” property set to “Resource”. This property can be accessed from the “Properties” tab of Visual Studio.
Each resjson file need to be under a folder that specifies the culture and/or region with the following format

 [cultureName]-[regionName]

If we respect these conventions, the framework will be able to load all this resources without any problem. Because of this we can end with a custom folder structure like this:

myProject
    payment   
        pages
            payPage
                payPage.html
                payPage.css
                payPage.js
            …
        …
        resources
            en-US
                pages.resjson
                errors.resjson

What we need to remember: We can have resjson file under any directory in our project. The only thing that we need to have is the parent directory of the resjson file in the custom format to specify the culture and/or region.

Read More

Service Bus Queues blog post series – a comprehensive look at Service Bus Queues from Windows Azure

In the last month I wrote a series of post about Service Bus Queues from Windows Azure. In this post I will summarize all the blog posts about Service Bus Queues that I wrote until now:

• Service Bus - Introduction to Service Bus of Windows Azure – a short introduction into Service Bus from Windows Azure

• Service Bus Queues from Windows Azure - Introduction – explain the base concepts of Service Bus Queues

• Service Bus Queues from Windows Azure - How to use it – presenting the base API that need to be used to access and use Service Bus Queues

• Service Bus Queues from Windows Azure - BrokeredMessage content – describe the BrokeredMessage class and what kind of data we should add to the messages from Service Bus Queues

• Service Bus Queues from Windows Azure - How to iterate – a small hack that can help us to make iteration possible in Service Bus Queues

• Service Bus Queues from Windows Azure - How to separate message or specify a consumer what types of message to consume –explain how to split a big data in separately messages and how to recreate it on the consumer side

• Service Bus Queues from Windows Azure - Death letter and poison messages – base concepts of death letter and poison messages on Service Bus Queues

• Service Bus Queues from Windows Azure - How to retry to consume messages and death letter –explain how we can write a code that can retry to consume messages from Service Bus Queues without creating an infinite look. Also an example on how we should consume messages from the sub-queue that stores the death letters

• Service Bus Queues from Windows Azure - Scheduling – a full example on how we can schedule a message to be available for the Service Bus Queues consumer only on a specific time

• Service Bus Queues from Windows Azure - Integration with WCF – presenting how we can integrate WCF to the Service Bus Queues and what we can gain from this

• Service Bus Queues vs Windows Azure Queues – a comparison between Service Bus Queues and Windows Azure Queues (similar but not the same – different objective)

• Service Bus Queues from Windows Azure - Business Scenarios – some business scenario when we can use Service Bus Queues with success

In the future I expect to write more about this subject. You can search on my blog for this topic using the following link: http://vunvulearadu.blogspot.com/search/label/service%20bus

Read More