VS2017 Error debugging Task of Tuple

Question

I am unable to view the debug information when using a Task of Tuple. E.G. When a breakpoint his hit, I cannot view any variables on hover, in the local window, or in the watch window.

The repro is just to create a new WPF app, add System.ValueTuple, add this code to MainWindow.xaml.cs, and then set breakpoints at both lines with "return".

using System.Threading.Tasks;
using System.Windows;

namespace WpfApp2
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private async void Button_Click(object sender, RoutedEventArgs e)
        {
            var task1 = TaskWithLocalDebugInfo();
            var task2 = TaskWithoutLocalDebugInfo();
        }

        private async Task<bool> TaskWithLocalDebugInfo()
        {
            var viewableInLocalWindowAndHover = true;
            return viewableInLocalWindowAndHover;
        }

        private async Task<(bool, bool)> TaskWithoutLocalDebugInfo()
        {
            var notViewableInLocalWindowAndHover = true;
            return (notViewableInLocalWindowAndHover, notViewableInLocalWindowAndHover);
        }
    }
}

Edit: If I add the un-viewable local variable to watch, I get: error CS8182: Predefined type 'ValueTuple`2' must be a struct.

Answer 1

It's a bug in the current version of Visual Studio 2017. It has been fixed and will be out in the next quarterly release.

See the GitHub issue and the comment from the MS employee saying it's fixed.

In the meantime, from the GitHub comment on Apr 13, 2017:

i can confirm that the bug repros with ValueTuple 4.3.0, but not with 4.3.0-preview1-24530-04.

You can install the "preview" version via the NuGet Package Manager/Manage NuGet Packages for Solution interface. Just select 4.3.0-preview1-24530-04 from the "Version:" dropdown and click "Install".

One hopes that, after the next update for Visual Studio, using the "preview" version of the package won't be necessary. As noted by the previously mentioned comment, it's not clear why using the "preview" version of the package avoids triggering the bug. But obviously it's preferable to be able to use the latest "stable" version of the package if one can; who knows what changes happened since the "preview" version that would lead to some other hard-to-diagnose bug, in the debugger or otherwise.