Just a short code snippet that helped me recently:

public static string SerializeTableToString(
    DataTable table )
{
    if (table == null)
    {
        return null;
    }
    else
    {
        using (var sw = new StringWriter())
        using (var tw = new XmlTextWriter(sw))
        {
            // Must set name for serialization to succeed.
            table.TableName = @"MyTable";

            // --
            // http://bit.ly/a75DK7

            tw.Formatting = Formatting.Indented;

            tw.WriteStartDocument();
            tw.WriteStartElement(@"data");

            ((IXmlSerializable)table).WriteXml(tw);

            tw.WriteEndElement();
            tw.WriteEndDocument();

            // --

            tw.Flush();
            tw.Close();
            sw.Flush();

            return sw.ToString();
        }
    }
}

Hopefully it is useful for someone out there, too.

Merke: Um eine versehentlich umgestellte Tastatur von Englisch auf Deutsch zu ändern, die Tastenkombination

Strg+Umschalt+1

drücken.

Passiert mir öfter mal pro Anwendung, dass ich das verstelle.

Introduction

Today I faced a strange issue; I was catching an Exception in a BackgroundWorker’s thread, threw a new exception and handled it in the main GUI thread by showing the exception’s Message in a message box.

The strange thing was, that no matter what I did, the main GUI thread always displayed the message of the first generated exception in the background thread.

Cause

As described by user „nobugz“ in this discussion, the cause is:

This is an architectural limitation to the way exceptions are marshalled from one thread (the BGW’s) to another (the UI thread).  Only a single exception object can get copied, the designers chose the first one thrown as the most likely to be relevant.  You’ll need to work around this restriction.

Interestingly enough this behavior seems to occur only in an Application.ThreadException handler which seems to pick up the exception from somewhere (maybe TLS?)

Resolution

The resolution is to handle the exception directly in the RunWorkerCompleted handler where it gets forwarded to and not to throw the exception any further, until the Application.ThreadException handler of the GUI thread handles it.

Example application

To show the error in a small example project I created a tiny Windows Forms application which you may download from here.

Main Window with erroneous Behavior

When the check box is activated, the erroneous behavior is being performed when clicking the button:

The first generated exception is being displayed to the end user instead the actual one that is being thrown later in the background thread.

Main Window with expected Behavior

When the check box is not activated when clicking the button, the expected result is being displayed; the latest thrown exception:

Summary

I’ve just shown you a case where (in my eyes) the .NET Framework behaves wrong.

Maybe you find this article useful or even prove that I am wrong or how to handle in a more elegant way.

Looking forward for your feedback!

Fehlermeldung

Beim Laden aus einer XML-Datei erhielt ein Kunde unseres CMS Zeta Producer folgende Fehlermeldung:

System.UriFormatException

—————–

Invalid URI: The hostname could not be parsed.

—————–

at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind)
at System.Xml.XmlResolver.ResolveUri(Uri baseUri, String relativeUri)
at System.Xml.XmlUrlResolver.ResolveUri(Uri baseUri, String relativeUri)
at System.Xml.XmlTextReaderImpl..ctor(String url, XmlNameTable nt)
at System.Xml.XmlDocument.Load(String filename)
at Zeta.EnterpriseLibrary.Tools.Storage.PersistentXmlFilePairStorage.load()
at Zeta.EnterpriseLibrary.Tools.Storage.PersistentXmlFilePairStorage.set_FilePath(FileInfo value)
at ZetaProducer.RuntimeBusinessLogic.Code.AppHost.Host.InitializeInstance()
at ZetaProducer.RuntimeMain.Code.AppHost.Host.InitializeInstance()
at ZetaProducer.Main.Code.AppHost.Host.InitializeInstance()
at ZetaProducer.Main.Code.AppHost.Host.process()

Ursache

Ursache war, dass der Kunde Parallels unter Mac OS X verwendet hat um Zeta Producer in einer virtuellen Maschine laufen zu lassen.

Gleichzeitig lagen die „Eigenen Dateien“ auf Mac OS X und wurden via Parallels in die virtuelle Maschine eingebunden.

Der Pfad war sichtbar als:

\\.psf\Home\Documents\Zeta Producer 9

Damit scheint die Uri-Klasse von .NET nicht zurecht zu kommen.

Lösung

Eine schnelle Lösung aus Anwendersicht ist, den UNC-Pfad „\\.psf\Home\Documents\Zeta Producer 9“ als Laufwerksbuchstaben unter Windows zu verbinden und dieses Laufwerk dann als Home-Ordner zu konfigurieren.

Eine programmierte Lösung wird so aussehen, dass ich das Laden eines XmlDocument selbst durchführe (via Stream) und dann den geladenen Stream (bzw. die Zeichenfolgen als string) an das XmlDocument übergebe. So umgehe ich die Uri-Klasse, die wohl mit UNC-Pfaden die mit „.“ beginnen Schwierigkeiten hat.

Dieser Artikel ist für mich als Referenz, weil ich es immer wieder mal recherchiere.

HOWTO: Text mit .NET/C# aus einer Textdatei lesen

1. Möglichkeit: Microsoft-Knowledge-Base-Artikel How to read a text file by using System.IO and Visual C#.

2. Möglichkeit: So wie in der MSDN-Dokumentation beschrieben: How to: Read Text from a File.

In aller Kürze:

string line;
using (var sr = new StreamReader("TestFile.txt"))
{
    line = sr.ReadToEnd();
}

// ...do something with line...

Ich hoffe es hilft mir und Euch da draußen mal.

The number of bytes for the Byte Order Mark („BOM“) differs among the used encodings.

public static bool IsBomRelevantEncoding(
    Encoding encoding,
    out int bomSizeBytes )
{
    if ( encoding == Encoding.Unicode )
    {
        bomSizeBytes = 2;
        return true;
    }
    else if ( encoding == Encoding.UTF32 )
    {
        bomSizeBytes = 4;
        return true;
    }
    else if ( encoding == Encoding.UTF8 )
    {
        bomSizeBytes = 3;
        return true;
    }
    else if ( encoding == Encoding.UTF7 )
    {
        bomSizeBytes = 4;
        return true;
    }
    else
    {
        bomSizeBytes = 0;
        return false;
    }
}

References:

• „Byte order mark“ in Wikipedia
• System.Text.Encoding in the MSDN documentation