c#debugging visual-studio-2022 output-window

Visual Studio 17.4.4 debug output: double-clicking solution-relative path

There are many questions that seem to be related, but they are all old, while I am almost sure this started happening with the latest update to visual studio version 17.4.4.

The problem:

In an as-concise-as-possible summary:

Double-clicking a line starting with solution-relative path in the debug output of Visual Studio in a multi-project solution opens up the file in the editor as an unusable plain text file.

As you know, if a debug output line starts with D:\Full\Path\To\SourceFile.cs(99): then it is double-clickable, and it opens the given file in the editor, and places the caret at the given line. That's immensely useful, so all my logs are in exactly that format. It can also be prefixed with optional whitespace, so all of my (indented) exception stack traces are also in that format.

The pathnames given by [CallerFileName] or StackFrame.GetFileName() are absolute, so they start from the drive letter and include the kitchen sink; in order to save screen real-estate and to produce logs that are also meaningful on machines other than the machine where the software was compiled, I have been converting all these absolute pathnames to solution-relative, and Visual Studio has been understanding them just fine. Until a couple of days ago.

So I recently upgraded my Visual Studio to version 17.4.4 and I installed/removed a whole bunch of frameworks for various things. Now, I am having the following problem: relative path-names in the output window still work for single-project solutions where the project is in the same directory as the solution; for multi-project solutions, the following bad thing happens:

When I double-click on a line in the debug output, Visual Studio opens the corresponding file in a new tab even if it already had it in an existing tab, and in this new tab the file is unusable: there is no syntax highlighting, no tooltips, no navigation, nothing.

The question(s):

Is anyone else experiencing this?

Has anyone found a workaround?

The Bug Report

I would have filed this bug report with Microsoft, but in order to do that they require me to authenticate first, and their authentication mechanism does not work. (I suppose that's one way of reducing the number of bug reports; Joseph Heller would be proud.) So, here is the bug report that I would have filed.

I am programming in C# using Visual Studio with ReSharper.
I have tried the following both with DotNet Framework 4.6.2 and with DotNet 7.0.
Full version information follows at the end.

Steps to reproduce:

Create a console application, ConsoleApp2.
Uncheck the "Place solution and project in the same directory" checkbox.
At the end of the auto-generated Program.cs add the following line of code: System.Diagnostics.Debug.WriteLine( "ConsoleApp2\\Program.cs(4): Hello, Output Window!" );
Compile the solution
Close the solution and re-open it.
Launch ConsoleApp2 (with debugging)
In the debug output of Visual Studio, double-click on the line that says "Hello, Output Window!".

Expected behavior:

Visual Studio switches to the already existing tab with Program.cs, and places the caret at line 4.
Syntax highlighting continues to work as expected.
Gutter symbols continue to appear.
Code tooltips are still available.
Navigation such as go-to-definition still works.
The tooltip of a tab shows the full path of the source file.
The "Open Containing Folder" command on the tab opens the folder containing the file.

Actual behavior:

Visual Studio opens an entirely new tab, loads Program.cs in it, and places the caret at line 4.
Syntax highlighting is completely gone.
Gutter symbols have disappeared.
Code tooltips are not shown anywhere in the code.
Navigation such as go-to-definition does not work anymore.
The tooltip of a tab shows only a relative path.
The "Open Containing Folder" command on the tab gives an error message box saying "Unable to open the folder. It might have been deleted or [...]"

Notes:

If the solution and the project are in the same directory, the problem does not occur.
The problem does not occur on the first try; the step which says "Close the solution and re-open it" appears to be necessary.
If you edit text in the "phantom" tab and save it, the changes do appear in the real tab.

Why is this a big problem:

The ability to double-click on a line in the debug output window and to be taken to the source code that emitted that line is a major convenience. When the IDE shows a wrong or otherwise unusable file, there is no way to open the right file other than carefully selecting part of the log line and pasting into the search box so as to perform a manual search for that file, which means that this major convenience is completely annulled.

Version information

From "About Microsoft Visual Studio":

Microsoft Visual Studio Community 2022 Version 17.4.4 VisualStudio.17.Release/17.4.4+33213.308 Microsoft .NET Framework Version 4.8.04084

Installed Version: Community

ASP.NET and Web Tools 17.4.326.54890 ASP.NET and Web Tools

Azure App Service Tools v3.0.0 17.4.326.54890 Azure App Service Tools v3.0.0

C# Tools 4.4.0-6.22608.27+af1e46ad38d900023f8b1a2839484e471ece1502 C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Clear MEF Component Cache 1.4 Clears the Visual Studio MEF component cache to fix issues with cache corruption.

Dotfuscator Community Edition 6.5.0+76d4669002 PreEmptive Protection - Dotfuscator CE

Extensibility Essentials 2022 1.1.14 A collection of extensions that makes it much easier to write Visual Studio extensions

Extensibility Margin 1.0.9 Shows relevant information about the current file and language to extensibility authors

Extensibility Message Bus 1.4.1 (main@2ee106a) Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Image Manifest Tools 1.1.8 Makes it easier to create and maintain .imagemanifest files for Visual Studio extension

Insert Guid 1.3.6 Makes it super easy to insert a new GUID into any editor and input field

KnownMonikers Explorer 2022 1.2.42 A tool window for Visual Studio extension authors to explore the KnownMonikers image collection

Markdown Editor v2 2.0.132 A full featured Markdown editor with live preview and syntax highlighting. Supports GitHub flavored Markdown.

Microsoft JVM Debugger 1.0 Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Mono Debugging for Visual Studio 17.4.19 (8c0a575) Support for debugging Mono processes with Visual Studio.

NuGet Package Manager 6.4.0 NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Pkgdef Language 1.3.88 Full language support with IntelliSense, validation, outlining, and more for .pkgdef and .pkgundef files

Razor (ASP.NET Core) 17.0.0.2246202+61cc048d36a3fc9246d2f04625988b19a18ab8f0 Provides languages services for ASP.NET Core Razor.

TypeScript Tools 17.0.10921.2001 TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 4.4.0-6.22608.27+af1e46ad38d900023f8b1a2839484e471ece1502 Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools 17.4.0-beta.22512.4+525d5109e389341bb90b144c24e2ad1ceec91e7b Microsoft Visual F# Tools

VisualStudio.DeviceLog 1.0 Information about my package

VisualStudio.Mac 1.0 Mac Extension for Visual Studio

VS Theme Colors 2022 1.0.11 Makes it easy to browse all the brushes and select the right theme color for your Visual Studio extension UI.

VSCode Theme Converter 1.0.15 A super easy way to convert VS Code themes to Visual Studio using the official CLI tool under the hood

VSColorOutput64 2022.2 Color output for build and debug windows - https://mike-ward.net/vscoloroutput

VSIX Synchronizer 1.0.27 Provides the ability to generate code-behind files for .vsixmanfiest and .vsct files in managed code to make the information easy to consume from the rest of the extension.

VSPackage Extension 1.0 VSPackage Visual Studio Extension Detailed Info

Xamarin 17.4.0.312 (d17-4@be7e8d1) Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer 17.4.0.138 (remotes/origin/d17-4@d36bba3cc9) Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin.Android SDK 13.1.0.1 (d17-4/13ba222) Xamarin.Android Reference Assemblies and MSBuild support. Mono: a96bde9 Java.Interop: xamarin/java.interop/d17-4@fcc33ce2 SQLite: xamarin/sqlite/3.39.3@23e1ae7 Xamarin.Android Tools: xamarin/xamarin-android-tools/main@0be567a

Solution

I think I may have found a workaround to this annoying problem. The workaround is also annoying, but not nearly as annoying as the problem itself. The workaround is as follows:

After converting an absolute source file pathname to a solution-relative pathname, prepend ..\ to it.

So, if you use [CallerFilePath] unmodified your log lines in the output window look like this:

C:\Full\Path\To\The\Solution\Project\Namespace\SourceFile.cs(4): bla bla bla...

...which works, but it is awful.

If you remove the path to the solution you get this:

Project\Namespace\SourceFile.cs(4): bla bla bla...

...which does not work; instead, it causes Visual Studio to exhibit the incredibly buggy behavior described in the question.

If you prepend "..\" to each line, you get this:

..\Project\Namespace\SourceFile.cs(4): bla bla bla...

...which is annoying, but it seems to work, and it is nowhere near as annoying as having every single log line in the debug output window prefixed with the entire absolute path to the solution.

So, apparently Visual Studio is using some directory other than the solution directory as the directory relative to which it resolves source filenames. I suspect it uses the directory of the startup project, which is entirely arbitrary, and of course it causes problems.