Re-opening this issue. Although it has been "fixed" in a sense, the fix does not adequately address the core issue. The "fix" is that instead of SSMS locking up, we now get a lock timeout exception. That's a good start, but we still can't see the information we're looking for.
Example: If I'm creating an index on some table, I still want to be able to get a list of all of the tables in the database. I still want to be able to look at properties of some of those tables. I still want to be able to do all of the stuff I'd usually be able to do.
As mentioned below, this can be accomplished by using the READ UNCOMMITTED isolation level for the core queries. This will enable users of SSMS to get a much better experience, especially when working with large databases.
Any time someone is doing a large DML operation--particularly, index creation--the components of SSMS that use metadata will lock up and become unresponsive. This is bad enough when it happens with the Object Browser, but today I saw it happen with Intellisense.
User A was creating a large indexed view in a database.
User B came in, typed the database name, hit ".", and his query editor window locked up, for several minutes, until User A killed his CREATE INDEX statement.
This kind of behavior is unacceptable for a what is supposed to be a "management" package. Lock timeouts should be set, and READ UNCOMMITTED or READPAST should be used if timeouts do occur, as a backup. Users should not be forced to wait for information--potentially for hours--just because a large index operation happens to be occurring.