Joseph N. Musser II

My feedback

  1. 7 votes
    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)

      We’ll send you updates on this idea

      Joseph N. Musser II supported this idea  · 
    • 2 votes
      Sign in
      Check!
      (thinking…)
      Reset
      or sign in with
      • facebook
      • google
        Password icon
        Signed in as (Sign out)

        We’ll send you updates on this idea

        Joseph N. Musser II supported this idea  · 
      • 36 votes
        Sign in
        Check!
        (thinking…)
        Reset
        or sign in with
        • facebook
        • google
          Password icon
          Signed in as (Sign out)

          We’ll send you updates on this idea

          Joseph N. Musser II commented  · 

          While reviewing a pull request, particularly a large one, I’ll often review many commits individually so I can see the explanatory commit messages and gain a quicker grasp of the changes within the PR.

          When I’m reading the commit diff and I see something to comment on, I usually click the ‘add comment’ icon to add the comment inline with the code. The problem is, since I’m on a commit diff rather than a whole-PR diff (or a PR update diff), the comment is never seen. It doesn’t show up in the discussion under the Overview tab, nor does it get emailed as a PR comment. This keeps catching us out at work.

          (Occasionally, viewing and commenting on a PR update diff is a workaround. This only works when exactly one commit has been pushed to the open PR at a time. This is rare.)

          I'm used to this just working with GitHub PR commits. GitHub knows whether you’re commenting on a PR commit or a non-PR commit, and it adds the comment to the PR discussion as appropriate. ‘Just working’ in TFS would be my favorite outcome, though second best would be to remove the commit comment feature so that I am not misled into commenting there so frequently.

          Joseph N. Musser II supported this idea  · 
        • 273 votes
          Sign in
          Check!
          (thinking…)
          Reset
          or sign in with
          • facebook
          • google
            Password icon
            Signed in as (Sign out)

            We’ll send you updates on this idea

            Joseph N. Musser II supported this idea  · 
            Joseph N. Musser II commented  · 

            This is critical because of the ultimatum that switching to VSTS becomes. We need to know there is a way out back to on-prem, even if we never use it.

            Git repository backups are much less important than project setup, work items, builds and anything else needed to continue if, say, we switched back to on-prem.

          • 40 votes
            Vote
            Sign in
            Check!
            (thinking…)
            Reset
            or sign in with
            • facebook
            • google
              Password icon
              Signed in as (Sign out)
              You have left! (?) (thinking…)
              4 comments  ·  Visual Studio IDE » Debugging and Diagnostics  ·  Flag idea as inappropriate…  ·  Admin →
              Joseph N. Musser II supported this idea  · 
            • 43 votes
              Sign in
              Check!
              (thinking…)
              Reset
              or sign in with
              • facebook
              • google
                Password icon
                Signed in as (Sign out)

                We’ll send you updates on this idea

                Joseph N. Musser II supported this idea  · 
              • 86 votes
                Vote
                Sign in
                Check!
                (thinking…)
                Reset
                or sign in with
                • facebook
                • google
                  Password icon
                  Signed in as (Sign out)
                  You have left! (?) (thinking…)
                  5 comments  ·  Visual Studio IDE » Test Tools  ·  Flag idea as inappropriate…  ·  Admin →
                  Joseph N. Musser II commented  · 

                  They have added this in Visual Studio 2017 Update 6 Preview 2! 🎉

                  https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes#new-hierarchy-view

                • 5,395 votes
                  Vote
                  Sign in
                  Check!
                  (thinking…)
                  Reset
                  or sign in with
                  • facebook
                  • google
                    Password icon
                    Signed in as (Sign out)
                    You have left! (?) (thinking…)
                    201 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
                    Joseph N. Musser II supported this idea  · 
                  • 354 votes
                    Sign in
                    Check!
                    (thinking…)
                    Reset
                    or sign in with
                    • facebook
                    • google
                      Password icon
                      Signed in as (Sign out)

                      We’ll send you updates on this idea

                      12 comments  ·  Visual Studio Team Services » CI (Build)  ·  Flag idea as inappropriate…  ·  Admin →
                      Joseph N. Musser II supported this idea  · 
                    • 38 votes
                      Vote
                      Sign in
                      Check!
                      (thinking…)
                      Reset
                      or sign in with
                      • facebook
                      • google
                        Password icon
                        Signed in as (Sign out)
                        You have left! (?) (thinking…)
                        4 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
                        Joseph N. Musser II commented  · 

                        Apparently the search terms become the title, and there is no way to edit the title once posted. Apologies for the lowercase.

                        Joseph N. Musser II shared this idea  · 
                      • 115 votes
                        Vote
                        Sign in
                        Check!
                        (thinking…)
                        Reset
                        or sign in with
                        • facebook
                        • google
                          Password icon
                          Signed in as (Sign out)
                          You have left! (?) (thinking…)
                          2 comments  ·  Visual Studio IDE » IDE and Editor  ·  Flag idea as inappropriate…  ·  Admin →
                          Joseph N. Musser II supported this idea  · 
                        • 131 votes
                          Vote
                          Sign in
                          Check!
                          (thinking…)
                          Reset
                          or sign in with
                          • facebook
                          • google
                            Password icon
                            Signed in as (Sign out)
                            You have left! (?) (thinking…)
                            26 comments  ·  Visual Studio IDE » Languages - C#  ·  Flag idea as inappropriate…  ·  Admin →
                            Joseph N. Musser II commented  · 

                            For one thing, I don't think it really is an infestation. I've been in a good variety of codebases that use it and it has rarely been laborious. But I know what you're referring to, so let's just go with that. How would you remove it? You would have to go either 100% sync or 100% async or invent a way that the same code could run both ways. You can't run synchronous methods asynchronously without losing all benefits of async and you can't run asynchronous methods synchronously without losing all benefits of sync.

                            Each scenario is specialized. Say you're reading from I/O. If the code runs synchronously, you make the system call to read. If it runs asynchronously, you make a system call to be notified when the system is done reading and then call back to a thread pool thread or to a UI message pump. Those two are nothing like each other but each has distinct benefits that we need to keep around. You have to keep two distinct methods around for this because sometimes you need one and sometimes the other. Does that make sense?

                            Async is inherently expensive just because it's the ideal solution to an inherently expensive problem. You want to make it very clear when you are and aren't using it. Moving to a world where it's all the same method and same return type for extremely different processes would be frustrating.

                            Joseph N. Musser II commented  · 

                            I'm not really sure this is actionable or even desirable. The "zombie" infection and having *Async versions of methods and async void are actually the *ideal* outcome as far as I can tell. There is no helpful way to generalize async and non-async code that I have been able to find. Without async void, how would you be able to write async event handlers in any practical way? I could go on.

                            Unless you have some ground-breaking theory proposals to point to, it sounds like you're mostly complaining about the fundamental nature of async programming rather than complaining about C#'s solution in particular. C#'s async/await is quite the state of the art right now when it comes to solving the callback **** problem, so perfectly executed that other languages are copying it.

                            On the cutting edge there are exciting improvements like custom builders for custom Task-like types, but for the most part the dichotomy between synchronous and asynchronous (callback-driven) code is a practical and useful one. Certainly, I may stand corrected on this and that would be exciting, but we'll need to be pointed to some heavy-duty research rather than complaints. No offense!

                          Feedback and Knowledge Base