I have a fairly large project inside a VS 2015 solution (yes, just one project) which uses an in-house NuGet package (and lots of namespaces from within that package.)
I have another (newer) NuGet package from which I need to use just one class, but that class conflicts with one of the namespaces pulled in by one (actually more) of the existing NuGet packages.
To make things more fun, there are plenty of other namespaces pulled in by the same, new package, used across multiple other NuGet packages.
Having read these SO/blog posts on the subject of extern alias:
What use is the Aliases property of assembly references in Visual Studio 8. https://blogs.msdn.microsoft.com/ansonh/2006/09/27/extern-alias-walkthrough/ http://geekswithblogs.net/bconlon/archive/2014/12/18/ambiguous-classes-in-c.aspx
I figured that I could simply add the required NuGet package, change it's alias from global to except (it involves exception logging) and everything should now compile as it did before. I thought this because I believed that anywhere I had not explicitly said to use a namespace from the new DLLs brought in by that package would continue to use the incumbent DLL namespaces.
This assumption (however learned) appears to be wrong because I added the NuGet package, changed it's DLL's alias and the rebuild did not work. Numerous exists in both build errors are reported.
Argh. Turns out the (legacy) solution dependencies were locally referenced DLLs, not NuGet packages.
The lesson here: Check your references.