Windows Azure and type initializer for 'System.ServiceModel.Diagnostics.TraceUtility' threw an Exception

I've been working on a new product that I'm with Windows Azure and today whilst I came to debug a WCF service within it stumbled apon an error that at first glance doesn't make a whole lot of sence, but with a bit of working backwards turns out is quite simple to fix.

The scenario: I have a WCF service setup to run in a WorkerRole as part of an Azure solution, pretty simple.

To enable me to see what was going on clearer with my service i decided to configure my system.diagnostic listeners and added the default AzureLocalStorage listener, which is created automatically for you, to my service model and message logging.

<system.diagnostics>    
    <sharedListeners>
      <add name="AzureLocalStorage" type="ServiceAuthenticationGatewayWorkerRole.AzureLocalStorageTraceListener, ServiceAuthenticationGatewayWorkerRole"/>
    </sharedListeners>
    <sources>
      <source name="System.ServiceModel" switchValue="Verbose, ActivityTracing">
        <listeners>
          <add name="AzureLocalStorage"/>
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
        <listeners>
          <add name="AzureLocalStorage"/>
        </listeners>
      </source>
    </sources>
   </system.diagnostics>

However upon running the application nothing would happen for around 30 - 60 seconds and then I was greeted with a nice TypeInitializationException.

Viewing the detail of this and the inner exceptions eventually led me to the following message:
{"Could not create xxxxxWorkerRole.AzureLocalStorageTraceListener, xxxxxxxx."}

So the AzureLocalStorageTraceListener was blowing up on type initialisation, popping open the code you see that the constructor does some work, specifically it gets the log directory of the WCF log file and combines the filename and path etc.

This looked normal, I put a breakpoint in and stepped through the GetLogDirectory method to find which line threw, my guess would be its where it calls into the RoleEnvironment and gets the local resource. Turns out this is exactly where it threw.

I had a quick gander at MSDN and found that you pass the local resource name to the method you want to load. This led me to think that the resource wasn't defined so next up was the storage configuration.

With Azure you configure local storage per role, to change the settings right click the worker role within the main Azure project, it will be in a folder called roles and open properties. You will then get a screen similar to what I had.

You will note, as I did, considering I thought I had local storage and was accessing it via the key, it wasn't setup within the role properties :(

Simply using the Add Local Storage button and entering the correct details let the project startup and start logging correctly.

What I found here is another case where the framework gives you the generic error message and not the exception that was really being thrown, RoleEnvironmentException which would have made me look at the local storage settings a lot quicker.

Any way there it is, I hope this helps :)

Tidying up user data for display

Today I was tidying up a quick WPF application i had built for a client. It simply renders "today's schedule" in a way that is meaningful for them and allows them to view it on multiple screens and print as necessary.

Development was quick as it only consumed several Google Calendar feeds and based upon my test data worked well.

However today seeing used in real life made me rethink how i rendered the data, in my test data I entered items how I would enter them, this is important, I entered them using sentence casing for paragraphs, title casing for titles etc. However due to the way some of the users worked everything was being entered in CAPS :(

Functionally the app works fine, however for me, and I'm no designer, it looked odd. So I opened the solution again and started to look at ways of improving this. My initial thoughts were to apply some sort of styling, think text-transform:capitalize; if you were using CSS, but alas XAML doesn't have this. I then thought I could implement a custom formatter that I could use in the XAML upon databinding, I could have done this, but I chose not too. Although it makes sense to do so, I started thinking about how I will probably end up using the data access / domain code in this project later on in another GUI where I will no doubt have the same problem.

As a result I wanted to "fix" this data at the domain level in C#. As soon as you hit the code you know there are many ways of achieving this, you could go down the route of RegEx replacing, iterating through the string looking for .'s or whitespace if you want title case etc and then do some replacing. You could even just specify everything is lowercase, but for me none of these fully fitted what I wanted / effort level I wanted to put in for an issue that only I really had.

What I really wanted was a ToTitleCase or ToSentanceCase that already exists the framework, I didn't want to go grab extension methods which I'm almost certain there will be many of. A quick bit of poking around led me to this gem.

TextInfo.ToTitleCase

I refer to MSDN the ToTitleCase method "Converts the specified string to titlecase." Great, exactly what I wanted. It's easy to use too:

// Defines the string with mixed casing.
      string myString = "wAr aNd pEaCe";

      // Creates a TextInfo based on the British culture.
      TextInfo myTI = new CultureInfo("en-GB",false).TextInfo;

      // Changes a string to titlecase.
      Console.WriteLine( "\"{0}\" to titlecase: {1}", myString, myTI.ToTitleCase( myString ) );

Fantastic, build, run, enjoy.....
Well kinda.... This is one method you really do need to read the remarks for on the MSDN page,

this method does not currently provide proper casing to convert a word that is entirely uppercase, such as an acronym.

and

the ToTitleCase method provides an arbitrary casing behavior which is not necessarily linguistically correct. A linguistically correct solution would require additional rules, and the current algorithm is somewhat simpler and faster. We reserve the right to make this API slower in the future.

This actually meant that in my case, when people added descriptions entirely in uppercase the method did nothing. Bit of a shame, I made the conscious decision that Titles I would use ToTitleCase in the hope to improve titles where people enter one with all lower case or mix use, but if they use entirely uppercase then I am unfortunate. However for descriptions I decided to lowercase the string and then use ToTitleCase. Now this isn't sentence casing but it does look better than all caps. This is a compromise, I was able to improve the app without spending too much time on it.

ToTitleCase is one of those hidden gems, (just like using XmlConvert.ToString with a DateTime will give you the DateTime in RFC 3339 which is fantastic for use with Google Calendar API's etc... but that's a blog post for another day ... ), which can save you time and provide quick wins, it's also culture sensitive which can really help you out if you have a globalised project, just be clear on what it does and what it doesn't do.

Enjoy

Tricky times using the MVC3 Date Validator and JQuery UI DatePicker

Today I came across a strange problem whilst seemingly writing a simple MVC3 prototype. My prototype had a textbox for a date value which I then used jQuery UI to append a date picker too. I was also using unobtrusive validation and data annotations on my models to seemingly "speed up" developing my prototype.

Although I thought I had wrote everything correctly whenever I tried to submit my form in Chrome I was getting a random error: Please enter a valid date. Originally I had suspected I had messed up the date time formatting, as I was using en-GB format, not the default en-US. Much time wasted and many things I tried had no effect.

I then by chance loaded the page in Internet Explorer only to find the issue had "vanished", so I went back to Chrome and nope it was back. Upon double checking my code I pondered if using the classname of "date" on my element could cause problems and a bit of Googling confirmed this. In short don't apply a date picker to an element with a class name of "date" otherwise Chrome gets all confused. I believe this is due to the page being HTML5 and the way Chrome parses elements etc, but for now I don't need to know too much about that ;)

Hurrah everything works again and only x amount of time wasted :(

Resharper 6.1 EAP throws an exception upon load

Last night I updated my ReSharper 6.1 EAP extension within VS 11 Developer Preview, I was several builds behind and thought it best to try and stay in sync.

Updating is easy enough, however upon restarting Visual Studio I was finding Resharper was throwing exceptions on load and wanted to send information about them "home".

I decided to look at the "detailed information" that shows the stack trace and found the following:

Could not load file or assembly 'JetBrains.ReSharper.UnitTestFramework, Version=6.1.13.115

It turns out that this was happening in the xunit contrib plugin I had loading for Resharper so I could run my XUnit tests within its runner.

For now I rolled back by Resharper version until I get chance to either get the source for XUnit Contrib and fix the issue or someone else does it for me :)

Passing Objects between Silverlight Applications

This week I have been making some prototype applications using Silverlight, which has been awesome, and I decided that I wanted to pass a few objects between these applications. If this wasn't a quick prototype and didn't have to run off of a Sales person's laptop I would have whipped together a quick bit of RIA Services and got them talking that way. However these are just two out of browser applications.


Enter Local Messaging.

Silverlight has a great little feature, that I'm not sure is too often used, Local Messaging. Local Messaging allows you to send simple string messages between two Silverlight applications running on a local computer. This can be within the same Web Page or two Out of Browser Applications

Local messaging works by having a LocalMessageReciever listening for messages in one application and then a LocalMessageSender sending messages from the other. If you want two way communication you simply have a listener and sender in each application.

// In the receiving application:
LocalMessageReceiver messageReceiver = new LocalMessageReceiver("receiver");

// In the sending application:
LocalMessageSender messageSender = new LocalMessageSender("receiver");

I'm not going to explain how you send messages between the applications as MSDN does a far better job of doing so. However MSDN only talks about simple string messages, I wanted to send objects.


Serialising the objects

The obvious solution I thought was to just serialise the objects to a string and then back at the other end. Silverlight doesn't support binary serialisation and as we have to send the message as a string the Serialisation could be XML, which is common practice and I'm sure most people know instinctively how to do so, however XML is bloated. Alot of our message string would be information we aren't interested in. Now in most applications we don't worry about this and XML is fine however this local app messaging has a maximum string size of 40 kilobytes. We don't want to fill this up with XML notation, instead we want something alot leaner.

Although Silverlight doesn't support Binary Serialisation it does however support JSON. JSON is a far less verbose markup which will mean our messages will be more about the object data and structure rather than syntax which is a good thing

When it comes to JSON serialisation there are a few options, the built in DataContractJsonSerializer , JSON.Net etc. For the ease of setup I have gone for using the build in DataContractJsonSerializer. Here i take a generic object and serialise it to a stream which we can then use in our message.

DataContractJsonSerializer serialiser = new DataContractJsonSerializer(message.GetType());
var stream = new System.IO.MemoryStream();
serialiser.WriteObject(stream, message);

With this string we can simply use a streamreader to get the string that our sendasync message sender method requires.

 new System.IO.StreamReader(stream).ReadToEnd())

But there's a problem, we cant just send the json object, as at the other end we won't know the type. What we have to do then is send the type and the serialised form. This leaves us with the following:

stream.Position = 0;
sender.SendAsync(String.Format("{0}|!|{1}", message.GetType(), new System.IO.StreamReader(stream).ReadToEnd()));

Note: I have used |!| as a way to know where the type name ends and the stream begins, I could have said {type}={jsonserilaisedobject} but I chose not too, for neatness though this should be possible I just chose to use a delimiter I knew wouldn't appear in my serialised object.

Receiving the message and getting the object back

To get the object back in the other application, after receiving the message from the sender we have to split the string based on the delimeter and then deserialise the object.

var type = e.Message.Substring(0, e.Message.IndexOf("|!|"));
var data = e.Message.Substring(e.Message.IndexOf("|!|") + 3);

The DataContractJsonSerializer requires a stram not a string to deserialise an object so next take the data string and turn it into a stream. Then just deserialise.

var stream = new System.IO.MemoryStream(System.Text.Encoding.UTF8.GetBytes(data));
var serialiser = new DataContractJsonSerializer(Type.GetType(type));
if(type == "OurCustomType"){
    var result = (OurCustomType)serialiser.ReadObject(stream);
}

And that's it, obviously handling lots of types would mean not using an if statement, maybe a switch or whatever but the principle is the same.
I hope you find this of use, it certainly made my prototype far more functional and proved a neat way of doing it