by Bogdan Varlamov (a.k.a. Phantom Stranger)
I've often found myself working on a class in some legacy application using objects hidden away in third-party libraries and thinking, "Wow... it would be really great if I could call this current existing method but have it process asynchronously (without blocking) and then notify me when it is complete."
The only way to do this would be to inherit the legacy object and add a new "Async" version of the method, right? And what about those pesky sealed classes? Not to mention the problems with having to refactor your whole application (and perhaps any dependent components used by other applications).
It can be quite a mess! But, luckily there is a simpler way...
Would you like to know more?
One of my clients asked me to write a very simple RESTful web service to retrieve user data (name, email, address, etc.) based on login credentials. Having recently finished working on a PHP-driven RESTful interface for another client (based on the Zend Framework), I thought this would be a simple and straightforward task. As comedian Bill Engvall says: "Here's your sign!". I should have known better. Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
One of the great things about .NET 3.5 is that it is fully inter-operable with .NET 2.0. You just have to reference the right assemblies and you can use WPF and Windows Forms from the same application! This is great for slowly migrating a .NET 2.0 application over to .NET 3.5; all you have to do is add the new functionality while keeping your old .NET 2.0 logic. Once you are ready, you can slowly migrate your old code over into .NET 3.5 as needed.
Well...at least it's all that easy in theory; there's just one pesky little hiccup--a System.ExecutionEngineException...
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I recently ran into an issue with an application that was not detecting a physical network problem and was consequently losing data while attempting to write it to the socket.
I know what you are thinking. Sounds like poor programming; surely the .NET Socket class has a clean and Object Oriented way of handling network failures.
That is what I thought at first. The .NET Framework is filled with tons of goodies--namespaces with classes that make coding life easier. I am usually fairly satisfied with what is available in .NET (especially in .NET 3.5), but when it comes to the System.Net.Sockets namespace, there is just more to be desired.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
I've been doing a lot of work with .NET Sockets lately, and I will be posting more articles discussing what I've been working on in greater detail. In this article, I want to talk about the concept of reading a Socket asynchronously, raising events to notify your application when bytes are received, and minimizing the number of times the callback method is processed.
If you are familiar with .NET Sockets you might already know that there are asynchronous methods to receive bytes from Sockets (Microsoft has an Asynchronous Server Socket Example available if you are interested in seeing code for doing this).
In the above code sample, a StateObject class that contains a byte buffer with a static size is passed around. When the asynchronous socket read happens, incoming bytes are stored into this buffer and then passed back to the receive callback method. This example works fine, but I think there are some optimizations that can be applied.
Would you like to know more?
by Bogdan Varlamov (a.k.a. Phantom Stranger)
Do you have an application that starts misbehaving randomly? You aren't quite sure what is going on, but it seems like for some reason your Timer just stops firing it's event handler--and once it stops it never starts back up.
This drove me nuts! But, it is definitely a problem in the Windows Server 2003 SP1. This bug is particularly devious since even if your application uses extensive logging it maybe be nearly impossible to find proof of a timer not firing in your logs.
Short of implementing a Homer Simpson type of "everything is okay alarm" is there anything you can do to determine whether or not your application might be suffering from dying timers?
Would you like to know more?
So, I've been hoping to make a nice little generic encryption module that essentially just wraps the .Net System stuff. Why? 'Cause I'd like to move some data around with reasonable security (it doesn't have to be completely hacker-proof, just reasonably obscured -- the data I'm covering isn't worth that much, but it's worth more than zero so it deserves some due process.) This is done with that atitude, if you want hard-core encryption, then your better off not using a wrapper (set your .IV cleverly, don't resize improper-length keys, etc.) Alternatively, use an existing, clean, third party app (or write your own -- R4 is not too terrible to code and is very powerful, especially if you tweak it during the implementation).
Would you like to know more?
Share / Bookmark
