System.WIndows.Application static members are thread safe?

Question

The Application static members are supposed to be thread safe:

The public static (Shared in Visual Basic) members of this type are thread safe. In addition, the FindResource and TryFindResource methods and the Properties and Resources properties are thread safe.1

How much can we trust that statement in a multithreaded environment when calling static member methods of System.Windows.Application?

Update:
It's all in reference to this question: http://stackoverflow.com/questions/2463822/threading-errors-with-application-loadcomponent-key-already-exists/2463866#2463866

I never thought I'd see a real bug in the library, but this must be the day for me... that question seems to show a genuine bug. Usually it's "user error," but this doesn't seem to be the case.

Answer 1

This is the general pattern of the .Net framework and associated libraries. Static / Shared members are assumed to be thread safe unless otherwise marked. If you find a member that is not thread safe and is not marked as such in the documentation it is a bug (in either the documentation or implementation).

Therefore I think it's safe to rely on them being thread safe.

Answer 2

In general you should trust the documentation at first, but stop trusting it when things don't work as advertised.

In this case the documentation is wrong because of a bug in WPF. See this answer for details about the bug.