Pitfall « of bits and bytes

Archiv für die Kategorie ‘Pitfall’

Slippery When Wet #6: XPath and the Default Namespace

Freitag, 18. Mai 2012

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.

Tags:.NET, C#, Namespace, Slippery When Wet, SWW, XML, XPath
Abgelegt in .NET, English, Pitfall, Slippery When Wet, XML | 2 Kommentare »

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

Samstag, 12. November 2011

I 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…

Tags:.NET, Slippery When Wet, SWW
Abgelegt in .NET, English, Pitfall, Slippery When Wet | Keine Kommentare »

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

Samstag, 11. Oktober 2008

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()]);

Tags:Javascript, Slippery When Wet, SWW
Abgelegt in English, Pitfall, Slippery When Wet | Keine Kommentare »

Exception after sending data async from a thread

Samstag, 24. Mai 2008

If you have a situation like this:

void MyThreadFunc()
{
// do some work

socket.BeginSend(buffer, 0, buffer.Length, 0, new AsyncCallback(MyCallback), s);
}

void MyCallback(IAsyncResult ar)
{
Socket s = (Socket) ar.AsyncState;
s.EndSend(ar);
}

And you send a big buffer over a slow connection it can happen that calling EndSend() will throw a SocketException ‘The I/O operation has been aborted because of either a thread exit or an application request’.

This happens because the Thread that started the sending is no more available when the sending ends. The only solution I know is to make sure the thread is still available or to use syncronous sending if possible.

Abgelegt in .NET, English, Pitfall | Keine Kommentare »

Exception “No web service found at:” with /js or /jsdebug

Freitag, 09. März 2007

With “ASP.NET 2.0 AJAX Extensions 1.0″ (I love this name with two version numbers inside…) you can request a JavaScript Proxy for a web service with appending /js or /jsdebug to the web service path, like “http://my-server/my-service.asmx/js”.

When I deployed my application I’ve got the InvalidOperationException “No web service found at:”. When I called the web service without /js or /jsdebug the web service worked (at least the generated forms in the Browser where shown).

I’ve spent a lot of time ’til I recognized the File my-service.asmx was not included in the deploy package. So without the /js appended the my-service.asmx file was not needed, the code from the compiled dll was executed directly, but when I added /js it needed the file.

Conclusion:
Don’t forget to add the .asmx files in the deployment of your ASP.NET AJAX Project!

Abgelegt in .NET, ASP.NET, English, Pitfall | 1 Kommentar »

Ambiguous match found nach Publishen der ASP.NET Webseite

Mittwoch, 27. September 2006

Beim Entwickeln einer Web-Anwendung bin ich über eine Eigenart von ASP.NET 2.0 gestolpert. Beim Testen auf dem lokalen Rechner lief alles wie gewünscht. Nach dem Publishen der Webseite erhielt ich dann aber den Fehler:

Ambiguous match found

Als Fehlerzeile war die erste Zeile mit der

@Page

-Direktive angegeben.

Nach einigem Suchen im Internet fand ich bei Peter Johnson den Blog-Eintrag Ambiguous match found, der mich auf das Problem aufmerksam machte:

Innerhalb meiner Seite hatte ich ein hiddenField mit der ID

MyIdentifier

und eine

protected

Member-Variable mit dem Namen

myIdentifier

. Diese beiden Variablen lebten während dem Entwickeln in friedlicher Koexistenz, nach dem Publizieren der Webseite vertrugen sie sich aber nicht mehr. Leider liefert das Visual Studio weder während des Entwickelns noch beim Publizieren irgendwelche Warnungen oder Fehler. Nachdem ich

myIdentifier

theIdentifier

umbenannt hatte lief dann alles reibunglos.

Abgelegt in .NET, ASP.NET, Deutsch, Pitfall | Keine Kommentare »

Fehlendes ImageUrl bei asp:image erzeugt unerwünschtem Seitenaufruf

Dienstag, 26. September 2006

Stundenlang habe ich gesucht, bis ich den Fehler gefunden habe:

Unter bestimmten Umständen wurde meine Seite bei einem Postback erneut aufgerufen, aber mit

IsPostBack == false

. Bis ich dann herausgefunden habe, dass es am

asp:image

Tag liegt. Wenn das Attribut

ImageUrl

nicht angegeben wird, wird das Tag image mit einem leeren

src

Attribut erzeugt, was den Browser dazu veranlasst, als Bild die Seite laden zu wollen. Dies erzeugte den nicht gewünschten Seitenaufruf. Nachdem ich ein leeres Bild als Standardbild angegeben habe, passiert dieser unerwünschte Seitenaufruf nicht mehr.