Visual Studio IDE

Announcement: Last fall, we migrated this forum to Visual Studio Developer Community to provide you one convenient and responsive system for all feedback. As the final step in the migration, this forum will be closed off completely on June 1st, 2019. We encourage you to visit Visual Studio Developer Community where you can now suggest new ideas, browse and vote on existing ideas, and engage with Visual Studio teams.

We’d like your suggestions and ideas to help us continuously improve future releases of Visual Studio, so we’ve partnered with UserVoice, a third-party service, to collect your feedback. Please do not send any novel or patentable ideas, copyrighted materials, samples or demos for which you do not want to grant a license to Microsoft.

Edit and Continue has always been a staple of Visual Studio development; it's one of the most important features that make it better than other IDEs. In 2002, Visual Studio .Net came out, and didn't have Edit and Continue, which made it very hard to use. In 2003, the new version had Edit and Continue and I was jubilant.

Enable edit and continue for lambda changes; that might mean that you even have to allow edit and continue to add new methods, but that should be possible using light-weight code generation.

Edit and Continue has always been a staple of Visual Studio development; it's one of the most important features that make it better than other IDEs. In 2002, Visual Studio .Net came out, and didn't have Edit and Continue, which made it very hard to use. In 2003, the new version had Edit and Continue and I was jubilant.

Enable edit and continue for lambda changes; that might mean that you even have to allow edit and continue to add new methods, but that should be possible using light-weight code generation.

Currently, integrated JavaScript debugging with Visual Studio is only possible with Internet Explorer. Even though you can do a bit of JavaScript debugging with external tools in Mozilla Firefox and Google Chrome, the experience for debugging is not nearly as good as the integrated JavaScript debugging experience available with Internet Explorer. However, JavaScript errors often cause the IE browser to crash, thus making it very difficult to provide a great JavaScript debugging experience with Visual Studio. Therefore, Microsoft should provide integrated Visual Studio debugging experiences with Mozilla Firefox and Google Chrome as they are the most popular alternative browsers in the market today and are commonly used as part of the standard web development toolset.

Currently, integrated JavaScript debugging with Visual Studio is only possible with Internet Explorer. Even though you can do a bit of JavaScript debugging with external tools in Mozilla Firefox and Google Chrome, the experience for debugging is not nearly as good as the integrated JavaScript debugging experience available with Internet Explorer. However, JavaScript errors often cause the IE browser to crash, thus making it very difficult to provide a great JavaScript debugging experience with Visual Studio. Therefore, Microsoft should provide integrated Visual Studio debugging experiences with Mozilla Firefox and Google Chrome as they are the most popular alternative browsers in…

Visual Studio 2015 RTM contains support for C++ Edit and Continue for both x86 and x64 with the default debug engine (which means you can use EnC and other features such as natvis and async call stacks at the same time). We’ll continue to improve the experience based on feedback but we believe we have completed this feature to a level that we can close this item. Read more details at http://blogs.msdn.com/b/vcblog/archive/2015/07/22/c-edit-and-continue-in-visual-studio-2015.aspx

From the blog post:
Source Link Authentication: The debugger now supports authenticated Source Link requests for Visual Studio Team Services and private GitHub repositories. When debugging code that was built on another computer, such as a library in a NuGet package, Source Link enables the debugger to show correctly matching source code by downloading it from the internet. To build your own code with Source Link enabled see https://aka.ms/SourceLinkSpec.
For VSTS repositories, authentication is provided by signing into Visual Studio. For GitHub, we leverage credentials from the GitHub Extension for Visual Studio and the Git Credential Manager for Windows. If Source Link fails due to an authentication error a new “Source Link Authentication Failed” page is shown to explain the issue. This page allows the user to login to VSTS or GitHub and retry the Source Link request.

From the blog post:
Source Link Authentication: The debugger now supports authenticated Source Link requests for Visual Studio Team Services and private GitHub repositories. When debugging code that was built on another computer, such as a library in a NuGet package, Source Link enables the debugger to show correctly matching source code by downloading it from the internet. To build your own code with Source Link enabled see https://aka.ms/SourceLinkSpec.
For VSTS repositories, authentication is provided by signing into Visual Studio. For GitHub, we leverage credentials from the GitHub Extension for Visual Studio and the Git Credential Manager for Windows. If Source Link fails due to an authentication error a new “Source Link Authentication Failed” page is shown to explain the issue. This page allows…

The C# compiler supports embedding sources files into the PDB via the '/embed' option. However, currently the debugger will not automatically pull them back out and show them. This item tracks properly supporting this feature in the debugger.

The Metrics Power Tool for Visual Studio 2010 is not compatible with the version of FxCop that ships with Visual Studio 2012. It looks like the interface changes that cause the break are minimal.

We use the Metrics Power tool in our build process and derive a number of reports from the data gathered during the nightly builds.

Please release an updated version of the Metrics Power tool which works with FxCop 11 or release an updated installer of the powertool that includes the correct dependencies so that it can be used without having to install Visual Studio 2010 alongside it.

Additional feedback for the power tool:
- Please use the same class name formatting which is used in the Code Coverage tables inside TFS databases, that makes it a lot easier to use the output in the Reporting features.
- Please add the source file location of the method (from the pdb file) to the report as well to make it a lot easier to provide actionable warnings and errors in the IDE.

The Metrics Power Tool for Visual Studio 2010 is not compatible with the version of FxCop that ships with Visual Studio 2012. It looks like the interface changes that cause the break are minimal.

We use the Metrics Power tool in our build process and derive a number of reports from the data gathered during the nightly builds.

Please release an updated version of the Metrics Power tool which works with FxCop 11 or release an updated installer of the powertool that includes the correct dependencies so that it can be used without having to install Visual Studio 2010 alongside…

This is a request to embed support for the SetThreadDescription API to critical Microsoft debugging and analysis tools: the Visual Studio Debugger, WinDbg, WPA, and mini-dumps.

A different User Voice request, titled "Add a thread name property for native threads to support attach and minidump debugging" was recently closed, with the rationale that Microsoft was working on a new approach to thread naming. This approach would be different from the current exception-based approach, and "[Microsoft] will look to leverage that in the future for any investments we make to debugging multithreaded code."

"Microsoft could implement my naive solution and add support to the tools that I care about – they own them all. More importantly, Microsoft could also do it at the kernel level, which would could make it handle thread termination.

There is precedent for adding this sort of instrumentation to the OS. The gflags tool allows developers to enable tracking of heap allocations, object creator type tracking, and much more. It is time for Microsoft to add thread names as a gflags option. The kernel could catch the existing exceptions, the debuggers and profilers could be updated to query the kernel’s thread-name database, and the world would be a better place."

If SetThreadDescription() is indeed the annointed API going forward, please support it properly and deeply within minidumps, debuggers, and analysis tools. Supporting this API across the tool suite would greatly enhance the debugging experience for anyone who debugs applications with significant numbers of threads.

This is a request to embed support for the SetThreadDescription API to critical Microsoft debugging and analysis tools: the Visual Studio Debugger, WinDbg, WPA, and mini-dumps.

A different User Voice request, titled "Add a thread name property for native threads to support attach and minidump debugging" was recently closed, with the rationale that Microsoft was working on a new approach to thread naming. This approach would be different from the current exception-based approach, and "[Microsoft] will look to leverage that in the future for any investments we make to debugging multithreaded code."

Often times I am motivated to create properties that have no custom accessor or specifier bodies. For example:

class Person
{
private int _age { get; set; }
}

The advantage of a property over field in this case is that if I ever want to debug how and when _age is being mutated or accessed I can fill in the bodies of get and set with an obligatory backing field:

and set breakpoints in the get and set body. Let's bypass the need for the backing field and allow users to set breakpoints on the original property. Even if we can't do any "hovering over" to see the value of the property it is still useful for the breakpoint to be hit just so we can see the current state of the stack when the code interacts with the property.

Often times I am motivated to create properties that have no custom accessor or specifier bodies. For example:

class Person
{
private int _age { get; set; }
}

The advantage of a property over field in this case is that if I ever want to debug how and when _age is being mutated or accessed I can fill in the bodies of get and set with an obligatory backing field:

In editions prior to Visual Studio 2010, exceptions were handled by breaking on the line that threw the exception and displaying the Exception Assistant, a dialog that was non-modal and non-distracting.

In more recent editions, this feature has been removed, returning to a large, obscuring modal dialog. Dismissing this dialog on every exception is painful, frustrating and a usability issue.

I would prefer the Exception Assistant was included in Express regardless, but given that it was removed for valid reasons (large number of dependencies, as mentioned on Microsoft Connect), I would suggest the following usability requirements as a *bare minimum* in it's replacement:

- Both Type and Description of the exception,
- Automatic breaking on the line that threw the exception,
- A non-modal state, so I can have it open at the same time as I analyse the state of the program, and
- A smaller, less-distracting appearance.

....

Screenshots and descriptions of this problem can be seen in these blog posts:

In editions prior to Visual Studio 2010, exceptions were handled by breaking on the line that threw the exception and displaying the Exception Assistant, a dialog that was non-modal and non-distracting.

In more recent editions, this feature has been removed, returning to a large, obscuring modal dialog. Dismissing this dialog on every exception is painful, frustrating and a usability issue.

I would prefer the Exception Assistant was included in Express regardless, but given that it was removed for valid reasons (large number of dependencies, as mentioned on Microsoft Connect), I would suggest the following usability requirements as a *bare minimum*…

The TypeScript team build support for source maps into the TypeScript compiler. It would be great if Visual Studio would support this. This would allow a developer to debug TypeScript as TypeScript and not as JavaScript.

64 bit had become popular for a long time. We all need it. Debugging is very important for each developer. We debugging many many times each day, we cannot suffer from the poor performance of remote debugger simulation (MSVSMON.exe) even we are debugging a local 64bit app.