How to disambiguate type in watch window when there are two types with the same name

Question

In the watch window, I'm trying to look at TaskScheduler.Current, but it shows me the following error:

The type 'System.Threading.Tasks.TaskScheduler' exists in both 
'CommonLanguageRuntimeLibrary' and 'System.Threading.dll'   

This is true for my program since:

• This is a .NET 4.0 exe which uses the TaskScheduler out of mscorlib (CommonLanguageRuntimeLibrary)
• A dll is brought in through late binding which references an old Reactive Extensions .NET 3.5 System.Threading.dll which also has TaskScheduler in the same namespace.

Question: What syntax can I use in the debugger to specify the dll of the TaskScheduler I want to inspect?

As an aside: I assume there is no issue (i.e. no undefined behavior) in terms of having these two identically named types being brought into the same executable, right?

Answer 1

I'm not sure if this works through the watch window (but I don't see why it shouldn't, who knows) - but the way to disambiguate between two dll-s with same types is using extern alias.

That's the same thing as the global:: - except that in this case you can use to specify dll aliases.

You can use it by setting / defining alias yourself on the dll reference (I think there is alias field there in the properties).

two different DLL with same namespace

I'm not sure if this entirely applies to your case, i.e. if you are able to do that, but you'll have to try it out in your own case.

EDIT: (based on the comments)

Given specifics - I tried it in my debugger. Since the other one is late-binding - compiler doesn't know about it (of course, as it wouldn't work).

So in your source code (.cs where you need to do the watch anyway) add at the top e.g.

using mysystem = global::System.Threading.Tasks.TaskScheduler;  

Then in the watch mysystem.Current (I'm basing it on my example)

Or...

using mytasks = global::System.Threading.Tasks;  

and mytasks.TaskScheduler - doesn't matter really which one really.

EDIT2:
And for historical reasons - I kind of confirmed that code-editing is unavoidable.

1) remove mscorlib from the project - project, setting, build, advanced.

2) unload and edit project configuration manually - add the mscorlib reference (adding through VS is not allowed). Also another fix is required for WPF apps (out of scope here),

3) add aliases for mscorlib - you can add multiple ones, separate w/ ,, that works fine,

4) add extern alias <your alias>,

from that point you can reference it in debugger - but there is not way of forgoing the manual code editing. Also extern alias is per 'building unit', i.e. file, so nothing global.

In short, that's the best we could do, IMHO.

---

And a confirmation from @JaredPar on this
How can I qualify a .NET type with assembly name for Visual Studio debugger to disambiguate while using an ambiguous type?