I just sent the following email to the BCL (Base Class Library) Team Blog email address in hopes of getting some insight into a weird problem we've been having.
I was hoping you could give me some general guidance on how Type.GetProperties() determines the sequence of the PropertyInfo objects it returns.
I just ran across this remark on MSDN about the order that Type.GetProperties() returns PropertyInfo objects
The GetProperties method does not return properties in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which properties are returned, because that order varies.
We have parsing code that uses the 1.1 framework which is dependent on the order in which properties are returned. It fails intermittently when run as part of a suite of MbUnit tests. After seeing this msdn remark, I changed the code to remove the sequence dependency and the MbUnit intermittent failure problem disappeared. This led me to believe that properties were sometimes being returned in an order other than what we expected (the order they were declared in the code files).
Normally we are not allowed to make production changes this time of the year unless the issue is critical, so we are trying to determine the likelihood of this causing production issues. The problem is that we get contradictory results based on how we test this. If I wrap the method in a hundred thousand loop iteration, then I can’t reproduce the error in MbUnit. The properties always return in the order in which they are declared in the class file. However, if I run the whole suite of tests several times in succession, then I receive random errors that seem to derive from the sequence being returned in a different order.
Is there some internal algorithm that might trigger a different sequential order to be generated based on some unique condition that running the whole MbUnit suite of tests as opposed to running them in a large loop would cause (i.e. a certain number of threads or memory/cpu pressure)?
Any insight you could offer in this problem would be greatly appreciated.
Thank you,
Russell Ball
Does anyone else have any ideas?
** Update **
We no longer get these failures in MbUnit if we revert it to the 1.1 framework by changing the supported frameworks node in the config file as described here. I'm guessing they changed the algorithm in the 2.0 framework that is used to determine the sequence.
That still doesn't explain why there is a difference between calling our code in a massive loop versus calling it as part of a suite of tests, but at least it puts our minds at ease with respect to the risk of intermittent failures occurring in our current production code.