I'm the first to admit that the number of streams and serializing methods can be confusing. I wanted a quick and simple way to test my serialize code by persisting an object into a string. A quick google later and I had found a number of overly complicated examples, so here is my very simple method...
                        XmlSerializer serializer = new XmlSerializer(typeof(MyType));
            string resultingXml = null;
            using (StringWriter stringWriter = new StringWriter(CultureInfo.InvariantCulture))
            {
                serializer.Serialize(stringWriter, myObject);
                resultingXml = stringWriter.ToString();
            }

One of the seemingly lesser known features of Enums is their ability to convert to and from the name rather than the value, so I thought I'd do a quick refresher.

Consider the following Enum...
Medal.Bronze = 0
Medal.Silver = 1
Medal.Gold = 2

The majority of cases people leave it as an int (can be any non-char integral type). However, what happens when you want to store/persist the type? If I was to save this to a disk file I might choose to use XML and have a result like...
<Medal>2</Medal>
Then when I load the XML back I can easily convert it back...
Medal medal = (int)Convert.ToInt32("2");
However, I don't actually like this, the value of 2 has no real meaning to the reader, I'd much prefer to see
<Medal>Gold</Medal>
Well it is possible. To save the name rather than the value you can use ToString and a format string...
medal.ToString("G");
Reading the name back into the enum uses the often overlooked Parse method...
Medal medal = (Medal)Enum.Parse(typeof(Medal), "Gold");
Admittedly this doesn't solve localization problems of having XML, "human readable" but I prefer it.

I had written some code that implemented a particular interface where I only wanted to support a small set of the functions. So when I used Visual Studio's snippet I left the throw new Exception("Not yet implemented") alone. My ever knowing colleague explained to me that this was a known problem with the snippet and it should really use...
throw new NotSupportedException

I thought this was a great find since I hated raising such a woolly exception.

Today I hit an annoying problem with VB.NET using components written in C#. The basic problem is that I have an object called Field with a Value property of type object written in C#. The client code is written in VB.NET and wants to access the Field's value without specifying the Value property, e.g.

Dim myField as Field = new Field()
myField.Value = 13
...
If CInt(myField) = 13 or myField = 13...

The initial problem is that a Field is not an int, so you'll get an invalid cast, fair enough. So I implemented the implicit/explicit conversion operators available in C#.

Field myField = new Field();
myField.Value = 13
...
if ((int)myField==13)...

The above, written in C#, now works but the previous VB.NET still fails! The problem is that VB.NET simply doesn't call op_Implicit/op_Explicit functions exposed by the C# code. Delving into the Visual Basic engine you can see that under the covers it use IConvertable to do all of its conversions. So if you want VB.NET to understand that House = 7 really means House.Number = 7 then you need to implement IConvertable in the C# component.

After implementing IConvertable the above code sprang into life.

Finally managed to find a 1/2 decent code editor for the Mac (smultron) so I thought I port my Wake Up On Lan code to mono and run it on the Mac. What an annoying tool mono is. After using the tools of dinosaurs (Terminal) I asked the compiler to do its work. It came back with... (4, 255+) Expecting ';'. Well fine but what the **!* does that mean? I sort of assumed that it was column and row. So I went to the 5th line and stuck in some rubbish characters to confirm my theory... (1, 124) Expecting ';'. Eh? Now I understand why they don't supply some lovely rich IDE but I would hope that the compiler gives useful error messages not some random value that makes it impossible to use. Ok I'll look up the error codes, couldn't find any documentation on that. Off to the forums, surely I must just have something configured incorrectly. What forum, must be a community support. Nope some link to a commercial company. Ah here we go...an email list. What is this? A tool for the uber geek who takes pleasure in finding the most painful and awful way to communicate? I've half a mind to simply give up on this if "they" simply want to keep it a dark room project.

[Edit] A plus in Mono's column... Although the error message is still *rubbish* I finally discovered that I had some generics code and I was using the v1 compiler. So I downloaded the latest version of Mono and updated (nice that it updated the existing version) and used the gmcs compiler (v2) and the file compiled without problems, so expect a WOL for OSX in the near future.

I had my first real play with the Windows Presentation Framework (WPF). The first thing that struck me is how like the web model it is. For example, through the use of various services it provides the cascading down of properties and the bubbling up of events. So you can mark a grand-parent property, e.g. color, and if any child node doesn't specify a colour they'll automatically have their parents colour value. Similarly the event model is like the web.  You  fire an  event in a child element and the event can bubble up through all of its ancestors, any of which can handle the event.

I only managed a very quick play with the beta Visual Studio Add-in, created a quick "hello world" style application from a button click. I'm not sure if it's a clumsy beta or it going to work this way but I didn't get my nice event handler template by double clicking the button. Oh no, I had to guess at event handling code (almost identical to the usual one) and guess where in the Xaml I had to add the click attribute to wire-up the event. But it worked and I hope to have a longer play soon.

I've hit the problem of serializing a property for the last time. When you create a type that contains a non-serializable type, in my case a CultureInfo class, you cannot automatically serialize the type - you get issues about "does not contain a public constructor", "problem reflecting the type", etc. Unfortunately this isn't caught at compile time and you have to wait until an attempt is made to serialize the containing object. What to do about it? The more complicated choice is to write some custom serialization code, but really, most of the time I just want to serialize pretty simple objects. So my preference is to mark the class as serializable and let the client choose how to serialize it, i.e. via Binary or Xml "serializers". The framework provides a couple of attributes for this, and this is where the gotcha lives.

The first attribute, [NonSerialized], should be applied to field members and informs the standard serialization methods to ignore the field. The second attribute, [System.Xml.Serialization.XmlIgnore], should be applied to public properties and informs the Xml Serializer to ignore the property. The combination of the two should be enough to stop the field from being serialized regardless of the serializer the client chooses to use.
Quick pseudo example:

[NonSerialized],
private SomeUnFriendlyType myType:

[System.Xml.Serialization.XmlIgnore]
public SomeUnFriendlyType MyType()
....

Today I discovered, the hard way, that if you ask for a key value that doesn't exist in a generic dictionary you get an exception, whereas for specialised dictionaries (or your own derived ones) you get null. This was especially annoying has I have a load of code expecting null and a colleague changed the dictionary to a generic one. So I had to change the indexer to do a quick "contains key" to return null if the key doesn't exist.

Writing a file watcher program at the moment but I've hit a problem, I can't seem to discover who changed the file last. I'm sure Windows keeps the information but I can't find it. Ok, so the users can turn on file auditing so I guess it's no big deal but I can't help thinking I'm just missing something. The other bit of information I was trying to locate is the 'File Version' of a DLL. After following seemingly countless dead ends looking at FileInfo, FileAttributes, etc I discovered that that this information is...under System.Diagnostics!  Obvious really!?

Ok it is a strange title but...

One of my the most problematic areas of ASP.NET is the combination of Viewstate and the Page Life-Cycle. If you attempt to access the Viewstate before it's ready then not only do you get incorrect results for that call but you corrupt the state for subsequent calls too. So given that ASP knows where it is in the life cycle and that you're trying to access the state, why doesn't simply raise an exception? If nothing else it would save about 100Gb worth of forum posts!

In a similar vein I was working on a HtmlInputText control the other day and fell for another issue. As a good ASP developer I knew that the ID I've given the control will be changed to some odd unique name with lots of "ctl_" text stuck in-front of it. (If I say I want to uniquely name it and take that responsibility then it should only use my ID, grrrr). So I when I wanted to generate some Javascript to access the control I passed in myControl.ClientID. However, my Javascript failed saying the object was null. Odd. A quick review of the code I noticed that I was accessing the ClientID before I'd added the control to the page. Ok, that makes sense, but again why is the ClientID populated with the name of the ID only before it's been added to the page? Surely if you access the ClientID before the *page* has correctly populated it, then it should error? Oh well, just yet another pitfall to side-step.

Finally managed to write my first program on Mac OS-X thanks the Mono project. Unfortunately there isn't a simple (free) IDE for it yet (at least not without installing lots of odd Unix X-like components).  But anyway it was nice to see "hello world" appear in a Unix window all written in C#, I'm easily pleased!