Breaking changes in .Net 2.0 - Something missing

  • Thread starter Thread starter John Wood
  • Start date Start date
J

John Wood

I saw that Microsoft have released a list of breaking changes in .Net here:
http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/default.aspx

While this is useful, it seems to be missing a change that has broken a lot
of my applications, relating to the order in which members are returned by
reflection. At least I can't find it. I reported the bug on ladybug:
http://lab.msdn.microsoft.com/produ...edbackid=e7fa3396-e74f-4f0f-8227-0ee741027f34

Also discussed in my blog:
http://dotnetjunkies.com/WebLog/johnwood/archive/2005/06/28/128723.aspx

Can anyone at Microsoft see that this is added to the list? I think it's
quite an important change.
 
Hi John,

Thanks for your feedback. But I didn't see this in the breaking changes
list. IMO, relying on the order of the returned methods from Reflection is
not reliable.

I suggest you sign in into the feedback page and suggest the product team
to make this breaking change listed. Because in this way, the products team
will see this immediately.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
I relied on the order of returned methods for caching purposes.

In my case the cache (consisting of a member-index to member lookup) was
created at application startup, and was referred to during application
execution. In 1.1 this worked (because members would be returned in the same
order throughout the application session).

In .Net 2.0 it doesn't work because every time you ask for a list of
members, they come back in a random order. This randomness was added by the
..Net team in 2.0 to ensure you don't rely on the order.

Relying on the order of members between sessions (ie. in serialization)
certainly isn't a good idea, many things can change between sessions. But
*during* the session objects won't be changing! And so they should be
reliable. Their solution to the problem of having people rely on the order
of reflection members being returned doesn't take my scenario into account.
It used to work in 1.1 and doesn't in 2.0 and that makes it a breaking
change.

Heck my applications break what more proof do I need to give! :)

When you say feedback page - do you mean in ladybug? or the feedback page
for the breaking changes list?

Thanks for responding,
John
 
John Wood said:
I relied on the order of returned methods for caching purposes.
In .Net 2.0 it doesn't work because every time you ask for a list of
members, they come back in a random order.
Click to expand...

Thanks for the heads-up on this. I'm also chaching memeber/field index
offset info.
This randomness was added by the .Net team in 2.0 to ensure you don't
rely on the order.
Click to expand...

Okay, that's *really* stupid. There are so many ways for people to shoot
themselves in the foot, that to try and stop this one way and in the process
disable a sensable optimization is pretty silly. I don't depend on C struct
layouts between machines or even compiler versions, but I certainly expect
them to be the same every time I run the same program so I can read my own
file. Next they'll be adding a random epsilon to all floating point values
because you shouldn't depend of those lower bits anyway...

m
 
Hi John,

In this case, you'd better contact the product team on this issue to get a
workaround from them. You just sign in on that feedback page to continue
posting. The product team might give you a workaround.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
 
Back
Top