Please do not only keep it updated, but also keep the old sources around, too -- and keep them accessible at the same URLs. For example, just now I tried to view source for 'System.Security.Principal.WindowsIdentity'. The PDB was found okay at http://referencesource.microsoft.com/symbols/mscorlib.pdb/A21F40D38EAB4B64B449E50DE8F5A3431/mscorlib.pdb but for some reason the source file couldn't be found at http://referencesource.microsoft.com/source/.NET/4/DEVDIV_TFS//Dev10/Releases/RTMRel/ndp/clr/src/BCL/System/Security/Principal/WindowsIdentity.cs/1407647/WindowsIdentity.cs like the PDB said it should be.
Firefox and Chrome have had stable source access for years: see https://www.chromium.org/developers/how-tos/debugging-on-windows/windbg-help and https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server and also https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_source_server
Supposedly, the Mozilla symbols go all the way back to Firefox 126.96.36.199, though since they shut down the CVS services in 2015, I guess you can't actually do source debugging in anything earlier than Firefox 3.5 without writing a script named "cvs" that adjusts the parameters to refer to a local copy of the repository from http://archive.mozilla.org/pub/vcs-archive/ before calling the real CVS.
My point being that it's really quite practical to keep source code for many, many builds available, and while I realize that you don't exactly have world-readable VCS like Chromium and Mozilla do, it ... really doesn't seem that hard to:
1. Automatically upload a new redacted tree for every release
2. Point the PDBs at that tree
3. *Don't delete the old tree*
This tool might be useful: https://github.com/AArnott/PdbGit
Also note that WinDbg's "r" command looks a bit more sensible, insofar as stuff lines up nicely, though it's kinda cramped vertically.
Yes; even if all the ways that such difficult-to-remove entries can get into the error list are bugs, it would be really nice to have a way to clear the remembered errors so they can be recomputed from scratch; I've ended up having errors listed in files that aren't even used anymore before.
> One way of doing this is having "Clean Solution" clean the Error List. (Let alone that "Rebuild Solution" should do this. I.E. when someone wishes to clean everything. Clean 'Everything!'.
"Clean solution" certainly seems like a reasonable time to do this, though on the other hand, this might make it harder for the developers of VS components/extensions to notice when they introduce such "unfixable" errors.
162 votesunder review · 7 comments · Visual Studio IDE » Debugging and Diagnostics · Flag idea as inappropriate… · Admin →
I suspect that doing this in a manner that is more useful than frustrating is trickier than it sounds: calling into CLR code when the debugger is stopped in a piece of native code is probably not safe, but it doesn't seem like it would be easy to extract data from run-of-the-mill managed types (which do not even specify a memory layout in their IL metadata, much less as part of their API/ABI) without ending up in CLR code: if it's compiled to native code, that code would presumably have to ask the CLR to help it with the memory layout; if it's compiled to managed code, that code is going to have to get run through the CLR at some point or other too, no?
510 votesunder review · 15 comments · Visual Studio IDE » Languages - F# Tools · Flag idea as inappropriate… · Admin →
Embedding that-before-this information in the source files in CPP-style (the C and/or C++ preprocessor(s), not C++!) notation certainly doesn't sound particularly elegant, but there clearly needs to be SOME reasonable way for MSBuild and/or FSC to know in what order to arrange the compilation units.
(I mean, it's not like it would be feasible to redefine F# such that the order dependencies go away, because presumably if that were feasible it would have been done back when F#'s was solely a Microsoft Research project, right?)
Maybe they want XNA Studio? And, you know, license to borrow any portions of MS's XNA library implementation that could be an improvement over what MonoGame has now, whether platform-neutral or just for Windows-specific code...