This is embarrassing -- I've been programming .NET for many years and despite following the MSDN instructions for debugging the .NET sources, I've never been able to get it to work.
When I attempt to step into some Framework code (the c'tor for StringBuilder, for example), the debugger just skips right over, onto the next statement. I can't step into any framework code.
I'm using VS 2017, Framework v4.7.
Below are the debugging options.
Go to Symbols and add this URL http://referencesource.microsoft.com/symbols and a local cache path.
Please see:
https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/
Other community members asked the simliar issue about debugging the .NET 4.6 here:
How do I debug .NET 4.6 framework source code in Visual Studio 2017?
Update:
It really has this issue from old VS version to VS2017, anyway, since we could repro this issue now, if possible, like Leo's suggestion, you could vote and add your comment here:
https://developercommunity.visualstudio.com/content/problem/101533/could-not-debug-net-framework-on-windws-10-machine.html
Related
It looks like Visual Studio 2017 switched its online reference documentation from .Net Framework to .Net Core: every time I hit the F1 key, I get sent on .Net Core documentation for the type/method on which the caret was.
Very well if I were in a .Net .Core project, but it does it too on .Net Framework 4.6.1 projects. And on this .Net Core help, there is no Show other versions drop down list. (Which is understandable, that is not really a newer version of .Net Framework 4.x.)
This renders this key almost useless to me. I end up googling the type / method for getting the MSDN .Net Framework 4.x documentation. (Which is currently more complete for subjects existing in both, compare this and this.)
Is there any way to get the F1 key to open from Visual Studio 2017 the .Net Framework 4.x documentation for the type/method on which the caret is?
I have found no settings for that neither in Help nor in Tools/Options.
This issue affects only online help. Technically Visual Studio does not seem to be blamed. It launches the browser on a MSDN website url with parameters specifying the framework and its version. But MSDN redirects regardless to .Net Core documentation. So it now appears to me as a MSDN website bug.
Example url on which Visual Studio 2017 sends:
http://msdn.microsoft.com/query/dev15.query?appId=Dev15IDEF1&l=EN-US&k=k(System.Runtime.Serialization.StreamingContext);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.6.1);k(DevLang-csharp)&rd=true
Resulting MSDN redirection: 301 => https://msdn... then 302 =>
https://learn.microsoft.com/en-us/dotnet/core/api/system.runtime.serialization.streamingcontext
While Visual Studio 2015 sends on:
http://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(System.Runtime.Serialization.SerializationInfo);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.6.1);k(DevLang-csharp)&rd=true
Which only redirects to the https version of the url, then serves the page.
Now this has changed.
As already stated in my question edit, that is more a documentation web site trouble than a Visual Studio trouble.
Moreover, the learn.microsoft.com web site has now changed its redirection. For the provided example, it now gets redirected to (no more core in the path):
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.streamingcontext
Which redirects further to:
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.serialization.streamingcontext?view=netframework-4.7
Well, still not the asked framework (4.7 instead of 4.6.1), but way better than landing on .Net Core documentation instead of .Net Framework.
It also looks as complete as msdn documentation, though not giving the option to see documentation for versions prior to 4.5.
And indeed in my few tests, changing the version does not seem to reload the page, it seems a bit cosmetic for now... In fact, that is the Core reference documentation which is now gone!
So that move from msdn to docs looks like a bit premature, the learn.microsoft.com site seems to be still a "work in progress" site.
Anyway, it does not look to me there is anything to do on Visual Studio 2017 side. Just wait for the new documentation site to get finished.
When debugging an ASP.NET Core application, using Visual Studio 2015, I cannot see the variable, parameters and field values, when, for example, I hover them. I cannot add them to the watch as well. I am running in debug.
We might have found a solution (or at least a workaround) for the problem. If we go into Tools > Options > Debugging and enable Use Managed Compatibility Mode then we can inspect all the values we like.
I hope this solves the issue for you as well.
Update: Visual Studio 2015 Update 2 RC fixed the issue for me, but unfortunately not for the OP.
This behavior happens with 1.0.0-rc1-update1, but not with 1.0.0-rc2-16357.
If possible, upgrade. Microsoft is aware of it.
I’m using visual studio 2008 and moles version 0.93. Everything works well except when I try to debug any test that uses a Moled type. The test skips all my breakpoints. And I get the following message in the output window:
Unable to attach. Check for one of the following.
The application you are trying to debug uses a version of the Microsoft .NET Framework that is not supported by the debugger.
The debugger has made an incorrect assumption about the Microsoft .NET Framework version your application is going to use.
The Microsoft .NET Framework version specified by you for debugging is incorrect
Please see the Visual Studio .NET debugger documentation for correctly specifying the Microsoft .NET Framework version your application is going to use for debugging.
If I try debbuger.Break () I get a message: "No symbols are loaded for any call stack frame. The source code cannot be displayed."
I’m in a crunch right now chasing an issue with one our main components and it has been a pain (like I need novocaine) trying to figure anything out without being able to step through the code.
I want to take advantage of mole's "smooth debugging experience". However, I can't seem to get the debugger to attach at all.
Thanks,
Bzz
See the solution to this issue here:
http://social.msdn.microsoft.com/Forums/en/pex/thread/91c08bf4-3260-458c-a221-91f030a75499
I had this problem when I moved a project from Visual Studio 2010 to Visual Studio 2008. Here's what I did to fix it.
Close Visual Studio. Navigate to the Debug/bin location. Delete the following files:
*.vshost.exe
*.vshost.exe.config
*.vshost.exe.manifest
Open the solution. Goto the project Settings. Under the Application Target Framework, select a framework lower than the one you are working with (you'll set it back later). Visual Studio will close and re-open your project automatically. Then set the Target Framework back to the original version you were working with. Rebuild all, and debugging will work properly.
I seem to have gotten a bit carried away with the number of libraries I'm referencing in a ASP.Net MVC web application I'm working on. Is there any tools or features already built into Visual Studio 2008/2010 which indicates to me which references I don't need?
See this older SO question and answer.
Resharper will do this for you, with its clean code context menu.
I just installed VS on another PC, but this time, while I am coding, it is not marking syntax errors while I am coding..... I need to press F6 to get the errors.
Normally when for example typing the line below, I get 's' underlined saying that there is a mismatch. Any ideas how I can enable this option?
string s = 4;
In order to enable background compilation for C#, which checks you code while typing for many types of errors that are usually only reported when you build the project, you will have to install Service Pack 1 for Visual Studio 2008. If you use the offline MSDN, you will also want to install the updated MSDN Library for Visual Studio 2008 SP1, since there were framework changes from .NET 3.5 RTM to .NET 3.5 SP1 (such as the addition of Entity Framework).
Have you recently deinstalled ReSharper?
(see responses in the same link for other possibilities).
C# has never been as consistent about finding errors while i type as VB.net has. I always assumed it was just due to the freeform nature of the language, which would also explain why C++ never found errors either til build time.