Need to print all inner exception details on source file read failure

[RobJellinghaus]

The last line of CommonCompiler.ToFileReadDiagnostics is:

diagnosticInfo = new DiagnosticInfo(MessageProvider, MessageProvider.ERR_NoSourceFile, file.Path, e.Message);

This prints out only the outermost exception's information. We encountered an issue in which a multi-level-deep dependent assembly could not be loaded when a source file was opened; this resulted in an IOException wrapping an AssemblyLoadException wrapping a FileNotFoundException, where the innermost FileNotFoundException had the actual details of which assembly was not found.

I added a helper method:

        public static string DeepMessage(Exception e)
        {
            StringBuilder b = new StringBuilder(e.Message);
            while (e.InnerException != null && e.InnerException != e)
            {
                e = e.InnerException;
                b.Append(" -- ");
                b.Append(e.Message);
            }
            return b.ToString();
        }

And modified the DiagnosticInfo creation to call DeepMessage(e) rather than just e.Message. Proved incredibly helpful. I recommend making a similar change to the mainline source.

[gafter]

Can we please have a bar check from shiproom? If this passes the bar a fix will be prepared for this milestone based on the strategy described above.

User scenario: some compiler failures (e.g. due to missing files) result in unhelpful or incomprehensible errors.

Fix Description: Provide more information from the underlying exceptions by digging through inner exceptions.

/cc @ManishJayaswal @srivatsn @jaredpar This is for 1.0 stable milestone.

[RobJellinghaus]

Note that this strategy might well be applicable in many other places; I just cite this one as one specific actual instance we directly experienced. In our case, we were missing dependencies from the local CLR environment, specifically including System.Text.Encoding.Extensions.dll, without which no text file could be opened by Roslyn. After getting that dll in the right place, we hit the same issue with another dependency or two, including (I think) System.Globalization.dll, so the deep exception info was helpful multiple times in this one place.