Archiv der Kategorie: Slippery When Wet

Slippery When Wet #8: Parsing IP addresses in C#

I proudly present to you the eighth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

When I was trying to read some IP addresses from a CSV file I parsed them with the method IPAddress.Parse() from the System.Net namespace. Everything worked fine up to the eighth ip address. There the Parse method threw a System.FormatException: The format of the IP address was not valid. The IP address that caused the problem looked like ‚127.000.000.008‘. In my opinion this looked like a valid number, although it could be written a little bit shorter.

But Microsoft sees the world a little bit different. According to the answer by Mario Cossi on the problem description I found on social.msdn.microsoft.com this behaviour is completly valid, as all the numbers with leading zeros should be considered as octal numbers and therefore 008 is not valid, as 8 in not in the range of octal numbers. Mario writes that this is defined by standards, but does not refere to the standard where this is defined.

I did some more research but could not find the standard that describes this behaviour. What I did find were some older RFCs (like RFC 790) where IP addresses (or ranges) were written in the format with the leading zeros.

According to a wikipedia article and a therein referenced draft there is no defined standard for the textual representation of a IPv4 address.

In my opinion, the design decision of Microsoft is not the best. At least there should be a possibility to set the expected behaviour in case of a leading zero octet. Especially as the IP address 010.010.010.010 could be interpreted as 10.10.10.10 or 8.8.8.8 and you would not get an error as it would be in octal as well as in decimal a valid number.

As Microsoft did not give this possibility, according to your data you have to read, you should possibily use your own parsing method instead of the built-in one.

Slippery When Wet #7.1: Binding between XElement and ComboBox/ListBox Revisited

In Slippery When Wet #7: Binding between XElement and ComboBox/ListBox I wrote that the problem should be fixed with a hotfix from Microsoft. Meanwhile I’ve got the Hotfix installed on my System.

And the Hotfix solved the problem! So if you plan to use TwoWay binding between XElement objects and a ComboBox or ListBox get the Hotfix from Microsoft. According to the description the Hotfix should be included in a future software update. But in which update this fix will be included is not written there. So check the version numbers of the files listed in the description to see if you still need the Hotfix.

Note: According to the description installing the hotfix should not require a restart of the computer. But on the two Systems where we installed the Hotfix (one 32bit and one 64bit system) we had to restart both systems.

Slippery When Wet #7: Binding between XElement and ComboBox/ListBox

I proudly present to you the seventh in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

In Slippery When Wet #6: XPath and the Default Namespace I already ran in some problems with XML in .NET. And I’ve done it again!

For a dynamically built User Interface I’ve bound some controls to a XDocument tree that contained the data and the description of the types. The first controls (TextBox and a numeric Control) worked perfectly, so I was confident that the next controls would just be a routine work. So the next control I wanted to use was the ComboBox.

The data was shown as expected, but after changing the selection the new data was not saved. I’ve tried several changes in the binding (adding explicit two-way binding, setting the UpdateSourceTrigger to PropertyChanged) but the data was not updated when the selection changed. I’ve asked some guys in the office with more WPF experience, but they also saw no reason why the binding didn’t work. Even adding a Converter to check if the data types were not compatible gave me no clue. I’ve also asked on Stack Overflow but got no solution for my problem.

After asking Dr. Google the right question I’ve found these two entries in the MSDN Forum:
MSDN Forum: ComboBox that binds to XElement breaks in .NET 4 and
ComboBox and DataGridComboBoxColumn two-way data binding broken in .NET 4 with XLinq for the SelectedItem/SelectedItemBindings property
which guided me to the Hot Fix from Microsoft (The „TwoWay“ binding does not reflect changes when the property path of the binding refers to the Attribute or Element method of an XElement object in a .NET Framework 4.0-based WPF application).

So it looks like I’ve done it right this time but Microsoft didn’t. So now I’m waiting for getting the Hot Fix installed on my System to check if it works now.

Slippery When Wet #6: XPath and the Default Namespace

I proudly present to you the sixth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

Recently, I tried to work on a XmlDocument with XPath in C#. To get the right expressions easily I used the XML Spy from Altova. As soon as I got the right XPath expressions I started Visual Studio to work in my .NET Application. But here, the only expression that worked was „/*“. According to the .NET Documentation the expressions should work, but they didn’t.

So I tried another XML file, one from the examples in the .NET Documentation of XPath. And with this file the (corresponding) expressions worked as expected. So I searched the difference of the two XML files. After a short time I found the relevant difference: The file that worked had no namespace defined, whereas the non-working file had two namespaces. One namespace with a prefix (xmlns:prefix=“URI“) and a default namespaces (xmlns=“URI“).

As I got the reason for my problem I had to look for a solution. A little bit of googling brought me the solution. I had to add the default namespace to the NamespaceManager with a prefix and then use the XPath expressions with the defined prefix.

In .NET 3.5 Microsoft introduced the XDocument class as a alternative (or a replacement) for XmlDocument. The C# code differs a little bit depending on the used class. I found a description when using the XmlDocument class and two when using the XDocument class.

With the added prefix for the default namespace my XPath expressions worked as expected.

Slippery When Wet #5: The Process object or Optimization? don’t do it!

Slippery When WetI proudly present to you the fifth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

To get the memory usage information you can use the System.Diagnostics.Process class. As I wantet to check the memory usage regularly I kept the reference to the Process object in my class. But the value never changed anymore… Then I tried to get the Process object every time i needed the current memory size – and it worked.

So I read the documentation a little more carefully and got to this part:

The process component obtains information about a group of properties all at once. After the Process component has obtained information about one member of any group, it will cache the values for the other properties in that group and not obtain new information about the other members of the group until you call the Refresh method. Therefore, a property value is not guaranteed to be any newer than the last call to the Refresh method. The group breakdowns are operating-system dependent.

So I changed my code again to not get the Process every time I wanted the current memory size but call the Refresh method.

And what did we learn from this episode?

Michael A. Jackson („The First Rule of Program Optimization: Don’t do it (…)„) and Donald Knuth („(…) premature optimization is the root of all evil (…)„) are right. Don’t do optimization, especially not if you don’t really know what you are doing…

Slippery When Wet #4: this is it – the this keyword in Javascript

I proudly present to you the fourth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

Coming from the C++/C#/Java world, the ‚this‘ keyword is well known for accessing the instance of the class itself. For accessing members, it is not mandantory but often favored for clearness.

With this background, a first try could look like this (complete html page in the package, file this1.html):

var marc = {
    name: "Marc",
    hello: function(visitor) {
        document.write("Hello " + visitor + ", my name is " + name + "!")
    }  
}

window.onload = function()
{
    marc.hello("Peter");
}

And the output is:

Hello Peter, my name is !

OK, let’s try again!
We call the name property explicit (this2.html):

        document.write("Hello " + visitor + ", my name is " + this.name + "!")

And the output is, as expected:

Hello Peter, my name is Marc!

So, it’s a piece of cake, we have only to put the this keyword for all members, and we’re done…

Wait, not so fast, youngster!

Let’s try it with a function reference like in the next example (this3.html):

var marc = {
    name: "Marc",
    hello: function(visitor) {
        document.write("Hello " + visitor + ", my name is " + this.name + "!")
    }  
}

var greet = marc.hello;

window.onload = function()
{
    greet("Peter");
}

And the output is:

Hello Peter, my name is !

The name is lost again!

This problem occurs because JavaScript doesn’t support implicit binding in a way C++ and others do.

With calling the function through the function reference, the this inside the hello function points not to marc but to the window. To verify this thesis, we just add a name to the window:

var marc = {
    name: "Marc",
    hello: function(visitor) {
        document.write("Hello " + visitor + ", my name is " + this.name + "!")
    }  
}

var greet = marc.hello;

window.name = "Sue";

window.onload = function()
{
    greet("Peter");
}

And the output is:

Hello Peter, my name is Sue!

But how can we solve this problem? The two easiest solutions are apply and call:

var marc = {
    name: "Marc",
    hello: function(visitor) {
        document.write("Hello " + visitor + ", my name is " + this.name + "!")
    }  
}

var greet = marc.hello;

window.onload = function()
{
    greet.apply(marc, ["Peter"]);
    document.write("<br />");
    greet.call(marc, "Peter");
}

And the output is:

Hello Peter, my name is Marc!
Hello Peter, my name is Marc!

With apply and call, you do an explicit binding. The object you pass as the first argument (in our example marc) does not need to have the function itself, but should of course have the members that are used inside the function.
The difference of apply and call is only in the signature of the function. With apply, the parameter have to be passed inside an array. With call, the parameters are lined up after the explicit binding object.

This should give you some ideas to identify problems coming from the binding and some solutions to solve them.

For further reading i suggest the following articles:

Slippery When Wet #3: IIS Certification Authority Cache

I proudly present to you the third in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

For an Web Application I needed not only to check the user rights but also to limit the the allowed computers. For this I limited the access with a client certificate that has to be installed on the accessing computer.
At the beginning I used a free client certificate from Thawte, as the server certificate was also from them. This certificate was only valid for one year. So I had to renew this certificate every year and all allowed computers had to be updated.
But as Thawte ended their support for the free certificate I needed an other solution. I chose to use a self signed certificate as the client certificate but keep the server certificate from Thawte as on the server were also running other Web Applications that needed https.
So I created the Certification Authority (CA) certificate and a client certificate signed with this CA certificate with openssl. Testing with this certificates worked as it should. But for Testing purposes I used the default values for the validity length. So I created a new CA and a new client certificate with a longer validity period. After removing the testing certificates and installing the new created certificates I thought it will work as before, but the client certificate was not selectable in the client certificate selection dialog of internet explorer.
I tried several things like restarting IE, clearing the SSL cache and cursing. But nothing helped.
Analyzing the communication between client and server with openssl brought the solution: The Internet Information Server (IIS) was still using the old, already removed CA certificate, probably from his cache, but not the new one, maybe because the were named similar. After restarting the IIS on the server the new client certificate was selectable in the client certificate selection dialog of internet explorer.
Conclusion: After removing a (CA) Certificate from the IIS restart it to clear the cache!

Slippery When Wet #2: SCOPE_IDENTITY and SqlDataReader

I proudly present to you the second in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stubled on.

Imagine you have a database table with a cloumn id of the data type integer that has set the IDENTITY. You use a stored procedure to insert a new entry into this table. Inside this stored procedure you use the SCOPE_IDENTITY() function to get the identifier created for this row. With RETURN SCOPE_IDENTITY() you give the identity to the caller.

You call this stored procedure from a SqlComand with ExecuteReader() that returns you an SqlDataReader object.

From this SqlDataReader you read now the identifier with GetInt32().

Wrong !

This will give you an InvalidCastException. SCOPE_IDENTITY()’s return type is numeric, although your identifier column is an integer. SqlDataReader’s GetXY functions do not convert the data and throw the exception when the data is not already of the right type.

The first solution

You can read the value with GetDecimal() and cast the value to an int:

int identifier = (int)reader.GetDecimal(0);

The second solution

You cast the identifier inside the stored procedure und return it already as an integer:

SELECT CAST(SCOPE_IDENTITY() AS INT)

Whatever solution you choose, take care that you use always the same inside your application.

Slippery When Wet #1: Javascript’s GetMonth()

I proudly present to you the first in a infinite number of posts of „Slippery When Wet.“ In these posts I show you a little bastard I stubled on.

I had to reformat a date in Javascript. There were all this little nice functions of a date object like

getFullYear(), getHours(), getMinutes()

and also

getMonth()

. Every of these functions returned the value as it would also be shown, but not getMonth(). getMonth() returns a value from 0 to 11, so 0 is January, 1 is February and so on untill 11, that is December.

I see a possible reason for this: With values from 0 to 11 you can use the value directly as the index for an array with the month names inside, like

alert(months[myDate.getMonth()]);