Everyone knows that an easy way to represent binary data in a normal ASCII, is to use Base64. Most people also know about the Convert.ToBase64String() and Convert.FromBase64String() methods in the .NET Framework. But how do you use this knowledge to convert any (serializable) object to/from a string, in as few lines of code as posssible?

Well, most (if not all) solutions I found on the net are making things a lot more complicated than they should be. So I decided to write my own and share it with you:

The 20-line Base64 Serializer/Deserializer

public static class Base64Serializer
{
    public static string Serialize(object obj)
    {
        using (MemoryStream memStream = new MemoryStream())
        {
            new BinaryFormatter().Serialize(memStream, obj);

            return Convert.ToBase64String(memStream.ToArray());
        }
    }

    public static T Deserialize<T>(string s)
    {
        using (MemoryStream memStream = new MemoryStream(Convert.FromBase64String(s)))
        {
            return (T) new BinaryFormatter().Deserialize(memStream);
        }
    }
}

•

When a software tester comes up to your desk and complains about a bug, and you have no idea what to tell him, just use the following list and pick a number:

1. This has always worked fine...
2. I didn't change anything...
3. It works here!
4. Weird, I tested this!
5. My unit tests were all green!
6. Are you using the latest build?
7. ... probably changed the code.
8. I've never seen this error before...
9. That's not my code!
10. I think this has never worked before...
11. The database changes probably haven't been done yet.
12. Was that included in the functional design?

As Dave Barry would say: I swear I'm not making this up! The "excuses" in this list are taken from what I hear every day. Sometimes they even make sense :)

•

ProMesh.NET, the .NET MVC Web Framework I released in the "open" last month is still waiting for it's first real released version. It's actually ready to go, but something is holding me back: documentation. Sadly, writing documentation is a tedious process, which always takes longer than you'd like...

In the world of intellisense-assisted code editors, documentation has become less important than in the past, but I personally think it is absolutely necessary to have proper documentation for a library/framework, be it commercial or open-source.

On the other hand, after looking at some other open-source .NET libraries out there, I start to wonder if it would be better to just "officially" release it and worry about documentation in the weeks after. An awful lot of (more or less) successful open-source frameworks seem to have little or no useful documentation. In many cases, documentation is updated after a release has been published (sometimes weeks or months later).

So I'd like to hear your opinion on this one. What's the best strategy?

1. Release now and publish the full documentation later when it's done
2. Release now and publish the current state of the documentation (while continuing adding documentation)
3. Wait until the full documentation is done.

•

Let me just say that I am pretty impressed by what Miguel De Icaza and the other Mono guys have accomplished by creating Mono.

I have never been impressed by Linux and I am not surprised by the slower than expected adoption of the operating system, despite huge efforts by Novell and Red Hat. To me, the main reason is the lack of standardization in the different distributions. Setting up and configuring a Linux system is never the same. Different vendors use different front-ends (Gnome vs KDE), the file systems are organized differently, boot procedures are totally different, ...

But, I have always been intrigued by Mono, the .NET platform for Linux which is "sponsored" by Novell. Mono has always been pretty up-to-date by implementing new .NET stuff and compiler features as soon as (or sometimes even sooner than) Microsoft made them publicly available

I was a little curious to see how ProMesh.NET (MVC Web Framework for .NET 2.0) would run on Mono (if at all), so I did the following:

• Download the VMWare image with a pre-installed Mono installation on SUSE Linux 10.2
• Download VMPlayer (free)
• Copied the latest ProMesh.NET source tree to the virtual machine
• Fired up MonoDevelop
• Compiled the framework... Works (well, it compiled)
• Copied the ProMesh.NET demo application to the virtual machine
• Compiled the demo app... Works!
• Started xsp2.exe (the lightweight .NET web server for Mono)
• Opened the index.ashx page using FireFox: WORKS
• Went through the complete demo site. Everything worked!

I was utterly amazed by the painless process of compiling and running a ProMesh.NET application on Mono, something I've never tried before (I did have some previous experience with MonoDevelop, but not a lot).

This is pretty exciting stuff, knowing you can just grab your ProMesh.NET web application, dump it on a Linux box and run it from a Linux web server.

Mono team: good job!!

•

This article may be extremely obvious to many people, but I am sure a lot of C# developers will be surprised by what will follow.

What's the difference between

MyType myObject1 = (MyType) anotherObject;

and:

MyType myObject2 = anotherObject as MyType;

Well, when "anotherObject" is assignable to MyType, both lines of code do the exact same thing, but when "anotherObject" is not of the correct type, the assignment to "myObject1" will throw an exception, but the second line of code will run fine and "myObject2" will be null.

Surprised? I was too, but it's in the C# specs.

FYI, the type cast is compiled to the "castclass" IL instruction, while the "as" version is compiled to the "isinst" instruction. Two different beasts

•