Daniel Turini's Lair

Firefox 1.5 does not install

2005-12-01T10:23:00.000-02:00

Sigh... Does everybody has problems like me with software? I stumble across, say, 10 or 20 software bugs each day.
Now, it was the new Firefox installation. It simply didn't start. It fails silently, and so fast that it doesn't even appear on task manager.
Reinstalling the old Firefox 1.0.7 brought it back to life, but I wanted the new Firefox so badly (although I don't know why :) )
Finally, I found a good soul, James Ross, that managed to solve the problem:

To fix any build in this situation, do this:
1. Make sure you're logged in with full permissions on the install folder.
2. Delete all components\*.xpt files EXCEPT browser.xpt.
3. Delete compreg.dat.
4. Make sure .autoreg exists in the firefox.exe folder.
5. Start Firefox.

Now, the problem is relatively simple - the components directory has the
contents of a non-static Firefox build [1] in it. I don't know for sure if
mozilla.org ever released such a build, but I'm willing to bet most other
builds are non-static (all builds were this by default until very recently).

Interestingly, though, all the XPTs are dated 9th Nov 2004, which *is* when
Firefox 1.0 was originally released.

So, I have a question for everyone with this problem: did you ever install a
version that was not an official mozilla.org release?

[1] In a static build, all the XPT files are bunched in to one (browser.xpt),
rather than having lots of little ones with different names.

Answering his question, I installed MOOX optimized builds in the past. It seems that MOOX managed to corrupt something.

SELECT MAX(NULL) FROM DUAL;

2005-07-18T14:51:00.000-03:00

Never do that.
Actually, never SELECT MAX(col) FROM tab where col is a NULLable column on an Oracle client. Oh, and don't forget that an empty string is a NULL on Oracle.
It seems that the .NET framework has a bug, and, when you do this, you'll get a NullReferenceException from the .NET Oracle provider.
Weird.
Time to review all my SELECT MAX, SELECT MIN and convert from:
SELECT MAX(col) FROM tab
to
SELECT MAX(col) FROM tab WHERE col IS NOT NULL

I just keep running on weird errors

2005-07-11T12:27:00.000-03:00

The Web server reported the following error when attempting to create or open the Web project located at the following URL: 'http://localhost/MyWebApplication1'. 'HTTP/1.1 500 Internal Server Error'.
Two hours later: we had an internal change on our network a few weeks ago, and the user/password on the processModel tag on MACHINE.CONFIG file was wrong. As you can see, I wasn't using ASP.NET so much...
I'm yet to see an IDE that gives less information than VS.NET when connecting to IIS...

I love Portland Patterns Repository

2005-06-29T14:53:00.000-03:00

It seems that my idea of Firefighting simulations were already invented. There are two patterns on the PPR, one is Defect Seeding and the other is Mutation Testing. It seems that my firefighting simulation is exactly the Defect Seeding pattern and Mutation Testing is a technique for automatically changing programs and finding unit test failures.
Well, maybe some day I invent something that was not already invented. But I still think it may be useful here, and probably we'll start using it.

Little known, powerful APIs

2005-06-27T17:11:00.000-03:00

Today, I'm working with an Exchange Event Sink. This article is an invaluable source for starting things. It may not be complete, but I'd spend at least two weeks digging the Exchange SDK to accomplish the same thing.
What I'm trying to do is a better integration between Exchange and Microsoft CRM. If this works, I'll publish it as an article. Microsoft CRM 1.2 standard e-mail support sucks: it needs a GUID on the subject with every message, it has no way of importing messages, the Exchange router is rudimentary at best.
For me, an obvious way of integrating Microsoft CRM and Exchange would be: for every e-mail that comes to CRM accounts, lookup the CRM based on the e-mail address and associate it with the proper contact. Either I'll discover that this is a stupid way for some reason, or I'll come up with something better than Microsoft did. I rarely bet I can do anything better than MS, but this time I'm pretty sure of this...
And what does this have to do with "Little know, powerful APIs"? The lesson here is: never underestimate those lesser known APIs, like Exchange APIs. Some of these APIs are very powerful, and you can produce some powerful software. Since those APIs are known only by a few programmers, often you can produce softwares with very little competition, if any.

Firefighting training simulations for testing code

2005-06-20T15:48:00.000-03:00

I was watching this documentary about a new super cool firefighting training simulator, which was affordable enough that even small companies could use and that was very effective in detecting failures in firefighting procedures. Those failures, on real world situations, could lead to disasters, causing injuries and even deaths.

So, an idea stroke me: what if we did the same thing in software world?

I'll explain: most decent software companies now have a well-defined software testing process. But how can we detect problems on those testing procedures?
Let's say we stopped a bit every now and then to make a bug detection simulation.

One or two programmers would be responsible for intentionally introducing bugs that could cause a disaster. Only those programmers would know which bugs were introduced. The idea is making things fun, like a game, where those programmers try to break the testing process and the testing staff try to find those bugs as quickly as possible.

A summary of the simulation would be:

Establish a time limit for the simulation. There's no point in the exercise if it takes months to run. The idea is running it in around the same time it takes to assess if a build should go to the customer or not. If all the bugs are found too quickly, new bugs should be introduced.

One or two programmers check-in some code that introduces some bugs. The more serious and disastrous the bugs are, the better. The harder to detect they are too, the better.

Those programmers may be allowed to alter the unit tests to make those bugs go unnoticed during the build process. I like the idea of being able to alter unit tests because that's what happens when you change specifications.

Without taking a look at the source code, the testing team will try to find those bugs.

All the other programmers may also help the testing team to find those bugs.

After finding (or not) the bugs and finishing the simulation, a few things should be assessed:

How fast did we detect those bugs?

Did we use the same procedures or did we need to employ new procedures?

Should we introduce new test procedures?

How many other bugs we found in the process? If we found bugs that were not part of the game, why didn't we find them before? What could we have done to find them?

My own Daily WTF

2005-06-17T15:12:00.000-03:00

What would you think of a programmer that coded an abstract class as a concrete class, and, instead of marking a few members abstract, implemented them as virtual and threw a "NotImplementedException"?
Well, I can imagine your face, and yesterday I was strugling again with System.Net.WebRequest and its memory leaks, trying to implement a new HttpWebRequest that used only WinHTTP to eliminate memory leaks definitively from every WebServices call we have. The funny thing is: WebRequest is a class coded like that. Someone at MS certainly think it's brilliant coding like this, and throws NotImplementedException on their code, instead of marking their members abstract.
A friend of mine here insisted that MS is not that bad at coding (and I do agree), and that there should be a good reason for that.
Today, I was reading my RSS feeds, and I found this post at The Daily WTF, describing a similar situation...
Sorry for my friend, but I really don't think that there's any good use for something like this.

It's been a long time...

2005-06-17T15:03:00.000-03:00

Since I last posted... But this blog is not abandoned, only neglected :)
The truth is that I assumed the responsibility for both the sales and technical departments, and I was really tied to lots of meetings and understanding how I could make things work better, specially with our sales staff. Selling, instead of purely programming, is a new thing for me, and it's being great to grasp some sales concepts and gaining experience in another area. I've been programming since I was 11, this means that I am programming for 23 years as of now. I never worked with anything else, and go to sell my own software is a great experience, as I hear a lot of good things from our customers.
But I still code a lot, and I'll update more this blog from now on…

It must be me.

2005-02-14T09:32:00.000-02:00

I must have some kind of magnet inside my computer that attracts weird .NET framework bugs. Now, it's a random "The underlying connection was closed: An unexpected error occurred on a (send/receive)", when calling web services under stress.
I googled a lot and I couldn't find something that solved my problem. Sure, I found a lot about HTTP Keep-alives and about proxies that dump the connection, but:

I tried the KeepAlive = false solution, and it didn't work, as expected - MS says that solved this problem in one of the service packs.

Proxies are not my problem. I am not passing through a proxy, neither accessing a remote machine. All the calls are being done on the same machine: the web service is simply a way for doing calls from a service to an ASP.NET application - kind of a sophisticated RPC

No exception is being thrown at the server side, and nothing appears on the Event Viewer

I must be doing something wrong. The trouble is: what? Crivo is quite sophisticated (over 220 projects), and this web service is a façade for calling this code. Anything can be the source of the problem. And I can't believe that web services are that troublesome and not scalable to this point (I'm doing only 8 parallel calls).

Sigh... It will be a long debugging and stress-testing week.

I want to be a good programmer... How???

2005-02-10T15:49:00.000-02:00

Yesterday, I was talking at CodeProject's Lounge, and someone asked about how to become a good programmer. It's actually a very good question, and I gave him the following answer:

As with anything, time is the key. As the time passes, and you code, you'll get better. Don't expect to become a decent programmer in less than 4 years

Find pet projects - even if you don't code a lot at college or at work, you can always get better by developing a project that you like. Don't worry if you will or won't be able to finish the project, and don't be scared about the size of the project. Even if you don't go too far in the project, you'll learn a lot

You'll make a lot of mistakes, like we did. And you'll learn from that. More than you'll learn from things you think you did right

Read a lot the programming forums and newsgroups. Read every message: there are all kinds of programmers there, often with the same problems you'll face

Try to find a more experienced programmer to tell you if your code is good or not (and why!). If you can't, use us on the forums. Post small pieces of code and ask "is there a better way of doing this?" or "can you suggest me style improvements?"

Talking about style, programming is all about style. Don't dismiss a better solution just because "my code is ugly, but it just works"

Start with a simpler, but robust language. I strongly suggest you to start with C# or Java. Forget about C++, VB, VB.NET, Perl, Python, etc, until you're better and can understand why

Read a lot about "best practices": this way your path will be shorter, as you won't spend time doing the same mistakes we did

Read a lot of books. Even those cheap "Learn * in 21 days" can be good for starters, but after a while, try to find better books

After a year programming, read a lot about OOP. This year without OOP will teach you why OOP is important

After a year of OOP programming, read a lot about design patterns. This year without design patterns will teach you why design patterns are important

Google is your friend. You need to be a Google master. Any good programmer should be able to find the needed information quickly

Don't be ashamed to try things: "What if I cast this double variable to a char * ?". After you see things like this not working, try to understand why

Karl suggested that I made this an article. I like the idea, and probably I'll expand those items and add a few other items.

Exception Handling Best Practices in .NET

2005-02-09T20:37:00.000-02:00

"My software never fails". Can you believe it? I'm almost hearing you all, screaming that I'm a liar. "Software that never fails is something near to impossible!"
Contrary to common belief, creating reliable, robust software is not something near to impossible. Notice that I'm not referring to bug-free software, intended to control nuclear power plants. I'm referring to common business software, which can run unattended on a server, or even a desktop machine, for long periods of time (weeks or months) and work predictably without any significant glitch. By predictably, I mean that it has a low failure rate, you can easily understand failure conditions to fix it quickly, and it never damages data in response of an external failure.
In other words, software that is stable.
Having a bug in your software is forgivable, and even expected. What's unforgivable is having a recurring bug you can't fix because you don't have enough information.
To understand better what I'm saying, I've seen countless business software that, in an out of disk space error in the DBMS, reports something like this:
"Could not update customer details. Contact the system administrator and try again later".
While this message may be an adequate of reporting an unknown resource failure to a business user, all too often this is the whole debugging information that is available to debug the error cause. Nothing was logged, and understanding what is happening will be time-consuming and often programmers will guess a lot of possible causes until they find the real error cause.
Notice that in this article, I will concentrate only in how to make a better use of .NET exceptions: I won't discuss how to properly report error messages, because I believe this belongs to UI domain, and it depends heavily on the interface being developed and the target audience; a blog text editor targeting teenagers should report error messages in a way completely different than a socket server, which will only be used directly by programmers.

Plan for the worst

A few basic design concepts will make your program much more robust, and will improve the user experience in the presence of an unexpected error. What do I mean by "improve the user experience in the presence of an unexpected error"? It's not that the user will be thrilled by the marvelous dialog box you'll show him. It's more about don't corrupting data, don't crashing the computer, and behaving safely. If your program can pass through an out of disk space error without doing any harm, you improved the user experience.

Check it early

Strong type checking and validation are powerful tools to prevent unexpected exceptions and to document and test code. The earlier in execution you detect a problem, the easier is to fix. Trying to understand what a CustomerID is doing on the ProductID column on the InvoiceItems table after a few months isn't fun neither easy. If you used classes for storing customer data, instead of using primitives (e.g., int, string, etc), chances are that the compiler would never allow you to do such a thing.

Don't trust external data

External data is not reliable. It must be extensively checked. It doesn't matter if the data is coming from the registry, database, from a disk, from a socket, from a file you just wrote or from the keyboard. All external data should be checked and only then you can rely on it. All too often I see programs that trust configuration files because the programmer never thought that someone would edit the file and corrupt it.

The only reliable devices are: the video, the mouse and keyboard.

Anytime you need external data, you can have the following situations:

Not enough security privileges

The information is not there

The information is incomplete

The information is complete, but invalid

It really doesn't matter if it's a registry key, a file, a socket, a database, a web service or a serial port. All external data sources will fail, sooner or later. Plan for a safe failure and minimize damage.

Writes can fail, too

Unreliable data sources are also unreliable data repositories. When you're saving data, similar situations can happen:

Not enough security privileges

The device isn't there

There's not enough space

The device has a physical fault

That's why compression programs create a temporary file and rename it after they're done, instead of changing the original one: if the disk (or even the software) fails for some reason, you won't lose your original data.

Code Safely

A friend of mine often says: "A good programmer is someone who never introduce bad code in his projects". I don't believe that this is all that it's needed to be a good programmer, but surely it will put you almost there. Below, I compiled a list of the most common "bad code" that you can introduce in your projects, when it comes to exception handling.

Don't throw new Exception()

Please, don't do it. Exception is a too broad class, and it's hard to catch without side-effects. Derive your own exception class, but derive it from ApplicationException. This way you could set a specialized exception handler for exceptions thrown by the framework and another for exceptions thrown by yourself.

Don't put important exception information on the Message field

Exceptions are classes. When you return the exception information, create fields to store data. If you fail on doing it, people will need to parse the Message field to get the information they need. Now, think what will happen to the calling code if you need to localize or even just correct a spelling error in error messages. You may never know how much code you'll break by doing it.

Put a single catch (Exception ex) per thread

Generic exception handling should be done in a central point in your application. Each thread needs a separate try/catch block, or you'll lose exceptions and you'll have problems hard to understand. When an application starts several threads to do some background processing, often you create a class for storing processing results. Don't forget to add a field for storing an exception that could happen or you won't be able to communicate it to the main thread. In "fire and forget" situations, you probably will need to duplicate the main application exception handler on the thread handler.

Generic Exceptions caught should be published

It really doesn't matter what you use for logging - log4net, EIF, Event Log, TraceListeners, text files, etc. What's really important is: if you caught a generic Exception, log it somewhere. But log it only once - often code is ridden with catch blocks that log exceptions and you end up with a huge log, with too much repeated information to be useful.

Log Exception.ToString(); never log only Exception.Message!

As we're talking about logging, don't forget that you should always log Exception.ToString(), and never Exception.Message. Exception.ToString() will give you a stack trace, the inner exception and the message. Often, this information is priceless and if you only log Exception.Message, you'll only have something like .

Don't catch (Exception) more than once per thread

There are rare exceptions (no pun intended) to this rule. If you need to catch an exception, always use the most specific exception for the code you're writing.
I always see beginners thinking that good code is code that doesn't throw exceptions. This is not true. Good code throws exceptions as needed, and handles only the exceptions it knows how to handle.
As a sample of this rule, look at the code below. I bet that the guy who wrote it will kill me when he read this, but it was taken from a real-world example. Actually, the real-world code was a bit more complicated - I simplified it a lot for didactic reasons.
The first class (MyClass) is on an assembly, and the second class (GenericLibrary) is on another assembly, a library full of generic code. On the development machine the code ran right, but on the QA machines, the code always returned "Invalid number", even if the entered number was valid.

Can you say why this was happening?

public class MyClass
{
    public static string ValidateNumber(string userInput)
    {
        try
        {
            int val = GenericLibrary.ConvertToInt(userInput);
            return "Valid number";
        }
        catch (Exception)
        {
            return "Invalid number";
        }
    }
}

public class GenericLibrary
{
    public static int ConvertToInt(string userInput)
    {
        return Convert.ToInt32(userInput);
    }
}

The problem was the too generic exception handler. According to the MSDN documentation, Convert.ToInt32 only throws ArgumentException, FormatException and OverflowException. So, those are the only exceptions that should be handled.
The problem was on our setup, which didn't include the second assembly (GenericLibrary). Now, we had a FileNotFoundException when the ConvertToInt was called, and the code assumed that it was because the number was invalid.
The next time you write "catch (Exception ex)", try to describe how your code would behave when an OutOfMemoryException is thrown.

Don't ever swallow exceptions

The worst thing you can do is catch (Exception) and put an empty code block on it. Never do it.

Cleanup code should be put in finally blocks

Ideally, since you're not handling a lot of generic exceptions and have a central exception handler, your code should have a lot more finally blocks than catch blocks. Never do cleanup code, e.g., closing streams, restoring state (as the mouse cursor), outside of a finally block. Make it a habit.

One thing that people often overlook is how a try/finally block can make your code both more readable and more robust. It's a great tool for cleanup code.
As a sample, suppose you need to read some temporary information from a file and return it as a string. No matter what happens, you need to delete this file, because it's temporary. This kind of return & cleanup begs for a try/finally block.

Let's see the simplest possible code without using try/finally:

string ReadTempFile(string FileName)
{
    string fileContents;
    using (StreamReader sr = new StreamReader(FileName))
    {
        fileContents = sr.ReadToEnd();
    }
    File.Delete(FileName);
    return fileContents;
}

This code also has a problem when an exception is thrown on, e.g., the ReadToEnd method: it leaves a temporary file on the disk. So, I've actually saw some people trying to solve it coding as this:

string ReadTempFile(string FileName)
{
    try
    {
        string fileContents;
        using (StreamReader sr = new StreamReader(FileName))
        {
            fileContents = sr.ReadToEnd();
        }
        File.Delete(FileName);
        return fileContents;
    }
    catch (Exception)
    {
        File.Delete(FileName);
        throw;
    }
}

The code is becoming complex and it's starting to duplicate code.

Now, see how much cleaner and robust is the try/finally solution:


string ReadTempFile(string FileName)
{
    try
    {
        using (StreamReader sr = new StreamReader(FileName))
        {
            return sr.ReadToEnd();
        }
    }
    finally
    {
        File.Delete(FileName);
    }
}

Where did the fileContents variable go? It's not necessary anymore, because we can return the contents and the cleanup code executes after the return point. This is one of the advantages of having code that can run after the function returns: you can clean resources that may be needed for the return statement.

Use "using" everywhere

Simply calling Dispose() on an object is not enough. The "using" keyword will prevent resource leaks even on the presence of an exception.

Don't return special values on error conditions

There are lots of problems with special values:

Exceptions makes the common case faster, because when you return special values from methods, each method return needs to be checked and this consumes at least one processor register more, leading to slower code

Special values can, and will, be ignored

Special values don't carry stack traces, and rich error details. There are performance reasons, too

All too often there's no suitable value to return from a function that can represent an error condition. What value would you return from the function below to represent a "division by zero" error?

    public int divide(int x, int y)
    {
        return x / y;
    }

Don't use exceptions to indicate absence of a resource

Microsoft recommends you to use return special values on extremely common situations. I know I just said the opposite and I also don't like it, but life is easier when most APIs are consistent, so I recommend you to adhere to this style with caution.
If looked at the .NET framework, and I noticed that the only APIs that follow this style are the APIs that return some resource (e.g., Assembly.GetManifestStream method). All those APIs return null in case of the absence of some resource.

Don't use exception handling as means of returning information from a method

This is a bad design. Not only exceptions are slow (as the name implies, they're meant only to be used on exceptional cases), but a lot of try/catch blocks in your code makes the code harder to follow. Proper class design can accommodate common return values. If you're really in need to return data as an exception, probably your method is doing too much and needs to be split.

Use exceptions for errors that should not be ignored

I'll use a real world example for this. When developing an API so people could access Crivo (my product), the first thing that you should do is calling the Login method. If Login fails, or is not called, every other method call will fail. I throw an exception from the Login method if it fails, so the calling program cannot ignore it.

Don't clear the stack trace when re-throwing an exception

The stack trace is one of the most useful information that an exception carries. Often, we need to put some exception handling on catch blocks (e.g., to rollback a transaction) and re-throw the exception. See the right (and the wrong) way of doing it:

The wrong way:

       try
        {
            // Some code that throws an exception
        }
        catch (Exception ex)
        {
            // some code that handles the exception
            throw ex;
        }

Why is this wrong? Because, when you examine the stack trace, the point of the exception will be the line of the "throw ex;", hiding the real error location. Try it.

       try
        {
            // Some code that throws an exception
        }
        catch (Exception ex)
        {
            // some code that handles the exception
            throw;
        }

What has changed? Instead of "throw ex;", which will throw a new exception and clear the stack trace, we have simply "throw;". If you don't specify the exception, the throw statement will simply rethrow the very same exception the catch statement caught. This will keep your stack trace intact, but still allows you to put code in your catch blocks.

Avoid changing exceptions without adding semantic value

Only change an exception if you need to add some semantic value to it - e.g., you're doing a DBMS connection driver, so the user doesn't care about the specific socket error, the user wants only to know that the connection failed.
If you ever need to do it, please, keep the original exception on the InnerException member. Don't forget that your exception handling code may have a bug too, and if you have InnerException, you may be able to find it easier.

Exceptions should be marked [Serializable]

A lot of situations needs that exceptions are serializable. When deriving from another exception class, don't forget to add that attribute.

When in doubt, don't Assert, throw an Exception

Don't forget that Debug.Assert is removed from release code. When checking and doing validation, it's often better to throw an Exception than to put an assertion in your code.
Save assertions for unit tests, for internal loop invariants, and for checks that should never fail due to runtime conditions (a very rare situation, if you think about it).

Each exception class should have at least the three original constructors

Doing it is easy (just copy & paste the definitions from other exception classes) and failing to do that won't allow users of your classes to follow some of these guidelines.
Which constructors I am referring to? The last three constructors described on this page.

Don't reinvent the wheel

There are lots of good frameworks and libraries to deal with exceptions. Two of them are provided by Microsoft and I mention here:

Exception Management Application Block

Microsoft Enterprise Instrumentation Framework

Notice, though, that if you don't follow strict design guidelines, like those I showed here, those libraries will be nearly useless.

VB.NET

If you read through this article, you'll notice that all the samples I used were in C#. That's because C# is my preferred language, and because VB.NET has a few guidelines of its own.

Emulate C# "using" statement

Unfortunately, VB.NET still doesn't have the "using" statement. Whidbey will has it, but until it's there, everytime you need to dispose an object, you should use the following pattern:

        Dim sw As StreamWriter = Nothing
        Try
            sw = New StreamWriter("C:\crivo.txt")
            ' Do something with sw
        Finally
            If Not sw is Nothing Then
                sw.Dispose()
            End if
        End Finally

If you're doing something different when calling Dispose, probably you're doing something wrong, and your code can fail and/or leak resources.

Don't use Unstructured Error Handling

Unstructured Error Handling is also known as "On Error Goto". Prof. Djikstra did it very well in 1974 when he wrote "Go To statement considered harmful". It was more than 30 years ago. Please, remove all traces of Unstructured Error Handling from your application as soon as possible. "On Error Goto" statements will bite you, I'll assure you.

Conclusion

I hope that this article helps someone to code better. More than a closed list of practices, I hope that this article be a starting point for a discussion of how to deal with exceptions in our code, and how to make our programs more robust.
I can't believe that I wrote all of this without any error or controversial opinion. I'd love to hear your opinion and suggestions about this topic.

And they said to you "no one will do drivers in .NET"

2004-09-03T08:57:00.000-03:00

Ok, it's only the control center, but it's a start... And it's from ATI, what means that soon any machine with an ATI card will have the .NET framework installed.

Via Patrick Steele's .NET Blog

GMail

2004-09-03T08:17:00.000-03:00

Thanks to David Stone, I'm a proud GMail user. Since I run my own Exchange server, the 1GB is not my primary interest (although I have some friends that loved it!). Most of my interest on it is learning how to do a lightining-fast, cleanly designed, cross browser UI.
If you are interested in a Google mail account, Google gave me 12 invites, and I already spent 6 of them. If you want it, drop me a comment or an e-mail with your e-mail address (don't forget to obfuscate it, beware of spambots) an your name, and I'll invite you.
[Update: now only 3 to go...]

SoapInclude & XmlInclude

2004-09-01T08:51:00.000-03:00

Yesterday, I coded a webservice that needed to return an array of objects that derived from a common base (abstract) class. When I tried to access the webservice, I had the following message:

The type XXX.YYY was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.

I thought: "Doh! Sure! ASP.NET needs to know about all the concrete classes, not only about the base class to be able to generate a proper WSDL, so a proper proxy client can be generated. Simple! Just add a SoapInclude(typeof()) attribute for each of the concrete classes and there we go!".
And so I did it. It didn't work.
I copy & pasted the MSDN sample for the SoapInclude attribute. It didn't work.
I tried it on a machine without SP1. It didn't work.
I tried to add the SoapInclude() attribute on the base class. It didn't work.
On a desperate try, I remove all the SoapInclude() attributes and used XmlInclude() attributes (remember the error message)? Yeah! It worked!
So, I leave this for anyone who may have the same problem and find me through Google or who can explain me why the SoapInclude() attribute didn't work.

Installing .NET 1.1 SP1 and Resharper 108

2004-09-01T08:41:00.000-03:00

You can find Microsoft .NET Framework 1.1 Service Pack 1 here and a version for Windows Server 2003 here.
I installed it yesterday and it required a reboot (probably because I was running RSS Bandit, coded in C#). After the reboot, my Resharper trial (build 108) didn't work anymore, giving me a strange HRESULT.
My solution:
When VS.NET asked about removing Resharper, I chose "No". Then, I removed Resharper through "Add/Remove Programs" and reinstalled it. Everything went back to normal.
And why am I saying this? While everything seems fine with my software, it tastes bad. Something in .NET SP1 installation broke Resharper, a .NET application just like mine. Why? What broke? It's hard to say that Jetbrains did something wrong on Resharper that would break on a service pack installation (contrary to Vault, which used a poor design decision). Sooner or later (probably when this gets into Windows Update), my customers will upgrade to SP1 and this may happen to them. We have people testing our software under SP1 (heck, even my machine is running it), but I won't feel comfortable until a lot of people upgrade.

I installed XP SP2

2004-08-10T09:13:00.000-03:00

So far, nothing broke. I had a pretty stable installation before this, and now, too. I've had two GPFs with zip folders (and didn't in XP SP1), but it seems to work. IE6 seems way better, but I really don't use it for navigation anymore, only for a bit of ASP.NET development (I only use Firefox for navigation, as I'm addicted to tabbed browsing, mouse gestures and adblock).
My software used some popups for drill-down in reports, and had those windows blocked. Exception lists are just two clicks aways, so, it won't be a problem.
The firewall asked me if RSS Bandit should be allowed to navigate, and while it seems to be the correct behavior, it didn't ask the same thing for AVG antivirus. Maybe it's something I didn't understand yet about it.

A weird bug - This time I don't know where, but solved it

2004-08-05T11:01:00.000-03:00

I'm deploying this Windows Forms application, which is actually a simple, but pretty text editor with some features like Intelissense and syntax highlighting. The application was tested on lots of environments and still, it managed to not work on any of the customer's computers. The culprit was the following innocent line:

MyFont = new Font("Courier New", 10);

Strange as it may seem, it was throwing the following exception:

************** Exception Text **************
System.TypeInitializationException: The type initializer 
for "ICSharpCode.TextEditor.Document.FontContainer" threw an exception. ---> 
System.ArithmeticException: Overflow or underflow in the arithmetic operation.
   at System.Drawing.Font.Initialize(FontFamily family, Single emSize, 
FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
   at System.Drawing.Font.Initialize(String familyName, Single emSize, 
FontStyle style, GraphicsUnit unit)
   at System.Drawing.Font..ctor(String familyName, Single emSize)

After a lot of Googling I found this KB article which mentions a similar problem and a possible solution. It was pretty close to the solution, but it didn't work. It seems to be some other software or driver interfering with my .NET application. I blame it on their anti-virus, as we tested it on lots of different hardware and software configurations (notebooks, desktops, developer machines) and none of them worked, but the same corporate anti-virus was present at all of these machines.
Since I cannot tell them to disable their anti-virus, lots and lots of desperate Googling (and the customer in need of the application), what I ended up doing was:

try
{
    DefaultFont = new Font("Courier New", 10);
}
catch (ArithmeticException)
{
    ResetFPU();
    DefaultFont = new Font("Courier New", 10);
}

where ResetFPU stands for:

[DllImport("msvcr70.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int _controlfp(int n, int mask);

const int _RC_NEAR       = 0x00000000;
const int _PC_53         = 0x00010000;
const int _EM_INVALID    = 0x00000010;
const int _EM_UNDERFLOW  = 0x00000002;
const int _EM_ZERODIVIDE = 0x00000008;
const int _EM_OVERFLOW   = 0x00000004;
const int _EM_INEXACT    = 0x00000001;
const int _EM_DENORMAL   = 0x00080000;
const int _CW_DEFAULT    = ( _RC_NEAR + _PC_53 +
    _EM_INVALID + _EM_ZERODIVIDE + _EM_OVERFLOW + _EM_UNDERFLOW +
    _EM_INEXACT + _EM_DENORMAL);
    
static void ResetFPU()
{
    _controlfp(_CW_DEFAULT ,0xfffff);
}

I hope this helps someone in the future...

Switched to a full RSS feed - Dog Food

2004-07-27T09:39:00.000-03:00

It may seem weird, but I did not try my own Atom Feed until today. When I saw it, I noticed: it was ugly, without formatting, without the source code, and incomplete. I changed a simple setting on Blogger.com and then, bang! Instant full RSS feeds, with colors, fonts, links and all the text!
I hope this does not be a hassle, but I love reading full RSS feeds, so I thought this switch was a Good Thing.

FlexWiki installed

2004-07-26T11:13:00.000-03:00

We are already using CVS, NAnt, NUnit and Bugzilla for quite a long time and we have a very good history with these tools. They're solid rock stable, useful, and some are even intuitive (e.g., Bugzilla). Bugzilla was a bit strange to setup, mainly because I do play a bit with Linux, but I'm by no means a Linux wizard.
People here liked Bugzilla so much that they started to create bugs in it just to document some internal knowledge and procedures (e.g., "how to setup a new build machine").
So I installed FlexWiki. It took me around 10 minutes to download and setup it.
We're still moving all the scattered documentation to the Wiki, but it seems great. FlexWiki have a few bugs, but at least until now, nothing seems so serious that makes it not be a great tool to use.

Where did my code go?

2004-07-24T07:09:00.000-03:00

A few weeks ago, I was teaching a bit of modern OO design to a fellow programmer (a bit of UML, design patterns, code smells, refactor, etc), who is one of the best programmers I've ever knew (he coded so many things other people named "impossible" that one has to respect that). For a series of reasons, he never really did a whole OO design, and he needed to design this big system, with around 50 classes. One of the difficulties was that he was having a bad time, trying to understand where all the code he was originally planning to do gone. All those huge methods he was planning to do had simply disappeared! Now, he basically had a few, very small methods (the biggest was around 10 or 20 lines of code), and the logic was scattered all over the place! He could clearly see that the design was right, and that the final code would probably work, but he was with that constant feeling that "we left something out of this", "the code can't be that simple", and so on.
And why I am talking about all of this? I'm reading Fowler's "Refactoring: Improving Design of Existing Code", and here is something I'd like to quote:

The object programs that live best and longest are those with short methods. Programmers new to objects often feel that no computation ever takes place, that object programs are endless sequences of delegation. When you have lived with such a program for a few years, however, you learn just how valuable all those little methods are. - Martin Fowler

Well, at least is nice to see that other people experience the same things.

More about the HttpWebRequest/HttpWebResponse leaks

2004-07-21T10:32:00.000-03:00

Steve Binney contacted me through e-mail and provided some feedback about the .NET HTTP infrastructure leaks I've (actually, everyone have) been having. The two last e-mails I had from him provided some very useful observations about the bug:

Email #1

Daniel,

I decided to be brave and install .Net 1.1 SP1 on my laptop. Unfortunately, the leaks still seem to be there. In Reflector, I have verified the HttpWebResponse/Request still have the leaks.

Steve

Email #2

To clarify my observations:

On the released version of .Net 1.1 and .Net 1.1 sp1 beta:

My app makes one synchronous HttpWebRequest/HttpWebResponse per second on a single thread. My handle count starts at 200 and ramps up to approx. 1200 before automatic GC kicks in. Memory (private bytes) start at 7 mb and quickly ramps to 20 mb before leveling off. The memory slowly creeps up after that. On a few occasions, the memory quickly increased to 60 mb but I cannot reproduce this. Calling gc.Collect stops the handle leak but has no effect on memory.

On VS 2005 Beta 1, .Net 2.0 beta 1:
Memory and handles are constant at (< 200 handles) and (18 mb). Using reflector, I see that the HttpWebRequest/HttpWebResponse clean up the
event handles created by internally calling begin/end async methods.

Steve

I have mixed feelings about this input: while it's very good news that VS 2005 does not have the same leaks, I feel a bit frustrated that this bug is not fixed yet in the .NET 1.1 SP1.
Steve and I also posted this on microsoft.public.dotnet.framework, but by Feroze feedback I feel it'll be a long, long run until a solution. Feroze didn't even seem to have looked at or tried the 10-line code snippet I posted. Probably I'll be using .NET 2.0 before that is fixed...

Boo

2004-07-21T07:42:00.000-03:00

No, I'm not talking about the little girl from Monsters, Inc. I'm talking about Rodrigo Barreto de Oliveira's work on a new language called Boo, defined as a "wrist friendly language" on its manifesto. Boo borrows some ideas from other languages (e.g., "duck typing" is nothing more than the old "late binding"), but introduces several new concepts (at least, new to me):

Extensible compilation pipeline: you can extend the language by implementing a visitor

Syntatic macros: it's not really new, but I didn't see anything like this since Clipper 5.x preprocessor, which allowed you to create your own keywords

Syntatic attributes: cool idea, similar to syntatic macros

Delegates are simpler than in C# and VB.NET: you can treat any function as an object

Automatic return type inference: only to save a little typing, but it's clean

String interpolation: Rodrigo surely coded in Clipper in the past

Builtin Literals: some ideas seem to come from Perl

There are some things, I don't like, though:

Automatic type conversion: aka "Option Strict Off" on VB.NET - I hate that!

Automatic variable declaration: for it to work, it needs a very solid IDE that's able to catch typos, or it'll introduce bugs that even with unit test may be hard to find out

But the coolest things about this language are:

It's .NET friendly, so you can start using it now where it makes sense to produce some C#-callable libraries

Hey, it's from a Brazilian buddy! It's always nice to see some yellow & green language design!

Another bug, another workaround...

2004-07-07T09:09:00.000-03:00

I was using Genghis to create a standard Find and Replace dialog, when I hit another bug in the .NET framework (this is getting boring...):
The System.Windows.Forms.NativeWindow class has a problem on the ReleaseHandle method: I don't know (don't care) why, when you subclass a window using the NativeWindow class, your new WndProc will still be called, even after the ReleaseHandle. On the Genghis FindReplaceDialog class, this bug appears when you invoke the dialog twice: your WndProc will be called for a while, and then, BAM! A call to a collected delegate will happen. I googled a lot and found nothing, so I coded the following workaround. When you need to subclass a window, just derive from my class instead of deriving from System.Windows.Forms.NativeWindow class and you won't need to change a single line of code!

class NativeWindow
{
    private IntPtr handle;
    private WndProcDelegate wndProcDelegate; // Prevents the delegate being collected
    private IntPtr oldWndFunc;
    private delegate IntPtr WndProcDelegate(IntPtr hwnd, int Msg, IntPtr wParam, IntPtr lParam);

    private const int GWL_WNDPROC = -4;

    [DllImport("User32.dll")]
    private static extern IntPtr SetWindowLong(IntPtr hWnd, int nIndex, WndProcDelegate wndProcDelegate);
    [DllImport("User32.dll")]
    private static extern IntPtr SetWindowLong(IntPtr hWnd, int nIndex, IntPtr wndFunc);

    [DllImport("User32.dll")]
    private static extern IntPtr CallWindowProc(IntPtr prevWndFunc, IntPtr hWnd, int iMsg, IntPtr wParam, IntPtr lParam);

    public NativeWindow()
    {
        wndProcDelegate = new WndProcDelegate(this.WndProc);
    }

    public void AssignHandle(IntPtr hWnd)
    {
        handle = hWnd;
        oldWndFunc = SetWindowLong(hWnd, GWL_WNDPROC, wndProcDelegate);
    }

    public void ReleaseHandle()
    {
        SetWindowLong(handle, GWL_WNDPROC, oldWndFunc);
        handle = IntPtr.Zero;
        oldWndFunc = IntPtr.Zero;
    }

    protected virtual void WndProc(ref Message msg)
    {
        DefWndProc(ref msg);
    }

    public void DefWndProc(ref Message m)
    {
        m.Result = CallWindowProc(oldWndFunc, m.HWnd, m.Msg, m.WParam, m.LParam);
    }

    private IntPtr WndProc(IntPtr hWnd, int Msg, IntPtr wParam, IntPtr lParam)
    {
        Message msg = Message.Create(hWnd, Msg, wParam, lParam);
        WndProc(ref msg);
        return msg.Result;
    }
}

Yet another bug on the .NET framework

2004-07-02T10:12:00.000-03:00

I hit another bug on the .NET framework. No, this time the bug is not a leak like the other two times.
I have this application that is starting to work, and it's starting to be a cool visual credit policies MDI editor. Now that the grunt work is done, I started to make the application visually appealing, and I started adding some icons to the toolbars. Everything was ok, until I added a toolbar and an ImageList to the main MDI form. Suddenly, every image on every toolbar on the application disappeared!
What amazed me more was that at design time everything was ok. After a bit try this, disable that, I disabled the following line on my Main():

/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main() 
{
    // Application.EnableVisualStyles(); <-- Removing this line "solved" the problem
    Application.Run(new Principal());
}

Now I had something to search and after a bit of Google I found this article. Although there are some failure reports on the posts below, Don is right: simply adding an Application.DoEvents worked like a charm!

Marc did it again!

2004-07-02T07:45:00.000-03:00

Marc Clifton, the article writing machine, and MyXaml author did it again! Worried about CodeProject's increasing noise level, he and Anders Molin branched another Windows development site, RealDevs.net. Speaking with some fellow programmers, some became worried about branching a site, which could split the development community. I don't think so: CodeProject was a branch from Codeguru, and look at the size it became, and CodeGuru still exists.
What I love about the way Marc and Anders are doing their site is: high quality articles, use of modern tools (as of today, DNN, DotNetNuke), and openness. Modern tools are a must, IMO, because they'll be able to concentrate on what the users want, not on how to do it. Can you really understand why Codeproject still runs in traditional ASP? And Chris still has performance and scalability problems, even on cluster!
Openness is also very powerful: instead of hiding your problems, tell them to the world, after all we are programmers, and maybe we can help! If not help, we can maybe learn, hehehe.
Quote of the day:

We both believe that there are no reasons for keeping a secret about what platform we use and what problems we have, so we will pretty much post all of it here ;)
- Anders

Good luck, guys!

IDisposable Article Series - What's IDisposable?

2004-07-02T07:25:00.000-03:00

IDisposable is, at the same time, one of the most simple and most important .NET interfaces. It consists of a single method, Dispose, with no parameters and returning nothing. It's declared by the .NET framework as follows:

namespace System
{
    public interface IDisposable
    {
        void Dispose();
    }
}

The goal behind IDisposable is simple: to clear any unmanaged resources allocated by a class. And what are "unmanaged resources"? First, you need to understand what are "managed resources": memory. But not any memory: only memory that the .NET framework explicitly allocated.
You probably know that the .NET framework provides you with a garbage collector (GC). While a standard technical term, I don't agree with this, I think it's not a precise term, at least in the .NET environment: there's no real "garbage collector" in .NET. What really exists is a memory recycler. Basically, you are not in control of memory deallocation and the environment takes care of this for you. Think of this as a "controlled memory leak". Your code will only ask for the GC to allocate memory and keep track of its uses, and when something triggers it (probably a combination of idle time, memory pressure and even maybe the size of your L2 cache), the GC comes in and releases all the unused memory. While this, most of the time, achieves high levels of performance and reliability, also has some very bad consequences:

There's no way to predict when the GC comes in;
There's no simple way to have a predictable destructor on your class, like in C++ and even VB 6.0.

If there are no predictable destructors in the .NET environment, how can API wrapper classes (e.g) Control, Bitmap, Socket or FileStream, which hold a handle to physical, costly or scarce resources, be able to automatically close handles or execute clean up code? They can't: at least, in a predictable way. So, IDisposable comes to scene, and you, the class user, are responsible for the lifetime management.

Next article part:
What are the responsibilities of the IDisposable for the class user?

All you ever wanted to know about the IDisposable and was ashamed to ask

2004-06-24T08:35:00.000-03:00

I have some coworkers who are new to the .NET world, and still need to be introduced to the platform best practices. One of the key knowledge that every .NET programmer should have is the IDisposable interface; when to implement it and when to call it. What happens when you fail to do that is one of the points of this article, but for now let's just say that it can lead to difficult to track software bugs, memory and resource leaks.
Before writing this I researched the Web a lot to find a single place that I could point my colleagues in order to learn about IDisposable, but I could not find an article that covers it both fully and deeply, so I decided to start writing.
As I don't have much free time for now, I will post this on my blog one chapter at a time, probably one topic each day, and when it is finished, I'll post this on sites like Code Project as a finished (huge) article.

The topics I intend to cover are (note that this is my initial planned outline, may it changes a little while I write, but you can consider this as a bare minimum):

The beginning
What's IDisposable?
What are the responsibilities of the IDisposable for the class user?
What happens if I don't call Dispose? Why is IDisposable needed?
Isn't .NET garbage-collected?

Calling Dispose
What happens if I call Dispose twice?
What happens if I use an object that had Dispose called?
Where's the correct place to call Dispose?

Implementing IDisposable
What is the correct way of implementing IDisposable?
Don't forget to throw ObjectDisposedException.

C# Support to IDisposable:
What about C# destructors?
The "using" statement.
The "foreach" statement.

Design implications:
Close or Dispose? Why do both exist?
Why did someone choose a private implementation of IDisposable?
Implications for library writers
Should I dispose a whole hierarchy of IDisposable instances or only the root?
Mis"using" C# support for IDisposable.

Useful links for more information

Leaks, leaks, everywhere...

2004-06-18T14:02:00.000-03:00

I think I'm becoming an authority on finding .NET leaks: I just found a handle leak on the EventLog class.
The problem, this time is with the static method (decompiled with Lutz Roeder's .NET Reflector):

public static void WriteEntry(string source, string message, EventLogEntryType type, int eventID,
                              short category, byte[] rawData)
{
    EventLog log1 = new EventLog();
    log1.Source = source;
    log1.WriteEntry(message, type, eventID, category, rawData);
}

Noticed? EventLog implements IDisposable and the code should be this:

public static void WriteEntry(string source, string message, EventLogEntryType type, int eventID,
                              short category, byte[] rawData)
{
    using (EventLog log1 = new EventLog())
    {
        log1.Source = source;
        log1.WriteEntry(message, type, eventID, category, rawData);
    }
}

So, the lesson is: if you care about not leaking handles (e.g., in server applications, where a few handles per processing unit can shut down a whole service), don't use LogEvent static methods. Create an instance and call its methods, and dispose it yourself.

Eric is right!

2004-06-18T11:12:00.000-03:00

This post isn't about programming, but is about making money programming. Eric is talking about the 22 Immutable Laws of Marketing, and today he posted Law #13: The Law of Sacrifice. Nothing could be more appropriate to me today.
I had this insanely good project, and that would mean a very nice amount of money. Today, I had to say "no" to it because the deadlines are too risky. More than this, it would mean a stop on the development a lot of nice features on Crivo that would fit so well to so many customers, that, in the long term would mean that we're hurting Crivo's feature.
But it's hard to say "no" and it's hard to keep this decision after saying that...

Deriving from Panel woes

2004-06-16T17:13:00.000-03:00

If you're deriving from Panel, set AutoScroll to true and set AutoScrollMinSize to some big numbers, you get a Panel with ScrollBars, right?
Right: everything works, but the OnMouseWheel event doesn't happen, and the mouse wheel don't work. After googling a lot, I happened to discover that the mouse wheel is only sent to controls when they have the focus (doh! it should be obvious!).
So, correcting this is a simple matter of SetStyle(ControlStyles.Selectable, true) and then, at some place (probably on OnMouseDown or OnMouseEnter), you call Focus().
Voilá! Instant mousewheel support on your Panel!

I'm new to this blog thing...

2004-06-16T09:25:00.000-03:00

And I'm yet discovering new things. By default, Blogger has the title field disabled, and the blog started to get confusing. I've changed the setting, but if you subscribed to my Atom feed, you probably noticed that the older posts became duplicated, because Blogger was sending a bogus title for previous posts...

More on Try/Finally.

2004-06-15T17:07:00.001-03:00

Along the lines of my previous post, this month's MSDN Magazine has an interesting article about unexpected errors in managed applications. On the "Some Best Practices" topic, Jason puts some quite strong arguments that go exactly along the lines of my post.
Some highlights:

* Don't catch or throw base exception types
* Use finally blocks liberally

(...)

Now let's look at the guideline surrounding finally blocks. In general, well-written managed code contains more try/finally constructs than it does try/catch constructs. The reason for this is that finally blocks guarantee the ability to perform method-level clean-up operations in both exceptional and non-exceptional executions. Many methods include code that qualifies as "clean-up operations." This includes the closing of files and other resources that were opened in the method, unlocking synchronization locks that were taken during the method, and so forth. Meanwhile, if you follow the first guideline-only catching expected exceptions-the number of methods that actually catch any exceptions at all is reduced in the end.

It's nice to see that I'm not alone thinking this way!

Try/Finally for cleaner cleanup.

2004-06-14T14:20:00.000-03:00

One thing that people often overlook is how a try/finally block can make your code both more readable and more robust. It's a great tool for cleanup code. You can see me using it on the GetErrorMessage on my WinHTTPException class. If you look carefully, you'll see that I close the handle after the return statement.
As a sample, suppose you need to read some temporary information from a file and return it as a string. No matter what happens, you need to delete this file, because it's temporary. This kind of return & cleanup begs for a try/finally block.

Let's see the simplest possible code without using try/finally:

string ReadTempFile(string FileName)
{
    string fileContents;
    using (StreamReader sr = new StreamReader(FileName))
    {
        fileContents = sr.ReadToEnd();
    }
    File.Delete(FileName);
    return fileContents;
}

This code also has a problem when an exception is thrown on, e.g, the ReadToEnd method. So, I've actually saw some people trying to solve it coding as this:

string ReadTempFile(string FileName)
{
    try
    {
        string fileContents;
        using (StreamReader sr = new StreamReader(FileName))
        {
            fileContents = sr.ReadToEnd();
        }
        File.Delete(FileName);
        return fileContents;
    }
    catch (Exception)
    {
        File.Delete(FileName);
        throw;
    }
}

The code is becoming complex and it's starting to duplicate code.

Now, see how much cleaner and robust is the try/finally solution:


string ReadTempFile(string FileName)
{
    try
    {
        using (StreamReader sr = new StreamReader(FileName))
        {
            return sr.ReadToEnd();
        }
    }
    finally
    {
        File.Delete(FileName);
    }
}

Resharper

2004-06-11T15:28:00.001-03:00

I just can't avoid mentioning Resharper. What a great tool!
If you don't know it yet, JetBrains is providing an Early Access Program for free.
It's a refactoring tool for C# and VS.NET, which basically makes your IDE as smart as IntelliJ.
Try it and you won't regret!

Case insensitive String functions

2004-06-09T16:16:00.000-03:00

The more I use .NET, the more I become astonished about what I still don't know. No, I'm not talking about some highly-advanced features: I'm talking about simple things, as string methods.
Sometimes you may need to do a case-insensitive IndexOf, or a case-insensitive StartsWith. Most people would call ToLower or ToUpper. This has two problems:
1. This is not the same thing than a case-insensitive search on some cultures. Second
2. This is slow, and creates two more objects to be collected. If done on a loop, this can create a lot of unnecessary overhead.

The solution most people (me included) do is creating their own case-insensitive IndexOf or StartsWith.
Until I found the CompareInfo class. You can use it through CultureInfo.CurrentCulture.CompareInfo and call, e.g.:

CultureInfo.CurrentUICulture.CompareInfo.IndexOf(text, substring, CompareOptions.IgnoreCase)

Cool, huh?
It's very fast and doesn't add overhead to the GC.

Free from the pad!

2004-06-09T10:45:00.000-03:00

Oh, the joy!
Input and output devices should be where you spend most of your money when building a new computer: they increase productivity like anything else, and their value have a low depreciation through time.
At my office, I use two 17" monitors, a cool MS keyboard with lots of cool features. I also work on a big desk, with lots of space. But I never thought of upgrading my old, trusty Logitech mouse with a wheel: it worked, and I thought it was as good as an optical mouse, and it was only that cool red led light that attracted people. I couldn't be farther from the truth. Yesterday, I used one for a while on a coworker's machine, and when I got back to my old mouse, I couldn't like it anymore. Just the absence of the mouse pad and the freedom to move it on is worth the upgrade. Now, I bought this MS basic optical mouse: it is beautiful, cheap, and looks distinct, seems reliable and easy to install; I plugged right into one of the keyboard USB ports and it started working.

Run, my little mouse, run free from the pad!

Don Knuth: Musings and more

2004-06-08T12:50:00.000-03:00

I just found a great page: Knuth: Musings and more. A series of videos featuring the great Don Knuth. I didn't watch them yet, but I plan doing it on the weekend.

Visual Studio Debugger Breakpoint Helper

2004-06-07T17:16:00.000-03:00

Great tool!
Kant mentioned, on CP lounge, a great tool for troubleshooting breakpoints that don't work.
Visual Studio Debugger Breakpoint Helper

Win32Exceptions capable of dealing with module error messages

2004-06-07T16:17:00.000-03:00

For those who may be, like me, in need of an exception that properly deals with Win32 error codes (obtained from GetLastError()) that can come from the system or an specific module, the code below does the trick.
You can change the name "WINHTTP" (it's what I'm dealing right now) for any DLL name you have and go for it!

using System;
using System.Text;
using System.Runtime.InteropServices;
using System.ComponentModel;

namespace WinHTTP
{
    public class WinHTTPException : Win32Exception
    {
        [DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
        private static extern int FormatMessage(uint dwFlags, HandleRef lpSource, uint dwMessageId, uint dwLanguageId, StringBuilder lpBuffer, uint nSize, IntPtr arguments); 
        
        [DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)]
        private static extern IntPtr GetModuleHandle(string lpModuleName);

        [DllImport("kernel32.dll", CharSet=CharSet.Auto)]
        private static extern bool CloseHandle(HandleRef handle); 

        private const uint FORMAT_MESSAGE_FROM_HMODULE = 0x00000800;
        private const uint FORMAT_MESSAGE_ALLOCATE_BUFFER = 0x00000100;
        private const uint FORMAT_MESSAGE_IGNORE_INSERTS = 0x00000200;
        private const uint FORMAT_MESSAGE_FROM_SYSTEM = 0x00001000;

        public WinHTTPException()
            : base(Marshal.GetLastWin32Error())
        {
        }

        public WinHTTPException(int NativeErrorCode)
            : base(NativeErrorCode)
        {
        }

        private string GetErrorMessage()
        {
            IntPtr hModule = IntPtr.Zero;
            try
            {
                hModule = GetModuleHandle("WINHTTP");
                int error = NativeErrorCode;
                if (hModule == IntPtr.Zero)
                    return "Unknown error " + error.ToString("X");
                StringBuilder sb = new StringBuilder(1024);
                int res = FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_FROM_HMODULE, new HandleRef(this, hModule), (uint)error, 0, sb, (uint)sb.Capacity, IntPtr.Zero);
                if (res == 0)
                    return "Unknown error " + error.ToString("X");
                else
                    return sb.ToString(0, res);
            }
            finally
            {
                if (hModule != IntPtr.Zero)
                    CloseHandle(new HandleRef(this, hModule));
            }
        }

        public override string Message
        {
            get
            {
                return GetErrorMessage();
            }
        }

    }
}

Solved the Win32Exception mistery...

2004-06-05T13:09:00.000-03:00

Great! I wrote my own exception, similar to Win32Exception, and now it's working. I'm calling FormatMessage with FORMAT_MESSAGE_FROM_HMODULE | FORMAT_MESSAGE_FROM_SYSTEM and the proper messages are being retrieved.

My managed WinHTTP wrapper starts to work...

2004-06-05T09:46:00.000-03:00

My WinHTTP wrapper is starting to work. I even made a nicer OOP model around WinHTTP, with a Session, a Connection, a Request, a Response (WinHTTP doesn't have a Response handle, everything belongs to the Request handle), and a ResponseStream that can be used to read the page.
The exceptions aren't still being able to get the proper Win32 messages, I can't understand why, as I'm using System.ComponentModel.Win32Exception and SetLastError = True on Interop.
Now, I just need to add support to HTTP status codes, headers and I'm done.
This really begs for an article, I wish I had a bit more free time (notice, it's Saturday and I'm working...)

P/Invoke to the rescue

2004-06-04T10:22:00.000-03:00

I just realized that I won't need to download the Platform SDK on all of our machines. I'll write a WinHTTP wrapper in C# (I sense a new CP article comming), so there'll be no need for the updated SDK on the machines.
Sure, I'll send it to PInvoke.NET

I quit!

2004-06-04T07:33:00.000-03:00

Unfortunately, I've tried everything and it wasn't enough. The leaks may seem harmless on a desktop application, which can leak a few handles and then wait for the garbage collector to appear, but in a server application it's simply a killer. On a 4-way SMP, there may be up to 100 simultaneous request running (each request takes an average of 5 seconds to complete), and if each of them leak 30 handles, I'm leaking 600 handles/second. The GC simply isn't smart enough to clean all of them and the number never gets down.
Since Crivo only is supported on Windows 2000, XP and 2003 with the last Service Pack applied, an alternative way is by using WinHTTP. No code in Crivo calls directly the .NET HTTP libraries, we provide a smart facade (similar to System.Net.WebClient, but smarter), so it's "just" a matter of rewriting our HTTP library to use WinHTTP.
BTW, I just discovered that WinHTTP is not included on the SDK that came with VS.NET 2003, and since it's now part of the OS (a good thing, IMO), it's not available for separate download anymore. To get it now, we need to run Platform SDK update on all development machines and on the build machine (~250 MB). :sigh:
I think I'll start by writing some C++ wrapper classes. Those who worked with me in the past know that I've always been a fan of RAII.

Damn! Handle leaks on the CLR!

2004-06-03T11:04:00.000-03:00

On the past few days, I'm dealing with some hard to find resource leaks. We seem to be pushing some areas CLR to their limit. You may say, "hey, how can you get resource leaks in a garbage collected environment"?.
Well, the simple code below will leak lots of handles.


        private void MakeARequest()
        {
            HttpWebRequest wr = (HttpWebRequest)WebRequest.Create("http://www.microsoft.com/");
            wr.Proxy = WebProxy.GetDefaultProxy();
            wr.Proxy.Credentials = CredentialCache.DefaultCredentials;
            using (HttpWebResponse wrp = (HttpWebResponse)wr.GetResponse())
            {
                using (Stream s = wrp.GetResponseStream())
                {
                    using (StreamReader sr = new StreamReader(s))
                    {
                        string st = sr.ReadToEnd();
                        sr.Close();
                        s.Close();
                    }
                }
            }
        }

Did you see it? It isn't missing a single Close() or Dispose() call, and yet leaks lots of handles. The biggest the page, the more handles it leaks.
I've been using an evaluation version (10 days remaining...) of the great SciTech's .NET memory profiler and noticed that the CLR is forgetting to dispose some (a lot!) ManualResetEvent, Sockets, and some internal Streams and Readers.
After a while, I found that the culprit are the synchronous HttpWeb(Request, Response) methods, and, by calling the assynchronous versions, I was able to reduce it a lot. Even the returned stream, System.Net.ConnectStream have these problems.
The only problem is when the request throws an Exception, it still leaks lots of handles, and, by now, it seems that I can do nothing about it...

My first post!

2004-06-03T08:58:00.000-03:00

On this blog, I intend to start sharing some knowledge and experiences on .NET development in general.
I'd like to introduce myself, if you still don't know me from The CodeProject. If this is the case, maybe you could be interested in some of my articles.
I'm the technical architect of Crivo. Crivo is an automated credit and risk assessment system, used by several large companies in Brazil. We combine some AI techniques (perceptrons and an expert rule inference engine) with a set of drivers which can obtain information in almost any information source. This set of drivers is one of our most powerful features, and we can deliver more than 27,000 variables coming from around 30 different sources to the assessment engine so it can take a decision.
It's a huge .Net based system (around 1.3MLOC as of date), comprised of around 180 projects. And it's growing fast, as we have a very productive team. As I blog, I'll talk more about how we develop software.