The Application static members are supposed to be thread safe:
The public s开发者_高级运维tatic (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: Threading errors with Application.LoadComponent (key already exists)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.
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.
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.
精彩评论